Axel Huebl

When I think about this, I think adding a "unit label" *before* conversion is not a good idea. Let me explain why. In order to make data portable, a data...

A label for a symbol I find still very useful, e.g. to make something latexy that would be odd/impossible as a record or record-component name.

Ok, "informational purposes only" aka "manual, human reader" is indeed useful for certain workflows! I wonder if we in such a case we even need to *standardize* it - since...

Admittedly, our goal is to motivate people not to look at the unconverted, raw data at all anymore ;) But I have no hard feelings on adding this, @RemiLehe any...

We decided today that the optional feature is useful and should be called explicitly something like `unitRawSymbol`.

[PIConGPU](https://github.com/ComputationalRadiationPhysics/picongpu) as of version `0.1.0` needs the following additional information: - slide counter: a integer number of "slides" that are plane-wise performed to advance the simulation (see [this wiki entry](https://github.com/ComputationalRadiationPhysics/picongpu/wiki/PIConGPU-domain-definitions#moving-window))...

ghotst cells: yes, exactly. clarified my description, thx!

> "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...

Sorry I missed the question. Yes, HDF5 does support 2D arrays as attributes, ADIOS afaik is limited to 1D arrays right now and as you found out: h5py does not...

`currentSmoothing` is an other candidate that should be a particle attribute for each species that creates the (charged/neutral) current (migrated from #128).