Hi Marc,
Yes I did receive the files you sent. Various grant proposal deadlines have
conspired to prevent me from having time to look at it properly yet though.
I agree your fix is correct and it is Chamber that is incorrectly filling
out the various fields in the topology file. I need to find time to go
through the code and work out why this is and how to fix it. There are
similar issues in leap when one has waters named different things in the pdb
file.
One thing you can do to help is try running your unmodified prmtop and your
modified prmtop through the cpu version of pmemd (and/or sander) and see if
you get the same answers. My suspicion is that you will and thus the only
difference is whether the waters are shaken in the standard routine or via
the supposedly faster water specific shake routine. If you can run them as
benchmarks and see if there is a timing difference that would help as well.
If, however, the answers come out different then the problem is more serious
than I first thought.
With regards to the second problem I think the issue here is that you end up
with a bond that spans molecules. The prmtop has a description of molecules
and anything that is covalently bonded together should be in the same
molecule. It should not be possible to have a bond that crosses two
molecules. If you run constant volume this should not cause a problem,
however, due to the way constant pressure is done in parallel this can cause
all sorts of problems when running NPT. Sander is fine because it replicates
the data across all nodes while pmemd is spatially decomposed. So see if NVT
causes the problem to go away. Sander I think is just missing the check and
will happily run. However as soon as you get one of your molecules cross the
box boundary it will be imaged and all hell will break loose. So you are
probably okay for a few hundred nanoseconds and then your calculation will
die.
This is a second bug in the prmtop creation. Is this again the prmtop made
with Chamber? - That you first fixed for the solvent pointers issue and then
this second issue cropped up?
All the best
Ross
From: Marc van der Kamp [mailto:marcvanderkamp.gmail.com]
Sent: Friday, April 15, 2011 2:44 AM
To: AMBER Mailing List
Cc: Ross Walker
Subject: Re: [AMBER] pmemd.cuda crashes due to "Inconsistent hydrogen
network"
Hi Ross and others,
Last Sunday I sent you the files and last Monday I sent you a further update
(I managed to fix the prmtop manually and run pmemd.cuda succesfully).
Could you confirm if you have received these emails, or has something gone
wrong?
For everyone's information:
My original problem was caused by a faulty prmtop (created by CHAMBER).
It turned out that 1 (of 2) SAM molecule and 1 water molecule (the first)
are 'missing' in the prmtop, i.e.
1) under %FLAG RESIDUE_LABEL there is only one SAM listed (should be two)
and 12174 water molecules (should be 12175).
2) the equivalent problem is present under %FLAG RESIDUE_POINTER, which
misses the beginning atom numbers of the 2nd SAM and the 1st water molecule
(6653 and 6703, respectively).
By changing the RESIDUE_LABEL and RESIDUE_POINTER fields manually, and
further the correcting the SOLVENT_POINTER field, I was able to use the
prmtop successfully with pmemd.cuda_SPDP.
BTW, I agree with Scott that it would be good if the fortran-code (both
sander and pmemd) would pick the problem up as well.
Further, I've now come across a different, but probably related problem:
When I run pmemd.MPI with the manually fixed prmtop, the program crashes
just after reading in the .rst file with:
ERROR: PMEMD does not support intermolecular PRFs!
This is NOT the case with sander.MPI or with pmemd (serial version), both of
which run fine.
It turns out that this error stems from
$AMBERHOME/src/pmemd/src/mol_list.f90 (line 418), and by looking at the
code, at least I found that PRF stands for 'pseudo-residue fragment'
(couldn't find this in AMBER manuals or mailing list). This seems to be
something used for running under MPI.
Obviously, I don't want intermolecular PRFs, so maybe I need to fix
something else in the prmtop in order to correct this? But if so, what? Or
perhaps the problem lies deeper than that...
Others that actually know (a little) about the code may help me out here...
(Perhaps I should start a new thread...)
Any help appreciated!!
Marc
On 10 April 2011 05:29, Ross Walker <ross.rosswalker.co.uk> wrote:
Hi Marc,
Can you please send me (privately) your input files and a script that would
allow me to build the prmtop from the psf using chamber and then also the
run scripts you are using in pmemd.cuda. That way I can take a look at it
and try to figure out what is going on.
I agree it is 'code' error and not user error here. But the problem could be
very subtle.
All the best
Ross
> -----Original Message-----
> From: Marc van der Kamp [mailto:marcvanderkamp.gmail.com]
> Sent: Saturday, April 09, 2011 2:41 AM
> To: AMBER Mailing List
> Subject: Re: [AMBER] pmemd.cuda crashes due to "Inconsistent hydrogen
> network"
>
> Hi again,
>
> Thanks Ross, Carlos and Scott for your replies.
> As I mentioned, I am using CHAMBER to get the prmtop, using a psf/crd
> of a
> fully solvated system. CHAMBER has renamed the TIP3 (CHARMM convention)
> to
> WAT, so all my waters are WAT. I further have 24 sodium ions in the
> solvent
> (named SOD, following CHARMM convention, not Na+).
> The SOLVENT_POINTERS in the created prmtop list are:
> 0 12203 0
>
> So this is presumably where things go wrong, as it should be last
> solute
> residue (428 in my case), total number of molecules (? or total number
> of
> solvent molecules? If the first, then 12203 is correct), first solvent
> molecule (429 in my case).
> (Or perhaps no molecules should be treated with the special solvent
> SHAKE to
> be more true to CHARMM?)
> However, manually changing these values in the prmtop did not change
> the
> problem.
> I will try to do more testing on Monday.
> BTW, I don't think this is really a user error, but perhaps an 'error'
> in
> CHAMBER?
>
> Many thanks,
> Marc
>
> On 9 April 2011 00:09, Scott Le Grand <SLeGrand.nvidia.com> wrote:
>
> > Yes, this is user error that is caught by the CUDA code. The FORTRAN
> code
> > should catch this as well IMO. One or more of your waters is
> incorrectly
> > named and not correctly picked up for the specialized SHAKE algorithm
> for
> > waters. So what I've detected is a hydrogen that is supposedly in a
> water
> > molecule but which has more than one bond attached to it.
> >
> >
> > -----Original Message-----
> > From: Marc van der Kamp [mailto:marcvanderkamp.gmail.com]
> > Sent: Friday, April 08, 2011 8:07 AM
> > To: amber.ambermd.org
> > Subject: [AMBER] pmemd.cuda crashes due to "Inconsistent hydrogen
> network"
> >
> > Hi all,
> >
> > I have previously successfully run pmemd.cuda_SPDP using an AMBER
> force
> > field.
> > I'm now trying to do the same using the CHARMM force field. After
> > converting
> > psf/crd using CHAMBER to prmtop/inpcrd, sander.MPI and pmemd.MPI have
> no
> > problems with my system/files. However, when I try to run the same on
> a
> > GPU,
> > pmemd.cuda_SPDP crashes with the following message:
> > Inconsistent hydrogen network, exiting.
> >
> > I noticed this error message was introduced (or altered) in the
> > comprehensive Bugfix.9 (BTW, all current bugfixes, i.e. up to 12, are
> > applied):
> >
> > if ((my_nonfastwat_bond_dat[j].atm_i == atm_j) ||
> > (my_nonfastwat_bond_dat[j].atm_i == atm_j))
> >
> > {
> >
> > printf("Inconsistent hydrogen network,
> > exiting.\n");
> >
> > + gpu_shutdown_();
> >
> > exit(-1);
> >
> > }
> >
> > The error occurs right after the number of triangulated waters are
> reported
> > in the output ("Number of triangulated 3-point waters found")
> >
> > FYI, I'm running on an NVIDIA Tesla M2050.
> >
> > Any suggestions on how to fix this?
> >
> > Many thanks in advance,
> > Marc
> > _______________________________________________
> > AMBER mailing list
> > AMBER.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber
> >
> > ---------------------------------------------------------------------
> --------------
> > This email message is for the sole use of the intended recipient(s)
> and may
> > contain
> > confidential information. Any unauthorized review, use, disclosure
> or
> > distribution
> > is prohibited. If you are not the intended recipient, please contact
> the
> > sender by
> > reply email and destroy all copies of the original message.
> >
> > ---------------------------------------------------------------------
> --------------
> >
> > _______________________________________________
> > 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 Fri Apr 15 2011 - 09:30:02 PDT
