Picongpu: constexpr error in bremsstrahlung

[PrometheusPi]

With the introduction of #3176, the PIConGPU jupyter services fails building due to the following error:

.../picongpu/include/pmacc/../picongpu/particles/bremsstrahlung/ScaledSpectrum.tpp: In member function 'picongpu::float_64 picongpu::particles::bremsstrahlung::ScaledSpectrum::dcs(picongpu::float_64, picongpu::float_64, picongpu::float_64) const':
.../picongpu/include/pmacc/../picongpu/particles/bremsstrahlung/ScaledSpectrum.tpp:98:69: error: '(-1.02349284e+21 * -1.02349284e+21)' is not a constant expression
     constexpr float_64 classicalElRadius = float_64(ELECTRON_CHARGE*ELECTRON_CHARGE) / (pi * 4.0 * EPS0 * ELECTRON_MASS * SPEED_OF_LIGHT*SPEED_OF_LIGHT);
                                                    ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~
.../picongpu/include/pmacc/../picongpu/particles/bremsstrahlung/ScaledSpectrum.tpp:99:73: error: '(-1.02349284e+21 * -1.02349284e+21)' is not a constant expression
     constexpr float_64 fineStructureConstant = float_64(ELECTRON_CHARGE*ELECTRON_CHARGE) / (pi * 4.0 * EPS0 * HBAR * SPEED_OF_LIGHT); 

The only difference in the configuration (on hemera) is that c-blosc is not loaded, which should not cause this error.

cc'ing @jkelling @ax3l

[psychocoderHPC]

It could be an nvcc bug we saw in the past with DELTA_T. The workaround was to add a intermediate variable inside of the functor.

constexpr float_64 electron_charge = ELECTRON_CHARGE;
constexpr float_64 classicalElRadius = (electron_charge * electron_charge) ...

[sbastrakov]

(Not important) @psychocoderHPC 's suggestion removes the explicit type case, perhaps it would be a tiny bit better to write, also having camelCase, constexpr float_64 electronCharge = float_64(ELECTRON_CHARGE); or using a more modern constexpr float_64 electronCharge = static_cast<float_64>(ELECTRON_CHARGE); or even the AAA-complying constexpr auto electronCharge = float_64{ ELECTRON_CHARGE };

[PrometheusPi]

I will first try to reproduce this compile time error on hemera outside the PIConGPU-jupyter environment. If it occurs, I will provide a pull request based on your (@psychocoderHPC and @sbastrakov ) suggestions.
If the error occurs on hemera, the question is, why the compile suite did not catch it.

[psychocoderHPC]

Please handle this with high priority so that we can start the release for PIConGPU 0.5.0

[PrometheusPi]

I could not reproduce this bug right from the current dev with my setup. But I can reproduce it with the jupyter system, despite using the same code version.

[PrometheusPi]

The compile time error induced by changes in #3176 is caused by a out of bounds value of the product result marked above that was caused by incorrect input parametrs.

The PARAM_BASE_DENSITY_SI was set to ~1.4 by the parameter generator despite requiring something in the >10^24 range.

The error occurred in the multiplication ELECTRON_CHARGE*ELECTRON_CHARGE because ELECTRON_CHARGE is defined as

constexpr float_X ELECTRON_CHARGE = (float_X) (SI::ELECTRON_CHARGE_SI / UNIT_CHARGE);

with SI::ELECTRON_CHARGE_SIbeing 1.6e-19 and UNIT_CHARGE being:

constexpr float_64 UNIT_CHARGE = -1.0 * SI::BASE_CHARGE_SI * double(particles::TYPICAL_NUM_PARTICLES_PER_MACROPARTICLE);

with SI::BASE_CHARGE_SI being the same as SI::ELECTRON_CHARGE_SI (1.6e-19) and particles::TYPICAL_NUM_PARTICLES_PER_MACROPARTICLE being

constexpr float_X TYPICAL_NUM_PARTICLES_PER_MACROPARTICLE =
    float_64( SI::BASE_DENSITY_SI * SI::CELL_WIDTH_SI * SI::CELL_HEIGHT_SI * SI::CELL_DEPTH_SI ) /
    float_64( particles::TYPICAL_PARTICLES_PER_CELL );

with SI::CELL_WIDTH_SI * SI::CELL_HEIGHT_SI * SI::CELL_DEPTH_SI being the cell volume of (in this case) 1.4e-21 and TYPICAL_PARTICLES_PER_CELL being (in this case) 2.

Thus, the product ELECTRON_CHARGE*ELECTRON_CHARGE depends on SI::BASE_DENSITY_SI as:

~ 6.3e42 / BASE_DENSITY_SI^2

This is for BASE_DENSITY_SI approximately around 1 = 10^42 and thus much higher than the maximum float32 value of 10^38.

Despite being generated at a strange place, this error is a great example why using constexpr in this place is a good choice. It catches a setup error.

@psychocoderHPC and @sbastrakov I am fore keeping it as is. One workaround would be

---     constexpr float_64 classicalElRadius = float_64(ELECTRON_CHARGE*ELECTRON_CHARGE) / (pi * 4.0 * EPS0 * ELECTRON_MASS * SPEED_OF_LIGHT*SPEED_OF_LIGHT);
+++     constexpr float_64 classicalElRadius = float_64(ELECTRON_CHARGE)*float_64(ELECTRON_CHARGE) / (pi * 4.0 * EPS0 * ELECTRON_MASS * SPEED_OF_LIGHT*SPEED_OF_LIGHT);

What do you think?

[PrometheusPi]

offline discussion with @sbastrakov and @psychocoderHPC:
We will not avoid this compile error since it points to a bad configuration.