Implement writing to same h5md files on multiple steps

[J-Hizzle]

Solves #38

Needs major redesign before being merged with main.

[J-Hizzle]

I tested my implementation in a simulation and found that when saving to H5MD file every step over 10 steps, the simulation time doubles. Since I would like to save only every 1000 steps, that would yield a performance comparable to 1001 steps, which sounds very tolerable to me.

I don't know if my implementation might run into memory problems eventually, though, due to the file being open all the time and its content growing from step to step. I'll conduct further tests.

[XzzX]

Ok, I would need more time to really dig into it. So just a few high level comments.

• How does dump and dumpStep interact? What happens if I call both interleaving? If they do not share any logic, does it make sense to separate it into two classes?
• As you experienced, there is a lot of typing and almost code duplication involved. To tackle this problem I used to generate these files via python and Jinja templates. This is not a must, but currently your changes would be overwritten.
• Can we use RAII for open and close? Aka, currently you might forget to call close. This can be avoided by binding open to the constructor of the class and close to the destructor. Similar to python with open(...) as f:.

[J-Hizzle]

How does dump and dumpStep interact? What happens if I call both interleaving? If they do not share any logic, does it make sense to separate it into two classes?

As of now, there is no interaction in between the two. We could separate them. The alternative would be merging. In principle, the dump function also opens, dumps and closes, so it could be changed to contain only calls to the corresponding functions.

[J-Hizzle]

As you experienced, there is a lot of typing and almost code duplication involved. To tackle this problem I used to generate these files via python and Jinja templates. This is not a must, but currently your changes would be overwritten.

I see. I have no experience with Jinja, so I would have to read into it. Would it make sense to pursue implementing everything in the c++ files and as a last step incorporating the changes into the Jinja files?

[J-Hizzle]

Can we use RAII for open and close? Aka, currently you might forget to call close. This can be avoided by binding open to the constructor of the class and close to the destructor. Similar to python with open(...) as f:.

That sounds very neat! I will have a look.

[J-Hizzle]

There seems to be an error: The positions, forces and velocities printed each step to one total file (dumpStep) are not necessarily the same as these quantities printed to one file per step (dump). I'm investigating this, but for now this branch is unstable.

[J-Hizzle]

There seems to be an error: The positions, forces and velocities printed each step to one total file (dumpStep) are not necessarily the same as these quantities printed to one file per step (dump). I'm investigating this, but for now this branch is unstable.

Apparently, this issue was due to something else. Anyways, I enabled reading one single requested step from an H5MD file containing an entire trajectory. Following this, I also implemented one test for the H5MD io for multiple steps and one test checking consistency between the single-step and multi-step output. I think now the changes on this PR are functionally stable.

Next step will be to clean up the implementation and adjust the jinja template files.

[J-Hizzle]

Cabana appears to have io functionality for hdf5 files as well. Might be worthwhile to check it out.