<div dir="ltr"><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div>In response to Joe&#39;s question, we have a three-phase support model planned.</div><div><br></div><div>Phase 0.  Mapping arguments to gmx command-line syntax is somewhat klunky but will allow us to support most gmx operations out of the box without substantial refactoring of core Gromacs code.</div><div>Phase 1.  In conjunction with planned refactoring of option parsing, we plan a more sophisticated and pythonic way to pass arguments to gmx command-line operations.</div><div>Phase 2.  Ultimately, we&#39;d like to offer more modular access to high-level Gromacs operations that might not be the current monolithic gmx command-line operations.  This obviously requires more design work and more core code refactoring.</div><div><br></div><div>We have a similar three-phase model planned for things that are currently file input/output also.</div><div>Phase 0.  Statically named files</div><div>Phase 1.  Files that are managed by the API (you see some examples of this)</div><div>Phase 2.  Data objects that are managed by the API and might or might not correspond to files on disk.</div><div><br></div><div>Our 6-month development timescale focuses on Phase 0 for command-line syntax (maybe stretch goal of Phase 1) and Phases 0/1 for files.  But I&#39;ve outlined our slightly longer-term vision here.  Thanks for the comments!</div><div><br></div><div>--Peter</div></div></div></div></div>