Particle Attributes: Scaling with Weighting about openpmd-standard HOT 7 CLOSED

The General Standard

That is a very good question, thank you!
I think the pure dimensionality of \gamma \beta it is much less of a problem as you think, but I noticed the same problem but more concerning if the weighting of a particle is included in momentum (e.g., currently it is not in charge/mass but in momentum it stands for the macro particle). Nevertheless, that is something for the ED-PIC extension, let us move that back for a second to explain the general scheme.

Coming back to your original question: the nice thing is, that it does not matter if you store it internally unitless or not. All that matters for the unitSI and unitDimension is the final converted SI quantity it represents - and that is always of dimensionality [mass] [length] [time]^-1 when we are talking about momentum.

Three examples:

• code A stores electrons in $m \gamma v$ (with m the mass of the whole macro particle)
  -> unitSI accordingly as scaled in your code (e.g., times m_e * speed of light)
  -> unitDimension is mass * length / time
• code B stores particles internally in $\gamma \beta$
  -> unitDimension is still mass * length / time, since it describes the converted values
  -> unitSI would for particles with the same weighting (and STANDARD.md does not know of weightings) be: the value of mass * speed of light for that species
  -> major disadvantage: one can not specify a common unitSI if the weighting varies for particles in that species
• code C stores photons scaled to their bare wavenumber
  -> unitDimension is still mass * length / time, since it describes the converted values
  -> unitSI would be the Planck constant

Since momentum or weighting are not specifically defined in STANDARD.md it is not up to the general standard to solve the problem with \gamma \beta - codes only implementing that part must store the momentum in (scaled) quantities of the macro particle (since the constituents of macro particles are not known to it).

The Question Arising in the ED-PIC Extension

The actual question is: for the ED-PIC extension, specific records such as momentum, weighting and mass, which are not properties useful for general particle records such as they are used in particle based image algorithms, are defined. How to define particle records that scale (not only linear) with that weighting? Let's play the examples:

CASE 1: all particle records describe a particle of weighting 1 - each user has to take care reading the weighting record too, e.g., when accessing a record such as momentum, charge or mass. Code B is well defined for momentum as soon as the unitSI is the single particle mass * c, but storing properties that are not linear in weighting such as a particle record "power, coherently radiated over time" scales quadratic with the number of particles (read: non-linear in weighting). But if one defines that weighting must be read and multiplied (linearly), once could specify that the stored value without the weighting has not necessarily a correct physical meaning (for such cases). A constant particle property such as the record charge can simply be stored with the replacement scheme.

CASE2: all particle records describe the particle properties according to a particle with a weighting as stored in the weighting record (the backwards-compatible approach to STANDARD.md since each record describes the macro particles that were actually computed). For varying weighting in a species, constant records such as mass or charge can not simply be stored as a single value and require a full record with arrays - that's not cool.

In case of PIConGPU it's currently even a bit more confusing, we store particle properties such as charge and mass regarding 1 particle (because they are usually constant for a species) but unfortunately store the momentum scaled with weighting to avoid reading the latter when not desperately needed (e.g., only for actual charge counters or radiation calculation).

To Conclude

Only position is a generic particle record in STANDARD.md - the question is up to the ED-PIC extension.

Codes might internally choose one way or an other to store and scale quantities with weighting and momentum - imposing a linear scaling and storing results regarding 1 or regarding weighting might require large-scale multiplications during outputs, which unitSI and unitDimension try to avoid for performance reasons.

Solution 1: New ED-PIC Attribute per Particle Record

Since weighting is introduced and defined in the ED-PIC extension, an additional attribute powerWeighting of type (double) per particle record (for each property that is not weighting). The value could be 0.0 (no need to read weighting), 1.0 (linear with weighting - read and multiply the result with that record) or something else (0.5 with sqrt of weighting, 2.0 quadratic with weighting).

The actual quantity would be for ED-PIC records:

# e = getGroupFromFile(...)
momentum_macro = e["momentum"][:] * e.attrs["unitSI"]
if e.attrs["powerWeighting"] != 0.0:
    momentum_macro *= e["weighting"][:] ** e.attrs["powerWeighting"]

Of course on can also just add a flag that imposes "scale linear with weighting" or "neglect weighting record, I am already scaled" to be a bit less general.

from openpmd-standard.

I like \gamma\beta as it is unitless and behaves well numerically.

from openpmd-standard.

Thanks Axel and Michael for your answers.
I had completely forgotten about the UnitSI attribute, so you're right : the most convenient is definitely to output the momenta in unitless form, and to add the conversion factor.

Regarding the scaling with weighting, I understand the point you are making. I guess this should be discussed first and then maybe introduced in a future release of OpenPMD. (I'm reluctant in part because the scaling of e.g. the radiation with the weighting - although consistent with the PIC description - may in some cases be unphysical. So it is not clear whether it is good practice to introduce this scaling in the standard, where users may use it without any critical thinking.)

from openpmd-standard.

Thanks for the feedback!

Let me allow to re-open this issue since it just pointed me on a problem that codes such as ours might not consequently store all particle records with the same weighting. We might actually need that little flag in the ED-PIC extension simply to avoid multiplying large chunks of data.

(Independent of a bit unusual and futuristic particle records that might not scale linearly with the weighting.)

from openpmd-standard.

problem with powerWeighting: even with and without it, it is not identical to the statement "this record is defined for the macro particle or for a single particle".

ignoring weird, non-linear in weighting records, it might be more useful to just define "weighted" 0/1. Unfurtunately, this makes only sense for mass, charge, momentum not for id, position, color, ...

from openpmd-standard.

status of this issue: @RemiLehe initial question will be solved (assigned) by being more explicit in the wording.

... and:

from openpmd-standard.

In the end, I think every particle record should have 2 attributes:

• weightingPower : says how the quantity scales with weight (e.g. position has weightingPower=0 and momentum, charge have weightingPower = 1)
• macroWeighted : says whether the outputted quantity has been written for an individual particle or for the full macroparticle. To switch from one description to the other, one uses weightingPower.

from openpmd-standard.