Specialize ADK for linear or circular laser polarization

[n01r]

The ADK model has been updated so that now the user is given the choice between the linear and circular polarization case, according to Delone, Krainov 1998 Phys.-Usp. 41 469.

[n01r]

Compiles and runs.
Checking against experiments when I find the time. ^^;

[bussmann]

+1

[PrometheusPi]

Could you check laserProfile::Polarisation to decide for whether one should use

• linear laserProfile::Polarisation<=2u or
• circular laserProfile::Polarisation==4u?

[n01r]

Sadly not all laser profiles are using this enum type, yet. Until then I thought it's better to have two independent realizations of ADK.

[PrometheusPi]

you mix British and American english in ionization/ionisation and polarization/polarisation.

[n01r]

my apologies 🙇 ... it's an internal conflict
will fix that

[PrometheusPi]

since this line is the only difference between AlgorithmADKCircPoland AlgorithmADKLinPol, but the code for AlgorithmADKLinPol takes about 120 additional lines, could you create a AlgorithmADKPol<...>that takes a template argument to switch between both cases? That would reduce the code duplication dramatically.

[n01r]

I now pass a boolean value as a template parameter that activates the calculation of the additional polarization factor for linear polarization or leaves it out for circular polarization. As we discussed offline before: we cannot just check for the polarization so easily because the laser could be initialized via an HDF5 input file.

[PrometheusPi]

This is still a run-time decision thus is not as efficient as possible.
Just use:

float_X polarizationFactor = TEMPLATE_PARAM::polarizationFactor;

with a struct containing the value not just a bool.

[n01r]

The value is not const so I cannot just calculate it during compile time (it depends on the ionization potential and the electric field strength). Nevertheless, it is known if the bool is true or false during compile time. Therefore the compiler should optimize the code in such a way that the unnecessary code vanishes.

[n01r]

@psychocoderHPC
your verdict?

[psychocoderHPC]

@PrometheusPi Your suggestion is not possible because like @n01r said the factor is only known at runtime.

A possible solution would be to add a functor for the factor calculation but it is a little bit complicated because of the needed input values.

My suggestion: (small design change)

/* ionization rate */
float_X rateADK = polarizationFactor \
                * eInAU * util::square(dFromADK) / (float_X(8.0) * pi * protonNumber) \
                * math::exp(float_X(-2.0) * util::cube(protonNumber) / (float_X(3.0) * util::cube(nEff) * eInAU));

if(T_linPol)
{
    /* factor from averaging over one laser cycle with LINEAR polarization */
    const float_X polarizationFactor = math::sqrt(float_X(3.0) * util::cube(nEff) * eInAU / (pi * util::cube(protonNumber)));
    rateADK *= polarizationFactor;
}

Then the code is better readable.

[n01r]

👍 Yep, looks good to me. I think it's okay to stay away from overcomplicating things and not introduce a new functor for this.

[PrometheusPi]

please remove this line as discussed offline

[PrometheusPi]

physics looks OK to me 👍