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

Mark Abraham mark.j.abraham at gmail.com
Mon Nov 21 15:39:37 CET 2016 

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20161121/32128915/attachment-0001.html>

More information about the gromacs.org_gmx-developers mailing list