[gmx-developers] Interfacing with gromacs to get potential energies/ forces

Mon Nov 21 18:47:32 CET 2016

Hi,

The use of a pair list is a standard optimization in N-body codes. You
search for pairs within an interaction radius, plus a buffer (sometimes
called skin), make a list, and re-use the list for a number of successive
evaluations, since particles don't move much between each evaluation. At
each step you use the actual interaction radius to compute the
interactions, including some that are out of range by design. Obviously
rerun must make a new pair list for every evaluation, since that assumption
does not apply. You need to understand your update process in order to
decide whether you want this, and whether it can work well.

Mark

On Mon, Nov 21, 2016 at 3:46 PM Augustin Chevallier <
augustin.chevallier at inria.fr> wrote:

> Thanks I didn't know about OpenMM, I'll take a look.
>
> What do you mean exactly by invalidating the pair list?
>
> Augustin
>
> ------------------------------
>
> *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
> <018-471%2042%2005>.
> > >> 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
> <018-471%2042%2005>.
> > 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.
>
> --
> 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/bc79e584/attachment-0001.html>