[gmx-developers] Gromacs workflows

[Berk Hess]

On 05/13/2011 12:40 PM, Dommert Florian wrote:
> On Thu, 2011-05-12 at 18:11 +0200, 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
>> 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 :().
>>
> During my Ph.D thesis I was dealing with FF development and was also
> concernced with the "simple calculations" David mentioned (ensembles,
> convergence checking, ...). Finally I have to apply some further
> extension and I will have some kind of this workflow available. You
> press the enter button one time and different simulations are
> automatically started, analyzed and in my case, new parameter files are
> generated to tune the LJ parameters. As input a generic mdp file and
> input structures are necessary and further options allow to determine
> which properties should be analyzed. However the analysis capabilities
> are so far rather limited, but new types of analysis can easily be
> incorporated.
>
> Are you looking for something like this ??
>
> /Flo
>
I have been ill for several days, so I have replied here for some time.

I wanted to let you know that I decided to use Michael's suggestion
and chose a (simple) free energy calculation as an example work flow.
Although specialisitic (as David said, everything we do is specialistic),
it is quite common and it has some data dependencies. So it's a nice
and useful example.

Thanks for all your input!

Berk