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

[psychocoderHPC]

I moved this issue again to the next release. @PrometheusPi is this issue still existing?

[PrometheusPi]

Good question! @finnolec could you please comment on your plugin?

[finnolec]

It's been a while since I used this plugin and I don't really remember this error... But from what I gathered by reading through all the messages here, this error only occurs when you try to calculate the transition radiation without any valid, radiating electrons (valid means that their velocity is larger than gamma > 1 and larger than the filter function). So as long as you have a filter function, which checks for non still standing particles, but includes the accelerated electrons from the simulation (1 < filterGamma < max velocity from electrons), this plugin should work as expected.

So the plugin does not catch NaN's by itself to my knowledge. But I think it's usually the user's fault if it even generates NaN's... If the issue is just, that there is no comment like "Don't remove the gamma filter! Still standing electrons generate NaN's in the output of the plugin and transition radiation is scaling by \propto \gamma^2" in the .param file, it should be fixable :)

[psychocoderHPC]

Activating the gamma filter will not solve the problem if it is a division by zero. The filter is activating tracking, if the particle is slowing down for any reason and stop then it will still be activated and create NaNs. It is more unlikely with the gamma filter but not solving the issue.

[PrometheusPi]

@psychocoderHPC thanks for the input - does that mean that if a particle once exceeds the gamma filter, it will remain active. Because gamma=1 is equivalent to a zero velocity (at that instance).

[psychocoderHPC]

@psychocoderHPC thanks for the input - does that mean that if a particle once exceeds the gamma filter, it will remain active. Because gamma=1 is equivalent to a zero velocity (at that instance).

It depends on how the filter is written but the default filter is only enabling radiation for a particle. It mechanism we use in the radiation plugin, I assume this way is used to avoid that a particle is one step active and the next not, this could produce noise in the output.

[PrometheusPi]

Yes, this is how we have to do it for the radiation plugin, since it performs a time integration and missing steps in a time integration messes up the Nyquist criteria. For the transition radiation plugin however, there is no time integration, and (as far as I understand it) the filter is the standard instantaneous filter used e.g. also for other plugins. Is this correct @finnolec? If the latter is true, having a gamma > 1.0 filter would prevent considering resting particles. However, I would tend to include this check by default into the plugin, if this is the sole cause for errors. (Since having an all filter, would break the plugin.)

[finnolec]

For the transition radiation plugin however, there is no time integration, and (as far as I understand it) the filter is the standard instantaneous filter used e.g. also for other plugins. Is this correct @finnolec?

Yes there is no time integration. The plugin is called once in every timestep it's used and then it calculates the whole transition radiation spectrum in this timestep. I'm not sure what you mean by "instantaneous filter". I compared the filters from the radiation and the transition radiaton plugin right now and they look very similar to me (transitionRadiation.param and radiation.param, respectively transition radiation ExecuteParticleFilter and radiation ExecuteParticleFilter). So the implementation looks quite similar to me in both radiation plugins, but I didn't compare it to other plugins yet.

If the latter is true, having a gamma > 1.0 filter would prevent considering resting particles. However, I would tend to include this check by default into the plugin, if this is the sole cause for errors. (Since having an all filter, would break the plugin.)

I think the idea for the filter in the param file instead of the plugin directly was, that the user can decide how many slow-moving particles they want to use. This means the user could calculate the transition radiation in a low energy simulation (although I'm not sure how relevant this actually is) and the user can set a large gamma value in the filter for a high energy simulation, to improve calculation time (because low energy electrons don't matter then). But if this flexibility is not needed, it makes sense to put it into the plugin.

[PrometheusPi]

Okay - due to the not required time integration, using an approach as the radiation plugin is using is not really needed for the transition radiation. A common filter without explicit particle flag attributes that tracks the result of the filter should be fine.