Closed cr-xu closed 1 year ago
I was actually thinking about the same, because it would also open the door to crude space charge estimations. I would prefer more descriptive variable names (e.g. total_charge
) though. Or in Bmad they choose the charge based on particle species, which is also interesting.
total_charge
sounds good. I would still decouple the charge
from the particle species because the idea of using macroparticles is that each one of them would represent N real particles.
Good point. If we want to, an option would be to later introduce sort of a macro ... where you can pass the species and it will figure out the per particle charge on its own.
I would actually say, both beam classes get a parameter and argument charge
. ParameterBeam
just saves this. ParticleBeam
if only charge
is passed derives num_particles
from that, assuming electrons for the time being. The other way round, if you only pass num_particles
, it figures out the charge. If you pass both, it just takes them as passed. And then maybe ParticleBeam
should have an @property
for single_particle_charge
(I prefer this to total_charge
).
Thoughts?
That's not necessarily the case, in a lot of particle tracking codes, one macroparticle actually represents a collection of particles.
So it's allowed to have different charge q
per macroparticle, even in most of the cases the macroparticles contain the same charge $q = Q\text{total}/N\text{macro}$.
The totalcharge (physical quantity) is not related to the number of macroparticles used for tracking ( which is chosen as a tradeoff between computational resources and the accuracy of simulation)
The true number of electrons is derived $N\text{e} = Q\text{total}/ q\text{e}$
This is probably an important feature that is overlooked.
Since
ParticleBeam
tracks macroparticles, it might make sense to add acharge
associated with each particle. This could open possibilities for additional physical process modules (collective effect etc.).ParameterBeam
will just have something like aq_total
.