[gmx-developers] single precision, double precision hybrid GROMACS

[D. Ensign]

Quoting Erik Lindahl <lindahl at sbc.su.se>:

> Hi Dan,
>
> On Apr 7, 2006, at 9:28 PM, D. Ensign wrote:
>
> > says Eric Lindahl:
> >> I think the only case for "limited double precision" is to get
> >> perfect energy conservation with constraints.
> >
> > Hold on, let's stop right there for a minute. Not that this train
> > has already passed by.
> >
> > Allow me to re-muddy the waters after Michael's clarification.
> > Please don't let it matter
> > to you WHY I want to do certain things in double precision and
> > others in single --
> > although it's not a big mystery, perhaps we can all pretend that
> > I'm doing it because of
> > the voices in my head, and what's a better reason than that?
> > Besides, someday I'm sure
> > I'll see you guys at a meeting, and I'll be jabbering on about what
> > a great idea it was
> > to do some calculations in single prec. and others in double. Then
> > you'll all make fun of
> > me and poke me with sharp sticks, until I start crying and run away
> > to hide in the
> > cupboard. I will not be coaxed out except with Gouda, Dutch beer,
> > and gentle coos of
> > "That's a nice little monkey, that's a boy." All in good time, my
> > friends, all in good
> > time.
>
> Well, to us the reason _is_ important, since it has do with where we
> (possibly) lose accuracy, and we want to isolate those places as much
> as possible and fix the actual error.
>
> Single precision will likely become even more important in the future
> as we move to graphics cards, physics coprocessors, embedded systems,
> etc., and for many of these it's simply not possible to use double -
> we have to work around precision loss in other ways (summation order,
> etc.).
>
> In other words, there might be more people interested in helping if
> you choose that path :-)

That's all perfectly fine, and I'm excited to see what comes out of this in the next few
years.

However -- to nail this down in the way you describe is going to take a lot of work, but I
need energy-conserving* trajectories right now -- and it would help immensely, and in many
ways, to have hybrid calculations. My task here is to decide if it would save me any time
to fuss with the code (plus, it's an education in GROMACS, lemme tell ya) rather than
just using small time steps, smooth cutoffs, PME, what have you, and sucking it up and
"only" getting 250 ps a day, per trajectory.

*When I say energy-conserving, I have a specific definition in mind: that the standard
deviation of the energy is linear with dt^2, as should be the case, I understand, with
Verlet-type algorithms with no net energy drift.

We do have a hack that someone tried with the code here, so I think at this point it would
be best to test that against vanilla single precision and (chocolate?) double precision on
my test system, rather than tooling around with it myself. I'm convinced that this hack
code is not what we want, however, but I'll see if it helps.

In any case, I'd be glad to be part of the fun of finding and fixing errors, if I can be
of use! (If nothing else, I've dusted off my pompoms and will play the role of
cheerleader.)

Have fun,
Dan

> > That being said, what would be easier to appease the voices:
> > 1. Use the single precision code and make the constraints double
> > 2. Use the double precision code and make the forces single (the
> > force calculations look
> > like they're all OVER the place, but I bet I can track them all down)
>
> For both of these you'll need to convert coordinate, force, and
> energy arrays between double and single every time you call the
> routine in the alternative precision.  Just doing the constraints
> (not integration) in double probably won't suffice to conserve
> energy, though.
>
> > 3. Compile single precision and double precision libraries, then
> > link, eg, single
> > precision fnbf.o with, eg, double precision md.o
> >
> Not possible. You can't provide a single precision array in a
> function call to a routine expecting a double precision one.
>
>
> Cheers,
>
> Erik
>
>
> _______________________________________________
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://www.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.
>