[gmx-developers] Gromacs workflows
hess at cbr.su.se
Thu May 12 18:20:41 CEST 2011
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
>>>> 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
>>> 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
>>> 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
>>> of each software code on board is not necessary.
>>> Incidentally, my group is working on a version of something like this
>>> now; we've only got proof of principle working so far (can import and
>>> 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
>> and if other MD simulation packages are also interested we might
>> 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
>>>> 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
>> 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
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.
More information about the gromacs.org_gmx-developers