Just to commend on this thread. The error message on the missing radii
is not due to a bug.
As stated in the manual, PBSA automatically reassigns prmtop radii
only for GAFF atoms with lower case atom types when radiopt=1. This is
not done for proteins or other macromolecules with upper case atom
types. Basically, the program does not pretend it knows anything about
your specific residue and atom types as far as solvation energy
calculation is concerned.
As has been discussed, it has become unrealistic to rely the hardcoded
routine in pb_aaradi() to keep track of all the new force fields and
new residues from the recent releases. Eventually, the radius
assignment will be moved to LEAP and leave it to the force field
people to decide. For now, you'll have to turn on radiopt=0 to use the
modified Bondi radii or other simpler rule-based radii. The other
option is to support pdb-type pqr files and let the users to hack the
file themselves. I know this is dangerous, but it gives people
choices.
Ray
>>
>> This atom type is from Glycam 06 G. From Glycam_06g-1.dat:
>>>
>>>> GLYCAM_06_G PARAMETERS (FOR AMBER 8.0, RESP 0.010), COPYRIGHT CCRC 2004
>>>> CG 12.01 ! sp3 C aliphatic
>>>
>>>
>>> The prmtop file has actually been created using leap from AmberTools 1.5
>>> with FF99SB + custom libs using types from GLYCAM_06_G.
>>>
>>> PBSA from Amber 11 / AmberTools 1.5 does not complain about the prmtop
>>> file. How comes that it finds the parameter that PBSA from Amber 12 misses?
>>>
>>
>> PBSA from AmberTools 1.5 automatically took radii from the prmtop file, I
>> think. Now it doesn't. Hence the difference.
>>
>
> Interesting.
>
>>
>>>> The solution would be to add this atom type explicitly to the PBSA source
>>>> code so it assigns the correct radius. The relevant subroutine is
>>>> pb_aaradi in $AMBERHOME/AmberTools/src/pbsa/sa_driver.F90.
>>>
>>> Hm, does this mean that for MMPBSA in Amber 12 all parameters for atoms
>>> from third party force fields need to be hardcoded in that file? I am
>>> sure you don't mean that, right? :)
>>>
>>
>> The solution is either that -or- use the radii from the topology file
>> instead (i.e., set radiopt=0). The hard-coded radii are the optimized
>> radii (cited in the AmberTools manual). The manual actually claims that
>> unrecognized atoms take radii from the topology, but that doesn't seem to
>> be the case... I can't speak definitively much more on this due to limited
>> experience/knowledge with PBSA.
>
> Would you consider this a bug now?
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Aug 31 2012 - 10:00:02 PDT
