Revisiting the output machinery

[grhawk]

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.

• [ ] The motion class should have access to the output in order to print stuff like optimized geometry, frequencies etc.
• [ ] Properties should be able to print the values of the geometry optimization criteria (maybe directly from the motion class) (taken from #139)
• [ ] Having more output modes available (array, matrix, molden file(?)).
• [ ] The backend/io_units should also take care of converting the output (taken from #147).
• [ ] It should be possible to read any pdb downloaded from the pdb website (taken from #135).
  • This means that pdb, unless otherwise specified in the pdb file, will be considered in angstrom.
  • And that i-PI should be able to understand which lines of the pdb are actually useful.
• [ ] pdb can only be used to ouput positions and only in angstrom (raising an error if units is specified when mode='pdb' in the trajectory output) respecting the pdb standard.
• [ ] Add the possibility to add preset for the output (?)

More Technical

• [ ] The name of the output file should be build in a simpler way (for example in the init of the output classes) so that it would be easier to use i-pi to parse input to retrieve the output filenames (frequently done in tools script).
• [ ] Take care of the comment lines on pdb (taken from #100)
• [ ] With the present infrastructure, it is impossible to specify the "size" of a property at runtime because everything is accessible only after the bind.

Feel free to add what I forgot....

[OndrejMarsalek]

And this seems to be the current I/O central. Count me in, we should really sort this out.

[OndrejMarsalek]

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

[grhawk]

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):

• set_stride: take an integer, used only once at the beginning
• set_atoms_positions: take a dependent object with atom coordinates
• set_atoms_speed: same as before for the speed
• set_atoms_forces: guess...
• set_nbeads: integer for the number of beads (used in the computation of some properties)
• set_prefix: take a string that will be used as the prefix in the filename
• get_filenames: return a dictionary with the fields "property" and "trajectory" and each field is associated with a list containing the respective file names
• refresh/step: trigger the depend machinery to go ahead of a step.

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.