[gmx-developers] Interfacing with gromacs to get potential energies/ forces
Augustin Chevallier
augustin.chevallier at inria.fr
Mon Nov 21 15:46:10 CET 2016
Thanks I didn't know about OpenMM, I'll take a look.
What do you mean exactly by invalidating the pair list?
Augustin
----- Mail original -----
> De: "Mark Abraham" <mark.j.abraham at gmail.com>
> À: gmx-developers at gromacs.org
> Envoyé: Lundi 21 Novembre 2016 15:39:23
> Objet: Re: [gmx-developers] Interfacing with gromacs to get potential
> energies/ forces
> Hi,
> On Mon, Nov 21, 2016 at 3:30 PM Augustin Chevallier <
> augustin.chevallier at inria.fr > wrote:
> > mdrun -rerun already does this. If you can cast the implementation of your
> > algorithm so that you have many sets of positions to be evaluated, then you
> > should start by implementing that with rerun, not with writing code that
> > you
> > then have to prove still works correctly. Calling the API directly sounds
> > like an optimization you should do only if you need it. You anyway want to
> > be able to do it via rerun to be a way of proving you've done it correctly.
>
> > Using GROMACS because it's really fast, but then hacking away all the
> > parallelism setup that makes it fast would be a bit inconsistent, and any
> > performance advantage of GROMACS doesn't really matter unless you're
> > already
> > planning at least millions of potential evaluations.
>
> > I'm trying to implement a stochastic algorithm, so I'm generating new
> > configurations on the fly, so I cannot (sadly) use the rerun functionality.
> > To be honest I don't have that many choices. I either re-implement gromacs
> > force fields to get the potential energies, which would take a lot of time
> > and testing AND will most likely be much slower (and I'm not talking about
> > MPI here, just plain SIMD) or I try to use gromacs directly.
>
> Also wanting plurality of force field support is a strong supporting reason
> for choosing GROMACS. Otherwise frameworks like OpenMM or TINKER (or
> others?) make some sense.
> > Thanks for your answers! So it seems that I have something which works :)
> > (it's in practice almost like replacing the update_coords with something
> > custom).
>
> Yeah. I would also consider leaving GROMACS code mostly alone and having
> update_coords call your code instead. But you will have to consider the
> question of when your update will invalidate the pair list (e.g. nstlist = 1
> is safe, but obviously slower)
> Mark
> > Cheers,
>
> > Augustin
>
> > > De: "Mark Abraham" < mark.j.abraham at gmail.com >
> >
>
> > > À: gmx-developers at gromacs.org
> >
>
> > > Envoyé: Lundi 21 Novembre 2016 15:18:22
> >
>
> > > Objet: Re: [gmx-developers] Interfacing with gromacs to get potential
> > > energies/ forces
> >
>
> > > Hi,
> >
>
> > > On Mon, Nov 21, 2016 at 1:52 PM Augustin Chevallier <
> > > augustin.chevallier at inria.fr > wrote:
> >
>
> > > > Thank you for both of your answers!
> > >
> >
>
> > > > I've tried the code from David van der Spoel, however it crashes. Thus
> > > > I
> > > > have
> > > > made my own (really messy) wrapper by taking the code from mdrun and
> > > > modifying it.
> > >
> >
>
> > > > It seems to work however I would like to confirm a few things.
> > >
> >
>
> > > > 1/ the energy computed during do_forces
> > >
> >
>
> > > If you pass GMX_FORCE_ENERGY in the flags
> >
>
> > > > 2/ after calling do_forces, enerd->term[F_EPOT] gives the potential
> > > > energy
> > > > (without kinetic energy)
> > >
> >
>
> > > Yes
> >
>
> > > > 3/ the units in enerd->term[F_EPOT] is kJ/mol
> > >
> >
>
> > > > Are these 3 points true?
> > >
> >
>
> > > Yes
> >
>
> > > > >mdrun reads all of that from the .tpr and looks at your hardware and
> > > > >command-line options and sets up all of that complexity. I don't think
> > > > >you
> > > > >should want to try to simplify that - you need to satisfy >the
> > > > >prerequisites of do_force() and those were never designed for this
> > > > >use.
> > > > >The
> > > > >important questions are "what will vary between evaluations?" and "why
> > > > >is
> > > > >GROMACS the right tool for the job?"
> > >
> >
>
> > > > well the positions of the atoms will vary. I need gromacs because it
> > > > implements the most common force fields and is really fast.
> > >
> >
>
> > > mdrun -rerun already does this. If you can cast the implementation of
> > > your
> > > algorithm so that you have many sets of positions to be evaluated, then
> > > you
> > > should start by implementing that with rerun, not with writing code that
> > > you
> > > then have to prove still works correctly. Calling the API directly sounds
> > > like an optimization you should do only if you need it. You anyway want
> > > to
> > > be able to do it via rerun to be a way of proving you've done it
> > > correctly.
> >
>
> > > Using GROMACS because it's really fast, but then hacking away all the
> > > parallelism setup that makes it fast would be a bit inconsistent, and any
> > > performance advantage of GROMACS doesn't really matter unless you're
> > > already
> > > planning at least millions of potential evaluations.
> >
>
> > > Mark
> >
>
> > > > >Yes. We are in the process of designing an API that would be usable
> > > > >for
> > > > >what
> > > > >you want, but that's years away still.
> > >
> >
>
> > > > That's good to hear, just sad that it's still years away ;)
> > >
> >
>
> > > > Thanks!
> > >
> >
>
> > > > Augustin
> > >
> >
>
> > > > ----- Mail original -----
> > >
> >
>
> > > > > De: "David van der Spoel" < spoel at xray.bmc.uu.se >
> > >
> >
>
> > > > > À: "gromacs org gmx-developers" <
> > > > > gromacs.org_gmx-developers at maillist.sys.kth.se >
> > >
> >
>
> > > > > Envoyé: Samedi 19 Novembre 2016 16:16:34
> > >
> >
>
> > > > > Objet: Re: [gmx-developers] Interfacing with gromacs to get potential
> > > > > energies/ forces
> > >
> >
>
> > > > >
> > >
> >
>
> > > > > On 19/11/16 14:48, Augustin Chevallier wrote:
> > >
> >
>
> > > > > > Thanks! This code is what I was looking for.
> > >
> >
>
> > > > > >
> > >
> >
>
> > > > > > As for the problem you mentioned, why will this code change? Is it
> > > > > > because
> > >
> >
>
> > > > > > the code itself isn't mature or because gromacs 'core' code will
> > > > > > change,
> > >
> >
>
> > > > > > making this code obsolete? Also about the license, is there any
> > > > > > kind
> > > > > > of
> > >
> >
>
> > > > > > restriction on the usage of this code?
> > >
> >
>
> > > > > >
> > >
> >
>
> > > > > The gromacs core is planned to change, meaning routines called by
> > > > > this
> > >
> >
>
> > > > > code will disappear (or be replaced by others in a non-trivial
> > > > > manner).
> > >
> >
>
> > > > > The specialized code here is also not mature and up-to-date with the
> > >
> >
>
> > > > > latest gromacs.
> > >
> >
>
> > > > >
> > >
> >
>
> > > > > The code is under the same LGPL license as the rest of gromacs.
> > >
> >
>
> > > > >
> > >
> >
>
> > > > > > Augustin
> > >
> >
>
> > > > > >
> > >
> >
>
> > > > > > ----- Mail original -----
> > >
> >
>
> > > > > >> De: "David van der Spoel" < spoel at xray.bmc.uu.se >
> > >
> >
>
> > > > > >> À: gmx-developers at gromacs.org
> > >
> >
>
> > > > > >> Envoyé: Vendredi 18 Novembre 2016 16:11:22
> > >
> >
>
> > > > > >> Objet: Re: [gmx-developers] Interfacing with gromacs to get
> > > > > >> potential
> > >
> >
>
> > > > > >> energies/ forces
> > >
> >
>
> > > > > >>
> > >
> >
>
> > > > > >> On 18/11/16 11:43, Augustin Chevallier wrote:
> > >
> >
>
> > > > > >>> Hello,
> > >
> >
>
> > > > > >>>
> > >
> >
>
> > > > > >>> first, I apologize if this is not the right mailing list, however
> > > > > >>> it
> > >
> >
>
> > > > > >>> seemed more appropriate than user mailing list.
> > >
> >
>
> > > > > >>>
> > >
> >
>
> > > > > >>> I would like to get the potential energy computed by gromacs
> > > > > >>> without
> > >
> >
>
> > > > > >>> having to use the command line and the overhead of
> > > > > >>> writing/reading
> > > > > >>> the
> > >
> >
>
> > > > > >>> result in files. I had a look at the code and indeed it seems
> > > > > >>> possible
> > >
> >
>
> > > > > >>> using mdlib, however I'm a bit overwhelmed by the complexity of
> > > > > >>> the
> > > > > >>> code.
> > >
> >
>
> > > > > >>>
> > >
> >
>
> > > > > >>> From what I understood, I should call the function do_forces(),
> > > > > >>> however
> > >
> >
>
> > > > > >>> it has many parameters, and after looking at do_md() ,mdrunner()
> > > > > >>> and
> > >
> >
>
> > > > > >>> main() it seems there is quite a lot of things to set up before
> > > > > >>> calling
> > >
> >
>
> > > > > >>> that function.
> > >
> >
>
> > > > > >>>
> > >
> >
>
> > > > > >>> So here are some more precise questions:
> > >
> >
>
> > > > > >>> *which initialization are required? should I just copy past some
> > > > > >>> parts
> > >
> >
>
> > > > > >>> of mdrunner for that?
> > >
> >
>
> > > > > >>> *how do I load a gromacs topology file?
> > >
> >
>
> > > > > >>> *I guess I also need a forcerec, how do I create on too?
> > >
> >
>
> > > > > >>> *If I want to modify the atoms positions, can I do it in mdAtoms
> > >
> >
>
> > > > > >>> directly?
> > >
> >
>
> > > > > >>>
> > >
> >
>
> > > > > >>> I know these questions are rather vague, so if you could just
> > > > > >>> point
> > > > > >>> to
> > >
> >
>
> > > > > >>> which part of md_runner() and do_md() I should look at, it would
> > > > > >>> greatly
> > >
> >
>
> > > > > >>> help!
> > >
> >
>
> > > > > >>>
> > >
> >
>
> > > > > >> If you check out the branch qmmm you will find there is an
> > > > > >> interface
> > > > > >> to
> > >
> >
>
> > > > > >> gromacs in src/gromacs/mmslave.h. You can call a few functions to
> > > > > >> change
> > >
> >
>
> > > > > >> coordinates and charges and then calculate energy and forces. If
> > > > > >> you
> > >
> >
>
> > > > > >> link your code to gromacs and call these routines it should work.
> > >
> >
>
> > > > > >>
> > >
> >
>
> > > > > >> The problem with this code is that it will most likely disappear
> > > > > >> or
> > >
> >
>
> > > > > >> change a lot before being taken up in regular gromacs.
> > >
> >
>
> > > > > >>
> > >
> >
>
> > > > > >>
> > >
> >
>
> > > > > >>
> > >
> >
>
> > > > > >>> Thanks!
> > >
> >
>
> > > > > >>> Augustin Chevallier
> > >
> >
>
> > > > > >>>
> > >
> >
>
> > > > > >>>
> > >
> >
>
> > > > > >>
> > >
> >
>
> > > > > >>
> > >
> >
>
> > > > > >> --
> > >
> >
>
> > > > > >> 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
> > >
> >
>
> > > > > >> --
> > >
> >
>
> > > > > >> Gromacs Developers mailing list
> > >
> >
>
> > > > > >>
> > >
> >
>
> > > > > >> * Please search the archive at
> > >
> >
>
> > > > > >> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List
> > > > > >> before
> > >
> >
>
> > > > > >> posting!
> > >
> >
>
> > > > > >>
> > >
> >
>
> > > > > >> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> > >
> >
>
> > > > > >>
> > >
> >
>
> > > > > >> * For (un)subscribe requests visit
> > >
> >
>
> > > > > >> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> > > > > >> or
> > >
> >
>
> > > > > >> send a mail 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
> > >
> >
>
> > > > > --
> > >
> >
>
> > > > > Gromacs Developers mailing list
> > >
> >
>
> > > > >
> > >
> >
>
> > > > > * Please search the archive at
> > >
> >
>
> > > > > http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List
> > > > > before
> > >
> >
>
> > > > > posting!
> > >
> >
>
> > > > >
> > >
> >
>
> > > > > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> > >
> >
>
> > > > >
> > >
> >
>
> > > > > * For (un)subscribe requests visit
> > >
> >
>
> > > > > https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> > > > > or
> > >
> >
>
> > > > > send a mail to gmx-developers-request at gromacs.org .
> > >
> >
>
> > > > > Hi,
> > >
> >
>
> > > > >On Fri, Nov 18, 2016 at 11:43 AM Augustin Chevallier <
> > > > >augustin.chevallier at inria.fr > wrote:
> > >
> >
>
> > > > >
> > >
> >
>
> > > > > Hello
> > >
> >
>
> > > > first, I apologize if this is not the right mailing list, however it
> > > > seemed
> > > > more appropriate than user mailing list.
> > >
> >
>
> > > > Sure, this is appropriate discussion here.
> > >
> >
>
> > > > I would like to get the potential energy computed by gromacs without
> > > > having
> > > > to use the command line and the overhead of writing/reading the result
> > > > in
> > > > files.
> > >
> >
>
> > > > If you don't need to change the model physics between computations of
> > > > PE,
> > > > then you should still consider mdrun -rerun, per
> > > > http://www.gromacs.org/Documentation/How-tos/Single-Point_Energy .
> > >
> >
>
> > > > I had a look at the code and indeed it seems possible using mdlib,
> > > > however
> > > > I'm a bit overwhelmed by the complexity of the code.
> > >
> >
>
> > > > Yes. We are in the process of designing an API that would be usable for
> > > > what
> > > > you want, but that's years away still.
> > >
> >
>
> > > > From what I understood, I should call the function do_forces(), however
> > > > it
> > > > has many parameters, and after looking at do_md() ,mdrunner() and
> > > > main()
> > > > it
> > > > seems there is quite a lot of things to set up before calling that
> > > > function.
> > >
> >
>
> > > > So here are some more precise questions:
> > >
> >
>
> > > > *which initialization are required? should I just copy past some parts
> > > > of
> > > > mdrunner for that?
> > >
> >
>
> > > > *how do I load a gromacs topology file?
> > >
> >
>
> > > > *I guess I also need a forcerec, how do I create on too?
> > >
> >
>
> > > > mdrun reads all of that from the .tpr and looks at your hardware and
> > > > command-line options and sets up all of that complexity. I don't think
> > > > you
> > > > should want to try to simplify that - you need to satisfy the
> > > > prerequisites
> > > > of do_force() and those were never designed for this use. The important
> > > > questions are "what will vary between evaluations?" and "why is GROMACS
> > > > the
> > > > right tool for the job?"
> > >
> >
>
> > > > *If I want to modify the atoms positions, can I do it in mdAtoms
> > > > directly?
> > >
> >
>
> > > > No, they live in a variable of type t_state.
> > >
> >
>
> > > > I know these questions are rather vague, so if you could just point to
> > > > which
> > > > part of md_runner() and do_md() I should look at, it would greatly
> > > > help!
> > >
> >
>
> > > > First let's see whether you can avoid it :-)
> > >
> >
>
> > > > Mark
> > >
> >
>
> > > > Thanks!
> > >
> >
>
> > > > Augustin Chevallier
> > >
> >
>
> > > > --
> > >
> >
>
> > > > Gromacs Developers mailing list
> > >
> >
>
> > > > * Please search the archive at
> > > > http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> > > > posting!
> > >
> >
>
> > > > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> > >
> >
>
> > > > * For (un)subscribe requests visit
> > >
> >
>
> > > > https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> > > > or
> > > > send a mail to gmx-developers-request at gromacs.org .
> > >
> >
>
> > > > --
> > >
> >
>
> > > > Gromacs Developers mailing list
> > >
> >
>
> > > > * Please search the archive at
> > > > http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> > > > posting!
> > >
> >
>
> > > > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> > >
> >
>
> > > > * For (un)subscribe requests visit
> > >
> >
>
> > > > https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> > > > or
> > > > send a mail to gmx-developers-request at gromacs.org .
> > >
> >
>
> > > --
> >
>
> > > Gromacs Developers mailing list
> >
>
> > > * Please search the archive at
> > > http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> > > posting!
> >
>
> > > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> >
>
> > > * For (un)subscribe requests visit
> >
>
> > > https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> > > or
> > > send a mail to gmx-developers-request at gromacs.org .
> >
>
> > --
>
> > Gromacs Developers mailing list
>
> > * Please search the archive at
> > http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> > posting!
>
> > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> > * For (un)subscribe requests visit
>
> > https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers or
> > send a mail to gmx-developers-request at gromacs.org .
>
> --
> Gromacs Developers mailing list
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers or
> send a mail to gmx-developers-request at gromacs.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20161121/e6309cac/attachment-0001.html>
More information about the gromacs.org_gmx-developers
mailing list