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 Should properties.py contains the values used as convergence criteria during the geop? #139)
• Having more output modes available (array, matrix, molden file(?)).
• The backend/io_units should also take care of converting the output (taken from Important units problem #147).
• It should be possible to read any pdb downloaded from the pdb website (taken from Read all valid PDBs #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 Return also comment line when reading files #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.