Re: [AMBER] GB protocol problems for large RNAs

From: Ross Walker <ross.rosswalker.co.uk>
Date: Thu, 22 Sep 2011 09:30:46 -0700

Hi Wojciech

> I am attempting to move from an explicit solvent protocol (working,
> but slow) to
> the GB simulations for large, multi-chain RNA structures (~260-300nt,
> with a diameter
> in excess of 120A), using Amber10 (sander.MPI).

I hate to be the bearer of bad news here but have you actually checked the
timings? For something this big GB will most likey (since you should set cut
much larger, ideally have no cut off at all [cut=9999.0]) be slower than
your implicit solvent calculations and also significantly less accurate. I
will let others comment more but my understanding is that GB will be
terrible for highly polar systems such as DNA / RNA. You would probably be
much better trying to improve the performance of your explicit solvent
calculations.

Firstly switch to pmemd which will give you at least a factor of 30 to 40%
performance boost in serial and will scale MUCH better in parallel. If you
have access to a large infiniband system you could probably run the above
out to 256 cores or so. You don't actually say how many atoms your system is
so it is hard to make predictions beyond that. You might also want to
consider switching to AMBER 11 and using PME running on GPUs which will give
you a huge performance boost if your system fits within the available memory
on the GPU.

> I would appreciate comments/corrections on the parameters used, and
> general comments
> on the applicability of the GB method to large RNA molecules.

Leaving aside the fact that GB is probably terrible for such a large system
and bad for nucleic acids anyway I will try to at least help with your input
settings.

> 2. Minimization input:
>
> &cntrl
> imin=1, ntx=1, drms=0.01,

This is a VERY larger drms value, I would just remove it from the input file
and leave it at the default.

> cut=999,

Good.

> ntpr=100, ntwx=100, ntwe=100,

Probably not much point setting ntwe unless you really need the energy data
in a separate file. It will take up disk space and slow down the simulation.

> nsnb=20,

Although it won't affect you here since your cut off is larger than your
system my general advice is DO NOT MESS WITH THIS VALUE!!! - Just remove it
from the input file and leave it at the default. Sander and pmemd just "Do
the right thing"(tm) when it comes to building the list if you leave this at
the default.

> maxcyc=20000, ncyc=1000,
> igb=1, saltcon=1.0, ntt=0, offset=0.13,

Why are you messing with the 'offset' value????? - Just leave it at the
default!

> gbsa=1, ntb=0,
> &end

Do you really need the surface area term included in your minimization and
MD calculations? It is a pretty terrible approximation and you might be
better just leaving it off unless you want to do things like GBSA/PBSA.

> 3. Heating
> &cntrl
> imin=0, ntx=1,
> irest=0, ntxo=1,
> cut=999, tempi=0.0,
> ntpr=500, ntwx=500, ntwe=500,

ntwe=0 unless you want the file.

> nstlim=100000, tautp=0.5, temp0=300.0,

You should NOT use Berendsen for GB simulations. Particularly during the
heating phase. I would suggest using Langevin (ntt=3) with a reasonable
coupling constant (gamma_ln=1.0) or so. This will equilibrate the
temperature much better.

> dt=0.001, nscm=100,

You should probably turn on shake (ntf=2,ntc=2). 1fs is kind of on the
bleeding edge for running without shake. I suggest dt=0.002 and ntf=2,ntc=2.
nscm can just be left at the default of 1000. Or probably best to set it to
zero if you are running with langevin and restraints.

> igb=1,ntb=0, saltcon=0.5, gbsa=1,

gbsa=0 unless you need it. Why did you change the salt concentration from
the minimization???

> ntt=1, nsnb=20, offset=0.13, ntr=1

ntt=3, gamma_ln=1.0, remove nsnb, remove offset!

> &end
> GROUP FOR CONSTRAINTS
> 20.0
> RES 1 264
> END
> END

Probably best to use slightly weaker restraints for the heating here,
otherwise you just put a lot of heat into your restraints. What are you
using as the reference structure -ref? - You should use the minimized
structure, so the same as what you have for your -c.

> 4. MD with constraints (last of 4 phases shown):

You mean 'restraints' not constraints I assume.

> &cntrl
> imin=0, ntx=5,
> irest=1, ntxo=1,
> cut=999, tempi=300.0,

tempi is ignored when irest=1.

> ntpr=1000, ntwx=1000, ntwe=1000,

ntwe=0,

> nstlim=100000, tautp=2, temp0=300.0,

remove tautp, use ntt=3,gamma_ln=1.0,

> dt=0.001, nscm=100,

ntf=2,ntc=2,dt=0.002, remove nscm.

> igb=1, ntb=0, saltcon=0.5, gbsa=1,

gbsa=0, use the same saltcon everywhere.

> ntt=1, nsnb=20, offset=0.13, ntr=1,

remove nsnb and offset.

> &end
> GROUP FOR CONSTRAINTS

Restraints!!!

> 5. MD input (things go awry v. quickly)
> MD-RUN GBSA production run with Berendsen thermostat (ntt=1)
> &cntrl
> imin=0,ntx=5,
> irest=1, ntxo=1,
> igb=1, cut=999, gbsa=1, ntb=0, saltcon=0.5,

gbsa=0,

> ntt=1, temp0=300.0, tempi=300.0,

tempi is ignored.

> nscm=100,

remove nscm

> nstlim=1000000,
> dt=0.001, nscm=100,

You have nscm twice??? - ntf=2,ntc=2,dt=0.002

> ntwprt=0,
> ntpr=1000, ntwx=1000, ntwe=1000,

ntwe=0

> nsnb=20, offset=0.13, tautp=2,

remove nsnb, offset and tautp, set ntt=3,gamma_ln=1.0 (although you could in
principal use Berendsen here once things have relaxed / equilibrated BUT you
should probably run without restraints with ntt=3 for a bit first.)

> ig=-1,

Good :-)

> &wt
> type='END'
> &end

This part is not needed.

So I would make these changes and see how things go but I think you might be
pushing GB way beyond what it was designed for.

Just for good measure also make sure all the test cases pass for your AMBER
installation, there could be something wrong with your actual installation.

All the best
Ross

/\
\/
|\oss Walker

---------------------------------------------------------
| Assistant Research Professor |
| San Diego Supercomputer Center |
| Adjunct Assistant Professor |
| Dept. of Chemistry and Biochemistry |
| University of California San Diego |
| NVIDIA Fellow |
| http://www.rosswalker.co.uk | http://www.wmd-lab.org/ |
| Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
---------------------------------------------------------

Note: Electronic Mail is not secure, has no guarantee of delivery, may not
be read every day, and should not be used for urgent or sensitive issues.





_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Sep 22 2011 - 10:00:02 PDT
Custom Search