[AMBER] resp charge fitting

From: Thomas Fox <thomas_fox.gmx.net>
Date: Fri, 14 Dec 2018 17:14:41 +0100

   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

   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

   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
   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
   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
   I have attached a tarball with all the files, so you can try to reproduce my

   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,

AMBER mailing list

Received on Fri Dec 14 2018 - 08:30:03 PST
Custom Search