Open grhawk opened 7 years ago
And this seems to be the current I/O central. Count me in, we should really sort this out.
Looking at the I/O code again, I am now pretty sure it should go in objects, one class per file type, inherited from a common base class. This unifies the interface and naturally absorbs the "backends".
I think we should mostly focus on what are the features that we want from the I/O code. How to organize it should come later. In other words: we should define a precise interface and then write (reorganize) the code behind the interface. I will try to provide a simple example.
Accessible functions of the I/O code (for sure I am missing many things):
For sure this is not exhaustive, but IMO this would be the best way to start and be sure that the code will be easier to use within i-PI itself and as a module to be imported in scripting. Moreover, a precise interface is easier to test. Of course, this approach requires thinking exactly what we expect from this part of the code because changing it later would be more difficult.
Following the improvement in i-PI on the side of non-MD feature, a revisiting of the output is needed. Followings are the main point that we should implement.
More Technical
Feel free to add what I forgot....