It was a bug. Checking in fix shortly... Dumb bookkeeping error...
Repros make fixes easy!
Scott
On Wed, Nov 30, 2011 at 9:51 AM, Marc van der Kamp <marcvanderkamp.gmail.com
> wrote:
> Ok, here is an archive, with just NVT and NPT input and pmemd and
> pmemd.cuda_DPDP outputs to keep it small, as well as runtests.sh and
> runtests_gpu.sh with the commands used to run.
> If anyone would like the prmtop and restart file to run the tests, I'll
> send them off list.
>
> Thanks,
> Marc
>
> On 30 November 2011 13:36, Marc van der Kamp <marcvanderkamp.gmail.com
> >wrote:
>
> > Thanks for the replies!
> >
> > I've been following the steps suggested by Ross.
> >
> > The results are essentially the same as I previously reported:
> >
> > - with NVT input, pmemd, sander and pmemd.cuda_DPDP give very similar
> > results.
> >
> > - with NPT input, pmemd and sander give similar results, BUT
> > pmemd.cuda_DPDP results are very different, especially towards the end of
> > the 200 steps, with Etot about 850 kcal/mole lower and EPtot about 500
> > kcal/mole lower.
> >
> > I tried to attach a bz2-zipped tar-file with the inputs and outputs
> > (mdout.npt.cpu, mdout.nvt.cpu, mdout.npt.DPDP, mdout.nvt.DPDP etc.), as
> > well as the prmtop and inpcrd used. The run commands are listed in
> > runtests.sh (for pmemd and sander) and runtests_DPDP.sh (for
> > pmemd.cuda_DPDP). But just got a reply that the message was too big.
> Can't
> > access files right now, but I will try to send a reduced archive when I
> do.
> >
> > Thanks in advance for looking into this!
> >
> > Marc
> >
> > PS My initial problem was that when I tried to compile pmemd.cuda_DPDP, I
> > got errors during compilation of bintraj.o / bintraj.f90 (a list of
> > undefined references to __netcdf_MOD_nf90_*)
> >
> > I'm using cuda 4.0.17. With the same setup, I previously successfully
> > compiled pmemd.cuda_SDPD (i.e. identical CUDA_HOME, in which no changes
> > have been made since the pmemd.cuda_SPDP compile).
> >
> > The only difference, as far as I can tell, is that I have since compiled
> > AmberTools1.5 in the same AMBERHOME tree, whereas I did the initial
> > pmemd.cuda_SPDP compilation in a 'clean' tree.
> >
> > So, I ended up making a new AMBERHOME tree and doing the compilation
> there.
> >
> >
> > On 29 November 2011 18:23, Ross Walker <ross.rosswalker.co.uk> wrote:
> >
> >> Hi Marc,
> >>
> >> Yes PMEMD.cuda was tested with chamber prmtops and should work no
> >> problems.
> >> It is possible that something is funky with the prmtop being produced by
> >> chamber that means it is not strictly kosher. The GPU version of the
> code
> >> is
> >> more strict about prmtop standards (atoms per molecule being correct
> etc)
> >> than the CPU code is.
> >>
> >> I would suggest doing the following to help with debugging this.
> >>
> >> 1) Compile the DPDP version of pmemd.cuda (assuming you have applied all
> >> the
> >> latest bugfixes)
> >>
> >> cd $AMBERHOME/AmberTools/src/
> >> ./configure -cuda_DPDP gnu
> >> cd ../../src
> >> make cuda
> >>
> >> 2) Run with your prmtop and inpcrd file that gives you the issue. Set
> >> ntt=1
> >> and ig=12345 in the mdin file to avoid complications from different
> random
> >> number generators. Set ntpr=1, nstlim=200. Then run with both:
> >>
> >> $AMBERHOME/bin/pmemd -O -o mdout.cpu -x mdcrd.cpu -r restrt.cpu
> >> $AMBERHOME/bin/sander -O -o mdout.cpu.sander -x mdcrd.cpu.sander -r
> >> restrt.cpu.sander
> >> $AMBERHOME/bin/pmemd.cuda_DPDP -O -o mdout.DPDP -x mdcrd.DPDP -r
> >> restrt.DPDP
> >>
> >> Try this with both NVT and NPT calculations. In both cases the CPU
> PMEMD,
> >> Sander and GPU DPDP code should match to the precision of the output on
> >> all
> >> steps (you get some variation in the last few decimal places) and a few
> >> differences in the virial but they should match.
> >>
> >> Post the results (and the input files here).
> >>
> >> All the best
> >> Ross
> >>
> >> > -----Original Message-----
> >> > From: Marc van der Kamp [mailto:marcvanderkamp.gmail.com]
> >> > Sent: Tuesday, November 29, 2011 7:08 AM
> >> > To: AMBER Mailing List
> >> > Subject: Re: [AMBER] combination of CHAMBER prmtop and pmemd.cuda is
> >> > causing serious instability
> >> >
> >> > It would be great if the pmemd.cuda people (Ross, Scott?) could
> confirm
> >> > that pmemd.cuda has indeed not been tested with the combination of a
> >> > CHAMBER prmtop and NPT.
> >> > Is this assumption true?
> >> > And, will there be efforts to test this and iron out potential
> >> > bugs/problems?
> >> >
> >> > As I'm expecting my system to change conformation, I would really
> >> > prefer to
> >> > run the production MD with NPT (as opposed to NVT after NPT
> >> > equilibration).
> >> > It would be a pity if I need to do (expensive) multi-CPU pmemd.MPI
> runs
> >> > instead of using the superspeedy pmemd.cuda on a single GPU card...
> >> >
> >> > If this would be helpful, I'd be happy to try and set up some small
> >> > test-systems (e.g. alanine dipeptide in waterbox) and see if I can
> >> > replicate the problem.
> >> >
> >> > Thanks,
> >> > Marc
> >> >
> >> >
> >> >
> >> > On 24 November 2011 17:16, Marc van der Kamp
> >> > <marcvanderkamp.gmail.com>wrote:
> >> >
> >> > > Hi Mark,
> >> > >
> >> > > Thanks for your input!
> >> > > Unfortunately, pmemd.cuda doesn't support the do_charmm_dump_gold
> >> > option
> >> > > of the debugf namelist. So I can't compare the forces this way.
> >> > > This may indicate that pmemd.cuda has never really been tested
> >> > (fully)
> >> > > with CHAMBER prmtops...
> >> > >
> >> > > Thanks,
> >> > > Marc
> >> > >
> >> > >
> >> > > On 24 November 2011 13:30, Mark Williamson <mjw.mjw.name> wrote:
> >> > >
> >> > >> On 11/24/11 12:20, Marc van der Kamp wrote:
> >> > >> > To provide more info:
> >> > >> > I've just finished running 1ns of NVE and NVT MD with pmemd.cuda,
> >> > and
> >> > >> they
> >> > >> > DON'T give the issue described, with CA RMSD < 1.8 in 1ns
> >> > simulation.
> >> > >> > The problems therefore appear to arise with a combination of
> >> > pmemd.cuda,
> >> > >> > NPT (ntb=2, ntp=1) and (my) CHAMBER prmtop.
> >> > >> > I would prefer to run this system with NPT, as a conformational
> >> > change
> >> > >> may
> >> > >> > occur. Nothing as large as unfolding though, just a small part of
> >> > the
> >> > >> > protein opening up. I'm using a fairly large water box around the
> >> > >> protein,
> >> > >> > so perhaps NVT would still be ok for this. Any comments
> >> > appreciated!
> >> > >> >
> >> > >> > --Marc
> >> > >>
> >> > >>
> >> > >> Dear Marc,
> >> > >>
> >> > >> I'm not sure where the source of this issue lies at the moment, but
> >> > I
> >> > >> have initial debug route to narrow this down.
> >> > >>
> >> > >> Have you tried checking that the potential energy and resultant per
> >> > atom
> >> > >> forces of the first step between two identical runs in pmemd and
> >> > >> pmemd.cuda are the same?
> >> > >>
> >> > >> The "do_charmm_dump_gold" option can be used for this:
> >> > >>
> >> > >> &debugf
> >> > >> do_charmm_dump_gold = 1
> >> > >> /
> >> > >>
> >> > >> and will dump the following:
> >> > >>
> >> > >> NATOM 24
> >> > >> ENERGY
> >> > >> ENER 0.6656019668295578D+02
> >> > >> BOND 0.1253078375923905D+01
> >> > >> ANGL 0.3101502989274569D+01
> >> > >> DIHE -0.2481576955859662D+02
> >> > >> VDW 0.3170732223102823D+01
> >> > >> ELEC 0.8385065265325110D+02
> >> > >> FORCE
> >> > >> 1 0.1774846256096088D+00 -0.7072502507211014D+00
> >> > >> 0.6898056336525684D+00
> >> > >> 2 -0.2664878707118652D+00 -0.2989897287348136D+00
> >> > >> -0.4514535076187112D+00
> >> > >> 3 0.1307432194682785D+00 0.1309127935015375D+01
> >> > >> 0.1002524982820262D+01
> >> > >> ...etc..
> >> > >>
> >> > >>
> >> > >> There are more examples in
> >> > $AMBERHOME/AmberTools/test/chamber/dev_tests
> >> > >> and also have a look at p 41 of
> >> > http://ambermd.org/doc11/AmberTools.pdf
> >> > >> When I was implementing this, I was using these tests to ensure
> that
> >> > I
> >> > >> was getting the same potential energy and per atom forces from the
> >> > AMBER
> >> > >> md engines as I was from the charmm MD engine for the same system.
> >> > >>
> >> > >> This test could be used to see if there is a difference in forces
> >> > >> between pmemd and pmemd.cuda MD engines. If the issue is not here,
> >> > one
> >> > >> may need to look into the integration within this ensemble.
> >> > >>
> >> > >> Regards,
> >> > >>
> >> > >> Mark
> >> > >>
> >> > >> _______________________________________________
> >> > >> AMBER mailing list
> >> > >> AMBER.ambermd.org
> >> > >> http://lists.ambermd.org/mailman/listinfo/amber
> >> > >>
> >> > >
> >> > >
> >> > _______________________________________________
> >> > AMBER mailing list
> >> > AMBER.ambermd.org
> >> > http://lists.ambermd.org/mailman/listinfo/amber
> >>
> >>
> >> _______________________________________________
> >> AMBER mailing list
> >> AMBER.ambermd.org
> >> http://lists.ambermd.org/mailman/listinfo/amber
> >>
> >
> >
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Wed Nov 30 2011 - 21:30:03 PST
