[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
   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
Custom Search