Species Type: Suggestion for Ion Syntax

[s9105947]

The species type extension in the section for atoms notes: "Any extension using this standard can define how to specify the charge state."

Would it be possible/advised to add such a definition?
I recon it is a somewhat common usecase, and would be justified in a standard.

I'd like to suggest the following notation:

Examples: He^2+, H^+, Cl^-, O^2-, #3He^2+
Generalized: atom "^" *DIGIT ( "+" / "-" )
Rationale:

• use a delimiter after the atom to specifically denote charge -- I'm not sure that ^ is a good idea, maybe another character is better suited (_, /, |, :?)
• allow omission of amount if it is 1
• could be used with molecules too (see below)

I'm not aware how existing implementations solve this, maybe copy from them instead?

[ax3l]

"Any extension using this standard can define how to specify the charge state."

Yes, this is to avoid confusion and determine which components of the standard have precedence. For instance, the ED-PIC convention has a clear meaning of charge, we then only add extra meaning with the SpeciesType extension to clarify that something is a Hydrogen or Carbon isotope.

Would it be possible/advised to add such a definition? I recon it is a somewhat common usecase, and would be justified in a standard.

Unless we have a concrete chemical use case, I would not specify this yet. This is also the reason why the "Molecule" section is intentionally sparse for future use.

The reason behind this is the following: currently, most our use cases are in laser-plasma physics, astrophysics, high-energy physics and some data analysis tasks. In all the listed domain sciences, the charge state changes during the simulation, thus we need to encode it per particle outside the SpeciesType extension. (Our codes have ionization physics and in the future maybe also re-combination physics included.)

The notions you list are chemical notations and assume the charge state cannot change in a data series.

So yep, good idea to add, but not without a use case (i.e., an actively maintained chemistry code that commits to adopt openPMD). We can keep this issue open for potential future adopters if you like :)

[s9105947]

This touches "What is a species?", and I'd agree that the charge state of individual particles is not part of that -- i.e. it does not make sense to include the charge in a species definition.

Suggestion for standard text:

The base speciesType standard does not support ions. The charge state ("ionization") is an attribute of an individual particle (or macroparticle), and therefore an implementation SHOULD NOT accept a charge state as part of the speciesType using an implementation-defined syntax. In the case that the implementation does treat the charge state ("ionization") as a global, unmodifiable property of the speciesType it MAY accept a charge state encoded in an implementation-defined way.

[DavidSagan]

Note: With the Beam Physics extension there is a chargeState array that can be used to specify the charge state of all particles individually.