[gmx-developers] Gromacs workflows

[Dommert Florian]

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 

> 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?
> 
> >
> > Berk
> >> Best,
> >> ~~~~~~~~~~~~
> >> Michael Shirts
> >> Assistant Professor
> >> Department of Chemical Engineering
> >> University of Virginia
> >> michael.shirts at virginia.edu
> >> (434)-243-1821
> >>
> >>
> >>> From: Berk Hess<hess at cbr.su.se>
> >>> Reply-To: Discussion list for GROMACS
> >>> development<gmx-developers at gromacs.org>
> >>> Date: Thu, 12 May 2011 11:38:43 -0400
> >>> To: Discussion list for GROMACS development<gmx-developers at gromacs.org>
> >>> Subject: [gmx-developers] Gromacs workflows
> >>>
> >>> Hi,
> >>>
> >>> Within the ScalaLife European project on scalable software for life
> >>> sciences (www.scalalife.eu),
> >>> we are working on several aspects of making scientific software, among
> >>> which Gromacs,
> >>> easier to use and run in parallel.
> >>> I have a question for the Gromacs community related to two projects
> >>> within ScalaLife.
> >>> One project is allowing Gromacs workflows to run on
> >>> clusters/supercomputers using a framework
> >>> that allows a simple description of the tasks and can then send it off,
> >>> run the simulation(s)
> >>> and analysis and get your results back.
> >>> 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.
> >>>
> >>> A problem is that in our group we are doing mainly non-standard things,
> >>> and therefore
> >>> we do not have a good overview of what the most common tasks and
> >>> needs are.
> >>>
> >>> 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.
> >>>
> >>> I don't know if it might be useful to start a wiki page on the file
> >>> format requirements.
> >>>
> >>> Berk
> >>>
> >>> --
> >>> gmx-developers mailing list
> >>> gmx-developers at gromacs.org
> >>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> >>> Please don't post (un)subscribe requests to the list. Use the
> >>> www interface or send it to gmx-developers-request at gromacs.org.
> >
> 
> 
> -- 
> David van der Spoel, Ph.D., Professor of Biology
> Dept. of Cell & Molec. Biol., Uppsala University.
> Box 596, 75124 Uppsala, Sweden. Phone:	+46184714205.
> spoel at xray.bmc.uu.se    http://folding.bmc.uu.se


-- 
Florian Dommert
Dipl. - Phys.

Institute for Computational Physics
University Stuttgart

Pfaffenwaldring 27
70569 Stuttgart

EMail: dommert at icp.uni-stuttgart.de
Homepage: http://www.icp.uni-stuttgart.de/~icp/Florian_Dommert

Tel.: +49 - (0)711 - 68563613
Fax.: +49 - (0)711 - 68563658
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20110513/610fc92b/attachment.sig>