[gmx-users] Setting custom atoms in FF

[Alex]

Whooooa, that's a huge blow, and it explains a bunch of other issues. I
was thinking the difference had to be around 2-3% and set my pdb files
very precisely.

I actually think that either the tolerance is even larger, or there's something on top of that in the code.

Setting

CJ   opls_996    0      12.011  3    C  0.10  C 0.10  C 0.10   ;bulk C

still assigns #996 to bulk graphene carbons, despite the
difference of about 42%. Anyway, this is nearly catastrophic for what I'm trying to do.
From what I understand, the tolerance cannot be set in the x2top
command itself... Oy.

If you know it off the top of your head, could you please point me to
the variable name in g_x2top.c (if it's there)? I'm using a
precompiled version right now, but I guess I will have to mess with the code on our
cluster.

Allowing this tolerance to be set either as percentage, or in
distance units would be extremely useful. One could always use the
default value if no setting is entered.

Could the last point be relayed to the developers? Sounds like a huge
necessity to me, to be honest.

Thank you,

Alex


JL> On 3/29/15 4:07 PM, Alex wrote:
>> Hi all,
>>
>> I am messing with the OPLS/AA forcefield. The idea is to functionalize
>> graphene edge atoms beyond passivation with hydrogen. At the
>> functionalization region, there is a C atom with
>> two C-C bonds (from graphene), while the third bond is formed with the
>> functional group. The particular atom from the functional group
>> intended to bond with that C bond is also carbon. When setting up the system, in atomname2type.n2t I have:
>>
>> CJ   opls_996    0      12.011  3    C  0.142  C 0.142  C 0.142  ; bulk graphene C
>>
>> but also want to introduce
>>
>> CJ   opls_1001   0.1    12.011  3    C  0.142  C 0.142  C 0.149  ; edge C
>>
>> Both 996 and 1001 are defined in the ffnononbonded.itp, these are
>> custom, but essentially copies from oplsaa entries for carbon. Note
>> the third bond that's longer (which is also the case in my input PDB).  The
>> significant difference is of course the charge there, as I want a globally neutral
>> system.
>>
>> Here is the problem: x2top ignores the second statement from above and the
>> functionalized edge C is assigned #996. Aside from manually modifying
>> the resulting topology, can we make this distinction stick?
>>

JL> g_x2top (and other programs like pdb2gmx) use a default ± 10% distance tolerance
JL> for deciding if something is within bonding distance.  The distinction between
JL> 0.149 and 0.142 is about 5%, so the two lines are effectively indistinguishable.
JL>   The most straightforward solution would be to change the default tolerance in
JL> the code, if your distances are going to be so close in magnitude.

JL> -Justin

JL> -- 
JL> ==================================================

JL> Justin A. Lemkul, Ph.D.
JL> Ruth L. Kirschstein NRSA Postdoctoral Fellow

JL> Department of Pharmaceutical Sciences
JL> School of Pharmacy
JL> Health Sciences Facility II, Room 629
JL> University of Maryland, Baltimore
JL> 20 Penn St.
JL> Baltimore, MD 21201

JL> jalemkul at outerbanks.umaryland.edu | (410) 706-7441
JL> http://mackerell.umaryland.edu/~jalemkul

JL> ==================================================