Hi Ross / Sasha,
I have also seen this problem while taking part in the nvidia GPU Test
Drive program that Ross mentioned a couple of weeks back. I have just 1
group of restrained atoms, although it is quite large (2634 atoms - all
heavy atoms in the protein). I see very similar behaviour - the cuda
executable seg faults after a few seconds, but standard pmemd completes
the job just fine. I have all the relevant files, but they're a little
big to post to the list - Ross, please let me know if you would like me
to send those to you separately (about 3MB zipped).
Thanks to nvidia and their partners (Viglen in my case) for setting up
the GPU Test Drive program. I found the system very straightforward to
use, Viglen were helpful and responded very quickly to my emailed
queries, and now I have the numbers I need to decide if a GPU system is
going to work for us. Thanks also to any of the AMBER guys on this list
who helped with this endeavour.
Cheers,
Paul
-----Original Message-----
From: Ross Walker [mailto:ross.rosswalker.co.uk]
Sent: 25 August 2010 19:29
To: 'AMBER Mailing List'
Subject: Re: [AMBER] simulation of a restrained protein fragment
+pmemd.cuda issues
Hi Sasha,
> First, pmemd and pmemd.cuda don't seem to accept restraintmask keyword
> (sander works fine), and only read residue groups specified after the
> parameter list.
Yes this is, unfortunately, true. It would be great to have the
restraintmask keyword added to pmemd, it is just a case of someone
finding
the time to do it. For the moment there is a program called ambmask in
$AMBERHOME/bin which will convert a mask to the old style group input
for
you.
> The initial minimization runs fine, with the entire protein restrained
> (pmemd.cuda works).
> The problems begin when multiple residue sets are restrained at the
> second stage of minimization (protein is relaxed along with the
> solvent). The full set of residues to be restrained is in the format
> below:
> Set 1
> 1000.0
> RES 1
> END
> Set 2
> 1000.0
> RES 24 43
> END
> ...
> END
> There is a total of 12 residue groups.
This is way more complicated than any restraint setup I have tried so I
am
not surprised there is a bug in the GPU version of the code. Can you
possibly send me (offlist) your prmtop, inpcrd and mdin file so I can
take a
look at this myself.
One other thing to try. Can you try putting the whole lot in a single
group?
I.e. if you are keeping the force constant the same I think you can
specify
it in the same group. I don't have the syntax to hand right now but I
thinking it is either:
set 1
1000.0
RES 1 1 24 43
END
END
or
set 1
1000.0
RES 1
RES 24 43
END
END
Or something similar to that. Possibly. I am just thinking off the top
of my
head. If you can figure out the syntax and this works then it will help
narrow down where the bug lies.
> pmemd.cuda fails. When I work my way backwards by removing residue
> groups, I get alternating segmentation faults and "unspecified launch
> failure launching kernel kNLClearCellBoundaries" errors. Finally, at
> only the first 3 residue groups it starts working and finishes the
> minimization. Not sure how to explain that.
One, unrelated thing to note, is that 1000 Kcal/mol/A^2 is a VERY large
restraint. Something like 10.0 would be better and should be enough to
keep
things fixed. 1000 is fine for minimization but such a large restraint
for
MD (3 times the stiffness of a bond) will cause very high oscillations
which
could lead to integration errors.
> Are there some unfinished issues with pmemd.cuda that affect
restraints
> handling?
There are now. :'(
> (all 12 groups with pmemd), I'm trying to run heating. At this point,
I
> use the same set of constraints and this command line:
> /data/amber11/exe/pmemd.cuda -O -i wat_heat.in -o complex_wat_heat.out
> -p complex_wat.prmtop -c complex_wat_min2.rst -r complex_wat_heat.rst
-
> x
> complex_wat_heat.mdcrd -ref complex_wat_min2.rst
>
> pmemd.cuda generates a segmentation fault, while CPU version of pmemd
> says "PMEMD terminated abnormally!" and leaves this message in the
> output file:
> Coordinate resetting cannot be accomplished,
> deviation is too large
> iter_cnt, my_bond_idx, i and j are: 1 444 869 870
>
> sander gives a similar complaint citing SHAKE not being able to run.
This is because 1000 KCAl/mol/A2 is too much for your timestep since it
gives very high frequency oscillations. Try 10.0.
All the best
Ross
/\
\/
|\oss Walker
---------------------------------------------------------
| Assistant Research Professor |
| San Diego Supercomputer Center |
| Adjunct Assistant Professor |
| Dept. of Chemistry and Biochemistry |
| University of California San Diego |
| NVIDIA Fellow |
|
http://www.rosswalker.co.uk |
http://www.wmd-lab.org/ |
| Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
---------------------------------------------------------
Note: Electronic Mail is not secure, has no guarantee of delivery, may
not
be read every day, and should not be used for urgent or sensitive
issues.
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Disclaimer
This communication is confidential and may contain privileged information intended solely for the named addressee(s). It may not be used or disclosed except for the purpose for which it has been sent. If you are not the intended recipient you must not review, use, disclose, copy, distribute or take any action in reliance upon it. If you have received this communication in error, please notify Astex Therapeutics Ltd by emailing P.Mortenson.astex-therapeutics.com and destroy all copies of the message and any attached documents.
Astex Therapeutics Ltd monitors, controls and protects all its messaging traffic in compliance with its corporate email policy. The Company accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Astex Therapeutics domain. Unless expressly stated, opinions in this message are those of the individual sender and not of Astex Therapeutics Ltd. The recipient should check this email and any attachments for the presence of computer viruses. Astex Therapeutics Ltd accepts no liability for damage caused by any virus transmitted by this email. E-mail is susceptible to data corruption, interception, unauthorized amendment, and tampering, Astex Therapeutics Ltd only send and receive e-mails on the basis that the Company is not liable for any such alteration or any consequences thereof.
Astex Therapeutics Ltd., Registered in England at 436 Cambridge Science Park, Cambridge CB4 0QA under number 3751674
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Aug 26 2010 - 03:00:03 PDT
