ToDo in laser refactoring

[steindev]

Since the implementation of the lasers is in parts at the least confusing and sometimes inconsistent, it is going to be refactored. The following action items are foreseen:

• check if all separable lasers have a correct phase calculation
• refactor BaseFunctorE:
  • move getCurrentTime() into struct BaseSeparableFunctorE 👈 don't do it, according to the variables used, this is a base class functionality
  • rename this 👆 function to getTminusXoverC() in order to reflect its purpose
• remove the laser cutoff, as it is wrong. Laser phases and envelopes should be computed for all times at all positions on the incident field plane.

// Cut off when the laser has not entered at this point yet to avoid confusion.
if(time < 0.0_X)
    return float3_X::create(0.0_X);

• Remove Wavepacket laser, as it is almost identical to PlaneWave? Except for the transverse Gaussian Envelope. Is it possible to at least reuse the plane wave laser implementation? Similar to the pulse-front tilt for the Gaussian? But why not use the gaussian instead of wavepacket for lasers with transverse envelope?
• Remove the pulse-front tilt feature in the standard Gaussian laser? It is not physical anyways, since we do not know how pulse-front tilts propagate for Laguerre-Gaussian modes, and for standard Gaussian pulses there is the DispersivePulse implementing the feature correctly.
• check if lasers define variables in their Params struct again although these are already defined in their BaseParam struct (happens at least with LASER_PHASE in wavepacket laser)
• since all lasers have define a focus (via BaseParam), the laser internal coordinate system should be relative to the focus position and not the origin (the former being the typical way of describing laser fields analytically).
  getInternalCoordinates() is only used in DispersivePulse and GaussianPulse anyways.
• reimplement Gaussian laser in order to have correct phases and envelope computation
  • allow for different width along the transverse axis (cf. polynom laser)
• refactor DispersivePulse:
  • check the time delay computation in the DispersivePulse for correctness wrt to BaseFunctorE internal coordinates and time
  • check correctness of the sign of the phase computation. Is fine, but focusPos has the wrong sign, which is properly accounted for in the DispersivePulse implementation
  • move computation of internal coordinates from amp() and phi() to getValueE()
    • when doing so, change focusPos to focusDis and take the proper sign (i.e. switch)
  • make dispersion axis parallel to polarization
  • Update comments according to other branch
  • shorten computation of magnitude in amp()

    // Normalization to Amplitude
    mag *= math::sqrt(pmacc::math::Pi<float_X>::doubleValue * 0.5_X) * 2.0_X
        * Unitless::PULSE_DURATION * Unitless::AMPLITUDE;
    
    // Dividing amplitude by 2 to compensate doubled spectral field strength
    // resulting from E(-Omega) = E*(Omega), which has to be fulfilled for E(t) to be real
    mag *= 0.5_X;

• rename Unitless::w -> Unitless::OMEGA0 (since there is confusion in the Gaussian profile with the width)
• does accessing Unitless::LASER_PHASE really work if it is defined in a mother::mother::mother::mother class?
• fix grammar errors:
  • PlaneWave.def:
    • l. 59: fulfulled
    • l. 42: PULSE_INIT -> RAMP_INIT in documentation OR rename parameter. PULSE_INIT is used in all other profiles.
  • PlaneWave.hpp:
    • l. 124: Unitless::RAMP_INIT does not exist (but Unitless::INIT_TIME)
    • l. 146: altough announced, there is no description of formula -> ask @PrometheusPi
  • BaseParam.hpp:
    • l.150 coordinate
  • Functors.hpp
    • l.142 coordinate
    • l. 308 comma missing after 'However'
  • Wavepacket.def:
    • l.70: LASER_PHASE is defined here and in BaseParam, too!
  • Traits.hpp:
    • l. 27 non-zero
    • l. 24: Huyhens -> Huygens
    • l.39: short-hand

[steindev]

Issues encountered during testing of the refactored implementation:

• 1. Why is the refactored GaussianPulse not producing any field?
  • Miscalculation of timeDelay variable plus not taking this variable into account at all.
  • Additionally the amplitude had wrong factors in its compute instruction.
• 2. Implement time-space domain clipping of DispersivePulse (and possibly GaussianPulse) because a field is fed into simulation from wrong boundaries if activating incidentField on all boundaries
• 3. Why is there reflection from a boundary with activated incidentField on that boundary and no reflection when inactive?
  • psychocoderHPC agrees to BrianMarre's suspection below since he has heard of this issue before

[steindev]

Regarding 3: @BrianMarre speculates, that this can be due to the superluminal part of the field propagating in front of the pulse which takes energy from the regularly propagating part such that the theoretical perfect cancellation on the incident plane overcompensates instead.

Initial GaussPulse traveling from -y to +y. Colorbar is clipped at 2x10^-7. Amplitude of the laser is 1.
(The focus of the laser is in the center of the simulation volume)

incidentField only on y-min activated:

incidentField on all boundaries activated:

The posterior-like structure is the reflection of the initial laser pulse traveling from +y to -y, being created when the laser arrives at the +y boundary.

[steindev]

Stray fields for obliquely propagating lasers

Another issue observed during testing is the presence of stray fields for obliquely propagating lasers.
For example for propagation from y center to x center with x-y-polarization.

For z-polarization it looks different but equal on a qualitative scale.

[steindev]

Wave excitation in front of the DispersivePulse

Another issue observed during testing is the presence of a (relatively low amplitude) wave excitation in front of the DispersivePulse.

(old implementation)

This case is for 20 spatial samples per wavelength, standard time step according to CFL DELTA_T = 0.995 * CELL_HEIGHT / (SPEED_OF_LIGHT * SQRT_3), PULSE_INIT = 17, and SPECTRAL_SUPPORT = 4.

Initially, I thought the sampling of the spectrum is too bad. Which can, on the one hand, happen due to too sparse frequency sampling where the spectrum has significant values, or, one the other hand, due to truncating the evaluated frequencies in the spectrum too early such that not all significant frequencies are taken into account in the field computation.
While the former can be remedied by increasing the frequency sampling, which scales as DELTA_OMEGA = 2 pi / (PULSE_INIT * PULSE_DURATION), the spectral support can be adjusted directly.

However, there is only slight improvement by increasing both values.

(PULSE_INIT = 20, and SPECTRAL_SUPPORT = 8)

Interestingly, smaller SPECTRAL_SUPPORT = 6 with small PULSE_INIT = 17 actually looks better.

My other suspicion was that the computation relies on the speed of light. But replacing the ideal vacuum speed of light with the actual numerical speed of light did not change the situation.

Currently, I am at a loss for explanations of the source of the initial excitation. Though I believe, it appears due to the fact that the first non-zero field values at the Huygens surface are too high. But if so, increasing either PULSE_INIT or SPECTRAL_SUPPORT should have changed the situation...

For reference, a direct comparison between DispersivePulse (left) and GaussianPulse (right) with the same parameters.