PIC to Geant converter

[berceanu]

Hello,

I was playing with the idea of a new repo for a PIC to Geant4 converter for the benefit of the community. I think a common workflow that we all encountered is using the electrons from an LWFA PIC setup as a source in Geant4, in order to compute, say, Bremsstrahlung emission from a secondary foil target and so on. One has to take into account the macroparticle weights for this, of course, and the "brute-force" way of doing is, if a particular weight is 1000, to generate 1000 "real" electrons in Geant with that momentum and initial position. To include all the particles in this way becomes quite computationally heavy, so one approach is to sample them. The simplest method would be to divide the weights by a constant factor, say, 50, or by the minimum weight in the PIC output file, and then generate the Geant4 electrons. A more refined approach would be to use one of the particle reduction / merging algorithms and give it a target, say, reduce the PIC output file to 100k particles, without altering the distribution shape in the 6D momentum-position phase space.

What do you think? I see this repo contains quite a number of particle reduction methods, which would you say is more suitable to this application? Before finding this repo, I was considering a simple kNN approach, and I see that is included as well. I'm curious how the various methods stack against each other. I see that for PIConGPU you chose the method based on
Luu, P. T., Tueckmantel, T., & Pukhov, A. (2016). Voronoi particle merging algorithm for PIC codes. Computer Physics Communications, 202, 165-174

[sbastrakov]

Hi,

I believe no one is working on this anymore, for a few years now. So I would imagine it's easier to make your own (idk, perhaps with openPMD people?), perhaps looking here as well but not reusing as-is.

PIConGPU implementation that you mention is way older than this project, and is rather loosely based on the paper you cite (I think for the sake of GPU friendliness and internal PIConGPU reasons). I've just checked that it is no longer part of PIConGPU dev branch either ComputationalRadiationPhysics/picongpu#4388.

[berceanu]

Hi @sbastrakov thanks for the update! Perhaps @PrometheusPi or @KseniaBastrakova can comment on the physics-related questions above?

[berceanu]

ping @PrometheusPi :))

[PrometheusPi]

@berceanu I definitely see the same problem of the need to reduce the number of particles for a further processing - might it be GEANT4 or any other particle based process.
Regarding the phase space convergence, the Voronoi particle merging algorithm seems very suitable. But as already mentioned by @sbastrakov, there is no one actively working on this anymore in PIConGPU. However, it works and has a medium priority in our dev team. (But if you start opening pull request, we will look into them.)

Regarding your bremststrahlungs problem, I would actually would not see accurate phase space sampling as a major issue, but think sampling the particles with the highest yield would be more suitable.

I have the impression I missed a major "physics questions". If that's the case, please let me know.

[berceanu]

@PrometheusPi thanks for your input. What do you think about thinning methods, as described in this paper, in particular globalLev? They appear much less computationally demanding compared to merging.

Is the Voronoi particle merging algorithm implemented at a global level or on a per-cell level? I was looking for a global solution, because it seems to me that any per-cell implementation can't go below 1 (macro)particle per cell, right?

[berceanu]

I've recently uploaded a repo on this, and will probably continue development there. Thanks again, and any feedback is greatly appreciated!

[PrometheusPi]

Sorry for the late reply @berceanu - over the summer holidays, I forgot about checking this thread.
Yes, due to the requirement of local neighborhood in 6d phase space, Voronoi particle merging algorithm will not reduce an already sparse (spatial) sampling. The 1 particle-per-cell is, if I remember correctly, not a hard limit.

Thanks for linking your repo. This looks very interesting.