openPMD/openPMD-api

Index Order Mappings

Offen

#147 geöffnet am 25.04.2018

 (1 Kommentar) (0 Reaktionen) (0 zugewiesene Personen)C++ (57 Forks)auto 404
frontend: C++17frontend: Python3good first issuehelp wanted

Repository-Metriken

Stars
 (160 Sterne)
PR-Merge-Metriken
 (PR-Metriken ausstehend)

Beschreibung

With the removal of dataOrder in openPMD 2.0 and the confusion it already adds in 1.0.0 we should provide an API that makes it easy to set/read attributes such as:

base standard attributes:

  • axisLabels
  • gridSpacing
  • gridGlobalOffset
  • shape of constant record components

and ED-PIC extension attributes:

  • fieldBoundary
  • particleBoundary

Attributes such as axisLabels should be an object and we could add an API of some kind of map. Otherwise it can be confusing if a user accesses low-level numpy attributes such as .shape which indices are then in inverted order if one is accessing from C/C++/Python.

So instead of

record.axisLabels = {"x", "y", "z"};
// ...
cout << record.axisLabels[0] << endl;

we should provide an access of that can not be confused or has a clear relation to a matrix' A[k,j,i] order.

Or we write setters/getters like

record.axisLabels.set({"x", "y", "z"}, indexOrder::fastToSlow);
// ...
cout << record.axisLabels.get(indexOrder::slowToFast) << endl;
// "z", "y", "x"

or we come up with something even more gentle.

Or we say "in the C++/Python API use the same order as your index order" and we invert it automatically on write according to the standard. They APIs don't need to match the low-level data, imho. Anyway, we did this in the past with libSplash and it was not necessarily removing confusion.

Contributor Guide