Picongpu: transition radiation plugin produces NaNs

[PrometheusPi]

Currently the transition radiation plugin introduces with #3003 produces NaNs for example in the LWFA simulations for @OmidZar. This is most likely caused by a division by zero as documented in the gamma filter section of the read the docs documentation.

This (hopefully) can be avoided in the LWFA case by increasing the gamma value of the filter (I will try 5 -> 20) but this is not a general solution.

As discussed offline with @psychocoderHPC, such divisions by zero should be stopped in the kernel (if case is fine, as long as no extra code is executed and only contribution to summation is stopped).

[PrometheusPi]

The issue I have encountered was probably caused by a nPhi = 1. Should we catch that or is this wrong-usage?

[sbastrakov]

I do not have a good idea about the plugin, but since nPhi is a constexpr you can control that it is in a valid range at compile-time with static_assert (or better a pmacc wrapper around it).

[finnolec]

@sbastrakov's idea sounds good.I will try to add an assertion and add a comment to the param files. The same should happen if you just detect in a single azimuth direction nTheta = 1 due to the way how the observation directions are finally calculated in transitionradiation.param.

[finnolec]

I think I'll do it without an assert and just program border cases, if nPhi or nTheta are equal to one, so that it'll automatically use phiMin and thetaMin as the observation angle.

[sbastrakov]

Sure, this looks reasonable.

[PrometheusPi]

I found out in some production runs, that the CTR is non-zero even though no electron passed the gamma limit of the gamma filter yet.

Blue line marks onset of CTR. Colormap shows electron energy evolution. Gray lines show CTR output periodicity. And the hight of the gray lines is the gamma limit.

[PrometheusPi]

I ran a test based on the default transition radiation example.
I fixed the filter gamma value to 20 and changed the gamma of the bunch from 30, to 15, to 5. My expectation was, that only the first case would produce non-zero CTR, but all produced radiation.
@finnolec What did I do wrong?

[sbastrakov]

@PrometheusPi is this issue (the latter one, with gamma filter not working properly) connected to #3105 ?

[PrometheusPi]

Most likely - @finnolec could not produce NaNs with the default LWFA setup and the fix from #3105 - I will rerun a simulation on taurus/ml to test whether there NaNs occur with this fix.

[sbastrakov]

@PrometheusPi thanks. And what about this issue? Sorry, I later edited my previous message.

[PrometheusPi]

@sbastrakov Yes - this issue (= #3090) documented NaN production in the CTR plugin.
This was/will be solved with:

• #3091 - prevents NaNs due to user fault by allowing single angles
• #3105 - activate filter (could be linked to NaNs - has to be tested)

The question is, whether there are still more causes for NaNs, since NaNs should be captured in the plugin itself. I have the impression, that the filter will not entirely prevent NaNs - but this feeling is just based on the simulation on taurus, where the filter was not working and the CTR plugin generated NaNs.

[PrometheusPi]

So please leave it open for now.

[finnolec]

Yes, I couldn't create NaNs with #3105 and the default LWFA setup and a gammafilter which is equal to filterGamma = 1.0. This means it should also have considered stationary electrons in the calculations, which were most likely the cause of the NaNs.

[psychocoderHPC]

@PrometheusPi Is this issue already solved?

[PrometheusPi]

No, it is not solved. But it is quite hard to find a suitable test case.
Please leave this issue open.

For all users that use this plugin: just apply a gamma filter to the particles. This prevents the NaN creation and usually should be fine when computing transition radiation from high energy electrons.

[sbastrakov]

@PrometheusPi perhaps this should be clarified in the transitionRadiation.param or elsewhere? Sorry if it already is, just from a short look seemed like not the case

[PrometheusPi]

@sbastrakov I agree. (I hoped to find the bug sooner.)

[psychocoderHPC]

I moved this PR tp the next release