Units should not be forced to SI

[mccoys]

We [the Smilei developers] would like to propose a change that was discussed a little somewhere else: specifying units in SI could be optional. In particular, this concerns the attributes timeUnitSI (in basePath), gridUnitSI (of each mesh record) and unitSI (of each Record Component).

We know that this possibility has found significant opposition here, but we would like to expose clearly the reasons, and a possible solution.

Why optional units?

From our perspective of PIC code developers and users, most of the simulations we run are scalable by some arbitrary factor. This is due to the Maxwell-Vlasov system of equations having a natural set of units: times, lengths, electromagnetic fields, densities and currents may be expressed in a normalized (unit-less) manner. They all depend on each other, but there is no absolute value of these quantities. In fact, the result of the simulation can be scaled using one arbitrary number, as long as each of the quantities above have been scaled in the correct way, with the correct exponent. Typically, in the case of the code Smilei, we have chosen this number to be in the dimensions of an angular frequency Wr. The simulation times are in units of 1 / Wr, distances in units of c / Wr, densities in units of ε0 m_e Wr^2 / e^2, etc. The results of the simulations can be scaled by these factors. For instance, if you multiply all times by 2, then you also have to multiply distances by 2, and densities must be divided by 4.

This does not apply to PIC simulations with additional physics which require an absolute system of units (ionization, collisions, QED, etc.) but this case is trivial.

It turns out that many PIC codes disregard the fact that the PIC equations are naturally scalable by some factor, and impose some absolute units. In our opinion this is too restrictive. We don't mean PIC codes should change, but OpenPMD should respect the variety of codes that use meshes and particles in order to broaden its scope.

How to specify the simulation scaling?

Electromagnetic PIC codes are not the only ones that can be scaled. It is also the case for Vlasov codes, electrostatic [Poisson-Vlasov] codes, and, to some extend, hydro codes. Even though EM-PIC codes have only one scaling factor, in general, there may be more (e.g. two factors for Poisson-Vlasov codes).

We thus propose new optional attributes as follows:

• in basePath, a new timeUnitScalings attribute
• in each mesh record, a new gridUnitScalings attribute
• in each Record Component, a new unitScalings attribute

These new attributes should each be a list of floats. They must all have the same number of elements. Each element represent the power at which a scaling factor should be taken if a user wants to scale the simulation up or down.

Let's take an example. In a EM-PIC simulation, there is only one scaling factor (in Smilei, the Wr above). This means that each of the new attributes above should be a list of one float. In this case, timeUnitScalings=[-1.] because times scale as 1/Wr, gridUnitScalings=[-1.] because distances scale as 1/Wr and for a record component that represents a plasma density, unitScalings=[2.] because densities scale as Wr^2. In other cases, we may have several scaling factors, so that these lists of scalings may have more than one element.

New rules:

• Both ***unitSI and ***unitScalings are optional.
• The rule above implies that OpenPMD cannot enforce a comparison between units of data. It is up to the user to make sure they have understood the type of data they are handling.
• The absence of the ***Scalings attributes means the data is not scalable by any factor. Alternately, it can be decided that an empty list should be defined instead.
• There may be both ***unitSI and ***unitScalings defined. The former being seen as the "default" scaling of the simulation, while the latter indicates that the simulation may be freely scaled.
• If any of the new attributes timeUnitScalings, gridUnitScalings, and unitScalings are defined, they must all have the same length.

Note that Scalings may not be the best wording for all attributes above. It can be confused with performance scalings (weak/strong scalings) in HPC computing. There could be a better word.

Doesn't this break OpenPMD fundamentals: making data comparable?

If the data of one code cannot be represented in SI units, how are you supposed to compare it to another code?
This has been one the most frequent arguments against having units optional. Let me explain why we disagree.

If one code provides simulation results in SI, and the other one normalized units, the user has to know what they want to compare and how the data should be modified in order to compare it. This is not the job of OpenPMD, in our opinion. Many simulations are fundamentally scalable, and later comparison to other simulations must be dealt knowingly by the user. We believe that the new attributes above provide a complete manner to scale the data. OpenPMD clients will have to provide users with a way to introduce scaling factors. In fact, this somewhat ensures that users actually know what they are doing instead of randomly compare things.

Overall, we understand that this is a complex question that changes features in OpenPMD but we believe that it needs to be addressed to make OpenPMD widely used. We hope we have convinced you that the current standard has flaws with respect to units management.

[ax3l]

Thank you very much for opening an issue on the discussed points and the great description! We will answer you as soon as possible, just want to write properly and not in between two meetings (we had a major evaluation last week).

[DavidSagan]

if one code provides simulation results in SI, and the other one normalized units, the user has to know what they want to compare and how the data should be modified in order to compare it. This is not the job of OpenPMD, in our opinion.

I agree. I don't think there will be a problem if the units would be made optional. One way to do this would be to have an optional boolian attribute in the root group called, say, scalableUnits. If scalableUnits is False (the default), units would have to be supplied. If scalableUnits is True then units would be optional.

[mccoys]

@DavidSagan I am not sure a boolean is the optimal idea. There could be an integer numberScalingFactors which represents obviously the number of scaling factors, or, in other words, the length of the lists defined above (unitScalings, etc.).

If numberScalingFactors equals 0, then units must be provided. Otherwise, they may or may not be defined.

On the other hand, one would argue that this attribute numberScalingFactors is redundant because it represent the length of lists that are already available. For this reason I suggest to avoid using another attribute like numberScalingFactors or scalableUnits.

[RemiLehe]

Sorry for my (very) delayed answer, and thanks for the detailed discussion of this issue. It is true that the issue of imposing SI units has also been criticized by other potential users of openPMD. Thus it would be great if this discussion could lead to a solution for these users, without disrupting the current ecosystem around openPMD.

As it is, however, my main concern is that the current proposal to make the SI units optional means that a number of existing openPMD tools that relied on it will not be able to do so anymore. In particular, I think that yt requires to know the conversion to SI units (but @C0nsultant could confirm this). And I think that the same holds for Visit (but @xxirii could say more on this).

Of course, one solution would be to accept that Visit and yt will still be able to read the files that contain unitSI, and they will not be able be to read those that don't. However, I would be strongly against this solution: if we make this kind of choice too many times (to accommodate the various requests that different users may have), then each code will have its own flavor of openPMD, which can be read and visualized by their own specialized tools, but not by the generic tools supported by openPMD. This goes against one of the aim of the standard, which is to centralize the efforts on the development of post-processing and visualization tools, so that the whole openPMD community
can benefit from them.

(Note: to be fair, I have to admit that, even currently, some openPMD tools cannot read all types of openPMD files. For instance, yt cannot read openPMD files in quasi-cylindrical geometry. However, this is something that we want to avoid as much as possible, and that we are trying to fix whenever possible.)

I hope other users can understand our position on this. If someone has a solution to this issue, I would definitely be open to it.

My personal inclination would be to still require the conversion to SI units in openPMD (as a default for a particular value of the scaling parameter Wr), and to allow the scaling parameters that @mccoys proposed, as an option (possibly in the ED-PIC extension).