On Mon, 2014-12-08 at 01:40 -0300, Juan Blanco wrote:
>
> Hi there,
>
> I'm getting the following error:
>
> Beginning GB calculations
> with /home/chopkins/amber_fresh/amber/bin/sander
> calculating complex contribution...
> bad atom type: Ng
> File "/home/chopkins/amber_fresh/amber/bin/MMPBSA.py", line 96, in
> <module>
> app.run_mmpbsa()
> File "/home/chopkins/amber_fresh/amber/bin/MMPBSA_mods/main.py",
> line 218, in run_mmpbsa
> self.calc_list.run(rank, self.stdout)
> File
> "/home/chopkins/amber_fresh/amber/bin/MMPBSA_mods/calculation.py",
> line 79, in run
> calc.run(rank, stdout=stdout, stderr=stderr)
> File
> "/home/chopkins/amber_fresh/amber/bin/MMPBSA_mods/calculation.py",
> line 148, in run
> self.prmtop))
> CalcError: /home/chopkins/amber_fresh/amber/bin/sander failed with
> prmtop complex.prmtop!
> Exiting. All files have been retained.
> sander found! Using /home/chopkins/amber_fresh/amber/bin/sander
> cpptraj found! Using /home/chopkins/amber_fresh/amber/bin/cpptraj
> mmpbsa_py_nabnmode found!
> Using /home/chopkins/amber_fresh/amber/bin/mmpbsa_py_nabnmode
>
>
> Ng is just a nitrogen atom of a N-Acetil-glucosamine sugar moiety as
> created with Glycam_06j (resname 0YA or 0YB)
>
> Since this "Ng" is chemically no different from any common backbone
> nitrogen, I tried to manually edit the complex and ligand prmtops and
> replace this "Ng" with just an "N" to see if I could by-pass the
> error, but then again I get the same (it reads "bad atom type: N"
> instead, of course, but I mean the same overall crash)
>
> Any hint of what's going on?
You didn't give nearly enough information. I'll try to intuit based on
the error message though: you are running decomposition analysis. For
recent versions of Amber, the only way you can even get this error
message is if you run decomposition analysis (where gbsa=2 is set in the
input file) -- a default radius is assigned for LCPO.
Another thing that is unclear is what version of Amber you are actually
using. I'm pretty sure that the installation of Chad's that you're
using is a checkout of the developer's git repository, but I have no
idea when the last time he pulled the latest changes was -- was it
yesterday? months ago? years ago?
The relevant part of the code is in mdread.F90 (or, if it's a more
recently updated version, mdread2.F90) in the sander source directory.
That part of the code in the *current* version of the code looks like
this:
if (atomicnumber .eq. 7) then
x(L165-1+i) = 1.55d0 + 1.4d0
else if (atomicnumber .eq. 6) then
x(L165-1+i) = 1.70d0 + 1.4d0
else if (atomicnumber .eq. 1) then
x(L165-1+i) = 1.20d0 + 1.4d0
else if (atomicnumber .eq. 8) then
x(L165-1+i) = 1.50d0 + 1.4d0
else if (atomicnumber .eq. 15) then
x(L165-1+i) = 1.80d0 + 1.4d0
else if (atomicnumber .eq. 16) then
x(L165-1+i) = 1.80d0 + 1.4d0
else if (atomicnumber .eq. 17) then
! Cl radius
x(L165-1+i) = 1.70d0 + 1.4d0
else if (atomicnumber .eq. 9) then
! F radius
x(L165-1+i) = 1.50d0 + 1.4d0
else if (atomicnumber .eq. 35) then
! Br radius
! Bondi, J. Phys. Chem. 1964, 68, 441.
x(L165-1+i) = 1.85d0 + 1.4d0
else if (atomicnumber .eq. 20) then
! Ca radius
! Calculated from Aqvist, J. Phys. Chem. 1990, 94, 8021.
x(L165-1+i) = 1.33d0 + 1.4d0
else if (atomicnumber .eq. 11) then
! Na radius
! Calculated from Aqvist, J. Phys. Chem. 1990, 94, 8021.
x(L165-1+i) = 1.87d0 + 1.4d0
else if (atomicnumber .eq. 30) then
! Zn radius
! Hoops, Anderson, Merz, JACS 1991, 113, 8262.
x(L165-1+i) = 1.10d0 + 1.4d0
else if (atomicnumber .eq. 12) then
! Mg radius = 0.99A: ref. 21 in J. Chem. Phys. 1997, 107, 5422
! Mg radius = 1.18A: ref. 30 in J. Chem. Phys. 1997, 107, 5422
! Mg radius = 1.45A: Aqvist 1992
x(L165-1+i) = 1.18d0 + 1.4d0
else
write( 0,* ) 'bad atom type: ',atype
FATAL_ERROR
end if
As you can see, radii are now assigned based on atomic numbers, which
should be stored in the Amber topology file in the ATOMIC_NUMBER
section.
If Ng is correctly identified as atomic number 7 in the topology file
(or if it's not set in the topology file because that topology file is
very old, if its mass is close to 14.01), then you should *not* be
getting this error if you are using even an old version of Amber (the
use of atomic numbers instead of atom type names was made in Jan 2012 --
almost 3 years ago).
So go back and make sure that you are using the most up-to-date version
of Amber (or, better yet, a freshly installed and updated copy of Amber
14) and re-run the calculations. If you still get the same error,
create an example that is as small and as simple as you can make it that
still gives that error and give us something we can use to reproduce the
error you're seeing on our own machines.
Good luck,
Jason
--
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Mon Dec 08 2014 - 07:30:03 PST
