[gmx-developers] Gromacs workflows

[Berk Hess]

On 05/12/2011 06:11 PM, David van der Spoel wrote:
> On 2011-05-12 17.59, Berk Hess wrote:
>> On 05/12/2011 05:49 PM, Shirts, Michael (mrs5pt) wrote:
>>>> Another project is a new file format for simulation input, output and
>>>> specifying analysis tasks.
>>>> We are aiming for a joint file format with at least Gromacs and Amber
>>>> and hopefully more
>>>> There are many issues to solve here and there will probably be many
>>>> fields specific for
>>>> a particular package, but we would like to have the most commonly used
>>>> information
>>>> in well defined fields so information can easily be exchanged between
>>>> different simulation
>>>> and analysis software.
>>> Interesting. I wonder if it might make more sense rather than to 
>>> come up
>>> with a new format that other tools need to support, build tools that 
>>> can
>>> intercovert between input/output files more easily. Then all that
>>> needs to
>>> be done is to write importers/exporters, rather than having to rewrite
>>> codes. This has some advantages:
>>>
>>> * Nothing breaks -- no need to worry about portability between new and
>>> older
>>> formats for existing code.
>>> * Decoupling changes in file writing/reading from changes in the main
>>> simulation codes.
>>> * If there are desires to move to a new general format eventually, it
>>> can be
>>> done gradually, as weak coupling between codes already exists.
>>> * Third parties can write importers/exporters, so having the main
>>> developers
>>> of each software code on board is not necessary.
>>>
>>> Incidentally, my group is working on a version of something like this
>>> right
>>> now; we've only got proof of principle working so far (can import and
>>> output
>>> from Gromacs to an abstract internal representation), but are now
>>> moving to
>>> supporting other codes, and parameterization schemes. I'd be very
>>> interested in connecting with other people on such a project.
>>>
>> I am also not in favor of yet another file format.
>> But we had anyhow already decided to move to xml for several types of 
>> files
>> and if other MD simulation packages are also interested we might 
>> actually
>> be able to achieve a good and widely used format.
>> An issue are our trajectories, which we would not want to have in ascii.
>> But note that I'm not at all a file format expert.
>>>> At this (very initial) point, I would like to ask the community if 
>>>> there
>>>> are documented workflows.
>>>> We might be able to use there, both to set up the framework and to see
>>>> what information
>>>> we might have to store in the new file format.
>>> David Mobley, John Chodera, and I have a fair amount of work done on
>>> automatic workflows for free energy calculations.
>> I was thinking of more "standard" things than that, but maybe free 
>> energy
>> calculations belong to the standard repertoire now.
>
> Maybe you should start with your own stuff. You may think you are 
> doing non-standard stuff, but if that is true, how much stuff is truly 
> standard? Doing a single simulation of a protein in water is simple, 
> but pretty useless nowadays. It is all about ensembles, automatic 
> convergence checking, equilibration checking, analysis. Catching errors
I agree with all of this. I'm mainly doing non life-science things now 
though,
so that wouldn't really qualify.
>
> Incidentally the gentop code will be very useful in any such project. 
> I will some have the complete antechamber functionality in one gromacs 
> style command line tool and it also has rudimentary OPLS support. In 
> the near future we might add CGenFF support too.
>
> This is not at all an easy endeavor though, in fact I have submitted 
> proposals around this which got rejected, basically because the 
> referee said it was impossible (and my group lacked the competence :().
>
> My ideal would be to have an iTunes like application where I can drag 
> molecules in a map and then click to fork off the computations that I 
> have predefined, to a server in the cloud. Automatic checking for 
> "doubles" (i.e. has the calculation been done already) is needed too. 
> Did I mention running it from a cell-phone?

These things are far more advanced than what we are aiming for here, we 
having been talking
about this as well, but never went as far a writing a proposal.
This would mainly be to send of simple calculations with possibly a 
small amount of post-processing
and possibly some data dependencies for further jobs.
I was wondering if there are common simple workflows, but maybe that's 
not the case.
There seems to be a large demand for push-the-button style simulations 
from (I guess)
the experimental side. But I wouldn't want to spend to much effort on that.

Berk