search

openPMD / openPMD-standard

:notebook: Open Standard for Particle-Mesh Data
http://www.openPMD.org
Creative Commons Attribution 4.0 International
79 stars 29 forks source link

Laser extension #271

Closed MaxThevenet closed 1 year ago

MaxThevenet commented 1 year ago

This PR proposes a new extension to the standard, suitable for describing a laser envelope on a regular grid.

Description

Although a laser pulse can be described as an electric and a magnetic field, it is sometimes much more efficient (in particular because one then need to describe the envelope only, not the laser frequency) to describe it as an envelope, and store its central frequency/wavelength as metadata. This is relevant for PIC codes relying on a laser envelope (most quasi-static PIC codes, and a number of electromagnetic PIC codes), but is not covered by the ED-PIC extension. The new EXT-LaserEnvelope is short and just targets this use case (with minimal metadata).

Affected Components

Logic Changes

Writer Changes

Reader Changes

This PR will not change any behavior, but the new option to describe a laser envelope will be incorporated with some changes in at least openPMD-viewer.

Data Converter

ax3l commented 1 year ago

Thanks a lot for this, Maxence!

We already reviewed this in lasy and have currently no further comments on it.

Let me know if you like to keep it open for a bit as we implement in lasy or if we shall stage it into the upcoming-2.0.0 branch already.

MaxThevenet commented 1 year ago

Thanks for your reviews, I think all comments are addressed now. @ax3l once we agree on this standard we can merge to upcoming-2.0.0 IMO.

MaxThevenet commented 1 year ago

Thanks, I updated the standard to allow for arbitrary name, with <laser envelope name> as a placeholder. Would this work for you?

Also, rather than looping over all mesh records and checking whether isLaserEnvelope == True, we're considering in HiPACE++ asking the user to specify the name of the laser envelope field (and then check for this field whether isLaserEnvelope == true). This is relatively convenient in the code, and avoids cumbersome logic when e.g. a file has multiple laser pulses. Should this be the advised behavior, or do we give no recommendation and let the application developers choose?

ax3l commented 1 year ago

Great point to consider.

I think by default, one can pick the first laser pulse found in a provided file.

I think if multiple pulses are in a file, one should either load all of them or warn if a code that can only handle one pulse picks one (e.g., the first found).

If a user picks one by name, then of course that one is taken (no warning). Does that make sense?

MaxThevenet commented 1 year ago

Just coming back to this PR. Is there something else needed?