Dear Jason, Scott, Dave, and Ross,
I have been reading this thread since Rosie described the problem with the
energies coming out different at each new calculation. Scott and Jason
were talking about the problem arising due to the GB model, or the method
it is being used by cuda. So, I provided Rosie with a new prmtop/inpcrd
input set directly created with ff12SB force field. The new set seems to
work fine. The previous one was created with new frcmod/lib files loaded
over ff12SB. The new frcmod has new atom types in it, and it seems that
those are the ones causing the problem (though it is not clear yet to me
why energies are different at the end). I've attached the inpcrd file as
well as the prmtop.notworking and prmtop.working files.
While creating the prmtop.notworking file, I used the following leap
script to create it.
---------- xleap.in -----------
source leaprc.ff12SB
addPdbAtomMap {
{ "OP1" "O1P" } { "OP2" "O2P" }
{ "HO5'" "H5T" } { "HO3'" "H3T" }
{ "H5'" "H5'1" } { "H5''" "H5'2" }
{ "H2'" "H2'1" } { "H2''" "H2'2" }
}
addAtomTypes {
{ "DH" "H" "sp3" }
{ "C1" "C" "sp2" }
{ "C2" "C" "sp2" }
{ "C3" "C" "sp2" }
{ "C4" "C" "sp2" }
{ "C5" "C" "sp2" }
{ "C6" "C" "sp2" }
{ "C7" "C" "sp2" }
{ "C8" "C" "sp2" }
{ "CI" "C" "sp3" }
{ "OZ" "O" "sp3" }
}
loadamberparams ./libraries/frcmod.parmCHI
loadamberparams ./libraries/frcmod.ionsjc_tip3p
loadoff ./libraries/dna.parm99chi.parmbsc.off
loadoff ./libraries/ions08.lib
set default PBradii mbondi2
mol = loadpdb model.pdb
saveAmberParm mol prmtop.notworking inpcrd
quit
------------------------------------------------
If someone wants to use a GB model on a modified system (or let's say a
model with revised force field) I am not sure what else needs to be
defined in the leap input file. In the cuda version of pmemd, is there a
specific file that has info on the GB model which needs to be modified in
order define new atom types (so that the GB model won't complain about
it)? It seems that usage of new atoms types somehow creates this whole
problem. Thanks.
Best regards,
Ilyas Yildirim, Ph.D.
-----------------------------------------------------------
= Department of Chemistry | University of Cambridge =
= Lensfield Road (Room # 380) | Cambridge, UK CB2 1EW =
= Ph.: +44-1223-336-353 | E-mail: iy222.cam.ac.uk =
= Website: http://ilyasyildirim.wordpress.com =
= ------------------------------------------------------- =
=
http://www.linkedin.com/in/yildirimilyas =
=
http://scholar.google.com/citations?user=O6RQCcwAAAAJ =
-----------------------------------------------------------
On Thu, 29 Jan 2015, Jason Swails wrote:
> On Thu, Jan 29, 2015 at 9:14 PM, Scott Le Grand <varelse2005.gmail.com>
> wrote:
>
>> Hey Jason, I found the root cause and checked in a fix.
>>
>> If I put a printf into any CUDA kernel, that's the end of its performance.
>> Printf is a hog. It's only useful for debugging purposes.
>
>
> That's what I was suggesting it be used for. Basically what I was curious
> about was whether or not any of the GB tests in our test suite hit the code
> path where dr didn't get initialized. If it did, that would seem (to me)
> to be clear evidence that that code path is not illegal/unusual (i.e.,
> indicative of bad parameters). If that printf is never triggered during
> the test suite, the parameters may be unusual. I certainly wasn't
> suggesting it be left in permanently. I'll take a look if I have time.
>
>
>
>> The beginning
>> of this thread has links to the data to repro this behavior. It's weird
>> that we never saw this before.
>>
>> Just initialializing PMEFloat dr does the trick. The bug is fixed.
>>
>
> I saw the commit log :).
>
> Thanks,
> Jason
>
> --
> Jason M. Swails
> BioMaPS,
> Rutgers University
> Postdoctoral Researcher
> _______________________________________________
> 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 Jan 30 2015 - 09:30:02 PST
