Dear all,
when trying to generate RESP charges for a non-natural aminoacid, I
encountered a weird
behavior of resp: depending how I fixed the charges for the backbone N, H, C
and O, I get
reasonable or less reasonable charges for the remaining atoms.
I illustrate this here with a two conformation (a-helix and b-sheet) stage1
resp fit for
serine capped with ACE and NME. Adding stage2 does not really change the
picture:
Method 1:
This is the method employed by residuegen and how I learned to derive resp
charges some
ages ago:
I read in the charges via qin and fix them with a -99 in the respin file
(atom section after &cntrl).
Then running resp with
resp -O -i tmp1.nc.respin1 -o tmp1.nc.respout1 -q QIN.nc -e ser.esp
Method2:
I think this is how the constraints are set in RED: here the charges are not
read via
the qin files, but are set in the respin file via group constraints. The
corresponing
constraint flags in the atom section are set to 0
The command then is
resp -O -i tmp2.nc.respin1 -o tmp2.nc.respout1 -e ser.esp
With Method1, I get quite large and oscillating charges, whereas with
Method2 the charges
are much closer to the original resp charges from W. Cornell et al in the
all_amino.lib files
Atom Method1 Method2 Cornell
CA 1.101476 0.003050 -0.024900
HA -0.321753 0.131216 0.084300
CB 0.031009 0.184188 0.211700
OG -0.795175 -0.656125 -0.654600
For a number of reasons - which also have been discussed here and in the RED
papers - I
dont expect the charges to be the same as in the Cornell paper, but I was
somewhat
surprised that Method 1, which is employed by residuegen, produces numbers
that are
so vastly different.
I guess one issue is that in Method1 the charges are fixed from the outset
with constraints,
whereas in method2 they are restraints (?? is this really so?) - so in
principle the optimizer
could end up in a completely different place. But I guess this is sth people
should have
noted before (or maybe they have and Im simply not aware of this?).
In any case, the re/constrained backbone charges come out the same with both
methods (not true
anymore when I add constraints for the caps as well, but this is a different
issue). And
the residual sum of squares look reasonable to me for both methods.
Anybody have a clue what is going on? Did I make a stupid error in the input
files?
I have attached a tarball with all the files, so you can try to reproduce my
results.
Amber version: AmberTools18, admittedly not at the latest patch level, but
as resp.F hasnt
changed from Amber16, I wouldnt expect anything from that side.
Thanks a lot for any hint,
Th.
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Dec 14 2018 - 08:30:03 PST
