Weak operations in postgkyl

[JunoRavin]

Weak division, multiplication, and other vector operations (dot product and cross product) should be possible on the DG fields postgkyl reads in.

This feature will allow us to compute weak moments (such as u, T, P_{ij}, q_i, the flow, temperature, pressure tensor, and heat-flux vector) even when we do not write out weak moments (and in general this may be preferable to writing out large numbers of files). In addition, there are a number of operations we would like to do with Vlasov (and eventually DG fluid) simulations that can also be done weakly, thus reducing error propagation. For example, in drift analysis and energization analysis, we are often interested in the parallel/perpendicular components of a field. The vector form of the parallel flow is simply:

u_{parallel} = (u dot b_hat) b_hat

which can be expressed as:

u_{parallel} = [(u dot B) * B]/|B|^2

the entire operation of which can be done using weak multiplies, dot products, and divides. We can then find the total parallel energy gain by doing a similar set of weak multiplies, dot products, and divides on the electric field, and computing: u_{parallel} dot E_{parallel}.

Other manipulations of the data, such as the parallel pressure, or E x B velocity, can also leverage weak operations, allowing us to delay interpolating of the data until the moment before visualization in many cases.

To add this feature, I believe the quickest thing to do would be to copy BinOp kernels into the postgkyl repo with a similar organization to gkyl, and then use similar infrastructure to the interpolate method to manipulate the raw DG field. Alternatively we could work towards making gkyl directly callable by postgkyl, which definitely speed up the operation (though at least for the application I want, this feature is only needed on 1D, 2D, and 3D data, and I expect that looping over a configuration space grid and doing weak operations is not going to be that taxing).

[ammarhakim]

I do not want to duplicate code across pgkyl and gkyl. It is best if we figure out how to use gkyl through pgkyl. It will not be hard and once we do it we will have tons on new and powerful things we can do immediately. In fact, my suggestion is really to get rid of interpolation from pgkyl and use the gkyl provided interpolation.

One disadvantage of pgkyl depending on gkyl is that the latter needs to be available. However, I think we don't need the latest-greatest gkyl but a version which works and is distro via conda.

[JunoRavin]

One disadvantage of pgkyl depending on gkyl is that the latter needs to be available. However, I think we don't need the latest-greatest gkyl but a version which works and is distro via conda.

I agree with this sentiment. Features that can be done through gkyl and that will be commonly used in postgkyl (interpolation, weak operations) are hopefully going to be very stable within gkyl. We may need a different pipeline for doing parallel post-processing (if we want to compute the field-particle correlation on TBs of data or something), but for post-processing in serial through postgkyl could just use the conda installation.

[nmandell]

I think it is important to keep postgkyl very easy to install/build. I think it’s a non-trivial complication if you also have to build gkyl to use postgkyl.

…

On Jan 4, 2021, at 10:32 AM, James Juno ***@***.***> wrote: One disadvantage of pgkyl depending on gkyl is that the latter needs to be available. However, I think we don't need the latest-greatest gkyl but a version which works and is distro via conda. I agree with this sentiment. Features that can be done through gkyl and that will be commonly used in postgkyl (interpolation, weak operations) are hopefully going to be very stable within gkyl. We may need a different pipeline for doing parallel post-processing (if we want to compute the field-particle correlation on TBs of data or something), but for post-processing in serial through postgkyl could just use the conda installation. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#13 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHRISTESLQG4J4P6ICU73DSYHNQNANCNFSM4VTD2J4A>.