Profile from openPMD file

[MaxThevenet]

This PR creates a new profile to read a laser pulse from an openPMD file. It derives from fromArrayProfile. Works both when the profile read is a laser envelope or the electric field of a laser pulse. in the latter case, the envelope is obtained with a Hilbert transform. Both were tested and give the same result as shown in #141.

Example

from lasy.profiles.from_openpmd_profile import FromOpenPMDProfile
from lasy.laser import Laser

# Create profile: one of
# - from FBPIC output
profile = FromOpenPMDProfile('lab_diags/hdf5/', 10, (0,1), 'E', 'y')
# - from LASY output
profile = FromOpenPMDProfile('./laserfbpic', 0, (1,0), 'laserEnvelope', envelope=True, prefix='laser3d')

# Create laser
dim = 'xyt'
lo = (-120e-6, -120e-6, -10e-15)
hi = (+120e-6, +120e-6, +60e-15)
npoints=(32,64,128)
laser = Laser(dim, lo, hi, npoints, profile)
laser.write_to_file('./laserfbpic/laser3d')

# Plot
from openpmd_viewer import OpenPMDTimeSeries
import numpy as np
import matplotlib.pyplot as plt
ts = OpenPMDTimeSeries('./laserfbpic')
F, m = ts.get_field(field='laserEnvelope')
F = np.abs(F)
plt.figure(figsize=(8,8))
plt.imshow(F[:,:,F.shape[2]//2], aspect='auto')
plt.colorbar()

To do (probably in a separate PR):

• Clean up handling of polarisation.
• Some functions could be interesting in general, and could be in tools or (better IMO) openPMD-viewer.
• Make compliant with latest version of the standard.
• (only if needed) support all axes ordering.
• The phase retrieval is 1D, which may cause problems for more complex laser pulses, so this could be improved.

[MaxThevenet]

As suggested by @RemiLehe FromOpenPMDProfile now derives from FromArrayProfile.

[hightower8083]

should probably use converters

[MaxThevenet]

A typical workflow:

• Run a FBPIC simulation, get z output
• Read in LASY, and do this dummy conversion t=-z/c (needed as lasy requires t representation)
• Write envelope to file, t representation
• Read in from another code, and if needed do the inverse conversion (z = - c*t). Alternatively, this and the step above could be simplified if LASY could output z representation directly, see More features to the z-t converters #155.

Points 2 and 4 are exactly symmetric, which is what we want, and that's easily done with this dummy convertor, so I think it should be like this. But the clean way would be to make this dummy convertor an option of the import_from_z convertor, that's for another PR (after #155 is addressed).

[hightower8083]

here you implicitly set t[0]=0, while we usually center beam in time so t_peak=0

[MaxThevenet]

Also to be discussed in #155.

[hightower8083]

here you could probably use np.gradient(phase, axis=-1) with weights=np.abs(h)

[MaxThevenet]

Indeed

[hightower8083]

maybe if wavelength is provided and differs from the one in the field, we should physically re-define the field with the new wavelength, e.g.

            array = F
            s = io.Series(path + "/" + prefix + "_%T.h5", io.Access.read_only)
            it = s.iterations[iteration]
            omg0 = it.meshes["laserEnvelope"].get_attribute("angularFrequency")

            if wavelength is None:
                wavelength_loc = 2 * np.pi * c / omg0
            else:
                wavelength_loc = wavelength
                array *= np.exp(1j * (2 * np.pi * c  / wavelength - omg0) * t)

[MaxThevenet]

Yes, we could do sth like this, I would keep this for another PR, as there are quite a few options that could make sense. I put it int #156.

[hightower8083]

i'm not sure it's an separate option -- imagine, a user takes an envelope defined with some central frequency, but wants to obtain an object with a different one. In that case the envelope phase should be adjusted as suggested. Otherwise wavelength_loc = wavelength is only passed to super().__init__() which registers it but never uses.

[MaxThevenet]

likewise, discussed offline, this option is useful and independent from this PR.

[MaxThevenet]

Thanks for your comments! I should have addressed them. I suggest that, for some of them, we address them in a separate PR, so I opened an issue (#156) accordingly. In particular, there should be CI, but that would be vastly simplified by either openPMD supporting t representation or by working a bit on the converter (also related to #155).

[MaxThevenet]

Discussed offline: I'll remove the wavelength argument, as it is mostly here for debugging and for some corner cases, and implement some other utils (find central frequency, shift the frequency at which the envelope is defined, etc.) that we can call here.