ascot4fusion / ascot5

ASCOT5 is a high-performance orbit-following code for fusion plasma physics and engineering
https://ascot4fusion.github.io/ascot5/
GNU Lesser General Public License v3.0
31 stars 9 forks source link

Scale markergen to represent all particles #120

Open BCHamstra opened 2 months ago

BCHamstra commented 2 months ago

If I understand it correctly, ascot adds the states of markers to the histogram at every time step. This can result in significantly more cells being filled with particles than there were markers to generate said particles. If the resulting histogram is then used to generate markers for a subsequent ascot run, the number of markers generated should be at least as big as the number of 'filled cells' to represent all particles. Were this is not the case, a subset of particles would be represented and the amount would be inversely proportional to the number of grid cells. This is annoying to deal with and can influence the results of those unaware.

I propose to scale the weight of markers to let them properly represent their particle distribution. I believe this can be achieved by adding a line in ascot5/a5py/routines/markergen.py. For example after the weights are shuffled (weight = weight[idx].ravel(), line 114):

weight = weight * np.sum(particledist.histogram()) / np.sum(weight)

Initial testing seems promising.

Otsooni commented 1 month ago

Can you clarify to me the advantages of this reweighting?

I would find it highly confusing for a sampled distribution to not agree with the distribution from which it was sampled. For a case in which the sampling was done for too few markers (or all bins with particles were not taken into account), I would rather have the sampled bin(sampled markers corresponding to the distribution) to have precisely the same weight as the bin.

For example, given a fusion alpha birth distribution sampled with an edge localized probability distribution, the resulting marker distribution would be edge weighted, and maybe only few markers were initialized at the magnetic axis where the weight is largest. Reweighting this could add orders of magnitude larger weights to the edge localized markers.

That said, I also have some considerations on if some flags should be implemented to notify on large discrepancies between number of sampled markers and the number of populated bins in the distribution. Maybe statistically significant bins(for example bins that hold 95% or more of the probability distribution) could be checked if they are included in the marker generation.

BCHamstra commented 1 month ago

Ah, I see your point. I am looking at the 14.1MeV neutron production from beam-target fusion in a stellarator. So BBNBI produces a deuterium source, which goes through ASCOT, reacts with deuterium plasma in AFSI to produce tritium, which is then sampled for another ASCOT run to finally get the neutrons from a DT-reaction in AFSI. So I need to include most if not all generated particles to get a good estimation of the resultant neutron distribution with respect to the input beam.

I noticed that I need a large number of bins for accuracy, though cannot afford to have enough markers to sample from all those bins. Thus these markers only represent a subset of what I need. Admittedly, I did forget about using a different sampling distribution. However, my deuterium distribution is quite wide and while the core is likely the most relevant, I would rather not make that distinction prematurely. Especially as I intend on testing different configurations/devices. This lead to my suggestion for reweighing.

Perhaps adding it as an option to the generate method to allow a user to choose which behaviour they want? Regardless, adding a warning if a significant number of particles are excluded seems helpful.