You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The DataCollector classes should be converted to C++ classes that can store states.
Store the ID.
Currently you must pass the id to almost(?) every write/read method. This is inconvenient and error-prone. The ID should be stored (e.g. during opening or with setters if it should be possible to change it) and removed from the write/read interface
Similar with the mpiRank
Currently some classes use the mpiRank and some use the ID for accessing data, it even seems to be mixed or nulled at some places. Better would be to honor the arguments passed in at file-opening and store it. So it would be possible to use a variable naming scheme for the files (mpiRank or ID in name)
Store the (base) filename
It might be good to store the basename of the h5 file for users to access it. It is e.g. required for openPMD attributes and doesn't cost much.
Store current dataset
Writing/reading is often done dataset-wise. So the interface should support that. A wrapper I came up with supports the usage below:
The DataCollector classes should be converted to C++ classes that can store states.
Currently you must pass the id to almost(?) every write/read method. This is inconvenient and error-prone. The ID should be stored (e.g. during opening or with setters if it should be possible to change it) and removed from the write/read interface
Currently some classes use the mpiRank and some use the ID for accessing data, it even seems to be mixed or nulled at some places. Better would be to honor the arguments passed in at file-opening and store it. So it would be possible to use a variable naming scheme for the files (mpiRank or ID in name)
It might be good to store the basename of the h5 file for users to access it. It is e.g. required for openPMD attributes and doesn't cost much.
Writing/reading is often done dataset-wise. So the interface should support that. A wrapper I came up with supports the usage below:
Wrapper:
The text was updated successfully, but these errors were encountered: