picongpu icon indicating copy to clipboard operation
picongpu copied to clipboard

Add InsightPulse profile

Open fabidie opened this issue 1 year ago • 2 comments

The InsightPulse profile is an IncidentField method that reads a Laser pulse into PIConGPU that has been measured experimentally at the focus position with Insight.

Since the Insight measurement is done in the frequency domain, the E-field data first has to be transformed into the time domain. Afterwards, the field data chunk is saved to an OpenPMD checkpoint and from there it will be read onto the incident field plane in the simulation volume (via linear interpolation). Those "preparation steps" are done with a python script, which is provided under picongpu/lib/python/picongpu/extra/input. There, one can find also an example workflow which explains the preparation routine more in detail.

Currently, there are some restrictions in using this profile:

  • propagation and polarization only work along the axes, not diagonally!
  • the pulse will always be aligned centered at the incident plane
  • one needs to increase the reserved GPU memory size in memory.param - since the field data chunk will be stored on each used device at timestep 0 (and not during init, before allocating the particle memory), the simulation could otherwise run into memory issues.
  • the Insight measurement scales have to be mm and fs, otherwise the preparation routine has to be adapted

There have been various tests:

1. Using a gaussian pulse profile

A Gaussian pulse field chunk ($\lambda$ = 800nm, $\tau$ = 30fs, $w_0$ = 10 $\mu$ m, $z$ = $-z_R$ = -0.393mm) has been read from OpenPMD into the simulation volume and then propagated to the focus. First, the amplitude at the incident plane ("PIC") has been compared to the analytical definition of the Gaussian pulse at $z$ = $-z_R$ ("Original") for different time steps covering the pulse duration. incidentPlaneIte600 The vertical line in the last subplot indicates the position of the incident plane at this moment. The amplitudes look similar in extent, but different in structure and amplitude, since the longitudinal sampling of both datasets is different. These small differences in space/time cause the visible differences, since the amplitude varies with $\lambda$ in the longitudinal direction.

Then, the amplitude at the focal plane ("PIC") has been compared to the analytical definition of the Gaussian pulse at the focus ("Original"), also for different time steps covering the pulse duration. focusPlaneIte5666 (amplitude in the focal plane) focusDiffIte5666 (transversely integrated amplitude, the black line represents the focus position) xzPlaneIte5666 (amplitude in propagation direction, the blue lines represent the focus position) Here, the lines again represent the focal plane position for this certain time step. Both pulses look similar in extent and amplitude.

Furthermore, the beam energy (density) was investigated. The original input beam had an energy of 4.5 J and the measured beam energy in the focus (shown in the pictures above) was a bit below with 4.3 J. The result could probably be improved with a finer sampling. Also, the energy density in the focus (integrated along the propagation axis) looks similar in extent and value (and is probably a better indicator than the beam amplitudes at incident and focal plane, since the effects of different spacing vanish due to the integration): energyDensityIte5666 The energy was calculated according to $W = \int dV \frac{\epsilon_0}{2} (E^2 + c^2 B^2)$ and the energy density $\mathcal{W} = \int dz \frac{\epsilon_0}{2} (E^2 + c^2 B^2)$.

Finally, the simulation has been re-run with the GaussianPulse profile (and the same parameters) to compare it to the former results (they looked the same).

2. Using a Gauss-Laguerre pulse

According to the definition of a Gauss-Laguerre pulse in the GaussianPulse profile, a Gauss-laguerre pulse field chunk has been written to OpenPMD and read into PIConGPU. The pulse parameters were the same as for the Gaussian pulse above, just $\tau$ was set shorter to $30/2\sqrt{2 ln 2}$ fs. As Laguerre coefficients, the example set in GaussianPulse.def was used. For two different positions, the simulation results ("PIC") were compared to the analytical solution ("Original"): a) at $z \approx -z_R$ xyPlaneIte1285 (amplitude along the longitudinal direction) energyDensityIte1285 (energy density, definition see above) b) at the focus position xyPlaneIte5597 (amplitude along the longitudinal direction, the blue line is the focus position at this time step) energyDensityIte5597 (energy density, definition see above) focusDiffIte5597 (transversal integrated amplitude, the black line is the focus position at this time step) In the above mentioned simulations, the transversal simulation cell was square-shaped, as well as the transversal extent of the test pulse field chunk. To test also the asymmetrical case, the simulation cell in $x$ direction was halved in size. The results were similar: energyDensityIte5649 (energy density for an asymmetrical cell size; the asymmetry in amplitude shows that the energy is conserved better for a smaller cell size) Then, the cell size was reset to original (transversal square-shaped), but the (original) field chunk was chosen to be asymmetrical: originalChunkExtent (original Gauss-Laguerre field at $z=-z_R$, before reading it into the simulation) The resulting simulation did behave just the same as above, e.g. the pulse was still centered and not distorted after propagating it into the focus: yxPlaneIte5597 yzPlaneIte5597 (amplitude in longitudinal direction, along both transversal directions; blue is the focus position) energyDensityIte5597 ( energy density)

3. Using an Insight measurement

For that, the measured field data has been propagated out of the focus (-150, -300, -500 and -1280 (= $-z_R$ ) $\mu$ m, during the preparation routine), saved to OpenPMD and then read into the simulation. This has been done for different propagation and polarization directions, for different (transversal) simulation window extents, for different transversal grid spacing ($w_0/6$ and $w_0/10$) and for a different number of devices (1, 2, 4). The field at the incident plane ("PIC") has been compared to the read-in ("Original") data: incidentPlaneIte1800 (propagation in z direction, polarization in x direction, just as the original) incidentPlaneNegPolIte1800 (propagation in z direction, polarization in -x direction; this automatically also swaps the y axis to keep the original pulse orientation) xzPlaneNegPropIte1800 (propagation in -z direction, polarization in x direction; the time axis of the original data has been transformed to a spatial one by multiplication with $c$ to allow a better comparison)

For z = -300 $\mu$ m, the pulse has been propagated in PIConGPU into the focus and then compared there to the Insight measurement at the focus: focusDiffIte4400 (amplitude at the beam center in propagation direction) focusPlaneIte4400 (amplitude in focal plane) xzPlaneIte4500 (amplitude in longitudinal direction, blue is the focal plane; the time axis of the original data has been transformed to a spatial one by multiplication with $c$ to allow a better comparison)

Differences in the above pictures arise from:

  • different spacing (so they are not completely at the same place in spacetime)
  • using the $c t$ approximation for the longitudinal space axis
  • numerical errors ($N_\lambda = 10$ as longitudinal grid spacing, could be done more fine)
  • slightly different results when propagating the pulse with the angular spectrum method (as in the preparation routine) compared to a Maxwell solver (here, Yee has been used)

As another test, the beam energy has been calculated. The Original Insight data pulse had an energy of 4.5 J and the energy of the same pulse in PIConGPU was about 2 - 3% less (using the Yee solver), which could be improved by a finer sampling.

fabidie avatar Jul 30 '24 14:07 fabidie

@fabidie Our CI is unhappy with the code formatting, you ned to run the code formatting tools to fix most and fix the remaining code style issues.

Please install the pre-commit code formater hooks as described here and run pre-commit run --all-files in your repository afterwards.

BrianMarre avatar Jul 31 '24 08:07 BrianMarre

@fabidie I rebased our PR and pushed it again to fix CI issues

psychocoderHPC avatar Aug 20 '24 18:08 psychocoderHPC

@fabidie please do not forget to rebase the PR to the current development branch

psychocoderHPC avatar Sep 05 '24 10:09 psychocoderHPC

I have set this PR to draft. IT shows always green but is not ready to be merged.

Never the less we added many changes to the dev branch therefore a rebase is required.

psychocoderHPC avatar Sep 27 '24 12:09 psychocoderHPC

I closed this one because there happened too much the last 14 days and rebasing is a mess. There is a new one though.

fabidie avatar Oct 01 '24 09:10 fabidie