[gmx-users] remd

[Justin Lemkul]

On Tue, Jul 2, 2013 at 5:30 AM, Richard Broadbent <
richard.broadbent09 at imperial.ac.uk> wrote:

> Not sure exactly what merging together means, for visualisation I
> generally use vmd as this supports gromacs files directly.
>
>
If I understand correctly (and the OP can clarify if I haven't), it sounds
like visualization of the average structure shows atoms overlapping one
another.  One should not necessarily expect anything reasonable from an
average structure.

http://www.gromacs.org/Documentation/Terminology/Average_Structure



> Your problem might be to do with, using rlist, rcoulomb, and rvdw set to 0
> is not the standard way to do an infinite cut-off normally you set them to
> -1 as in the manual.
>
>
I have never seen cutoffs set to -1. Is this a special trick in the code?
The OP's settings are correct for infinite cutoffs and use of all-vs-all
kernels.


> Also the AMBER force field was parametrised with a cut-off it might,
> depending on what you are trying to do, be advisable to use the cut-off
> specified in the original papers and the wider literature for the AMBER
> force field.
>
>
This is an important point, but finite cutoffs like those used in
explicit-solvent simulations (on the order of 1.0 nm) have, in my hands,
produced terrible results in an implicit environment (poor energy
conservation, loss of structure, etc).  Longer cutoffs are generally
recommended, and I only ever use infinite cutoffs in implicit systems.  It
is definitely worth some time doing validation of one's settings.


> Richard
>
>
> On 02/07/13 10:07, Shine A wrote:
>
>> Sir,
>>
>>        I did a 10 ns  REMD simulation for a peptide, 8 replicas using
>> amber
>> force field.Then extracted pdb file from the trajectory and clustered
>> using
>> g_cluster. The I viewed the average structure of the cluster in pymol .But
>> here the atoms are merged togather.why it happends?Is there any problem
>> with my force field? My md.mdp file as follows.
>>
>> RESHELIX ; -DFLEXIBLE -DPOSRES
>>   constraints         =  none
>>   integrator          =  md
>>   dt                  =  0.001   ; ps
>>   nsteps              =  10000000 ; 10000 ps = 10 ns
>>   nstcomm             =  10
>>   nstcalcenergy       =  10
>>   nstxout             =  500     ; frequency to write coordinates to
>> output
>>   trajectory
>>   nstvout             =  0       ; frequency to write velocities to output
>>   trajectory; the last velocities are always written
>>   nstfout             =  0       ; frequency to write forces to output
>>   trajectory
>>   nstlog              =  1000         ; frequency to write energies to log
>>   file
>>   nstenergy           =  1000     ; frequency to write energies to edr
>> file
>>
>>   vdwtype             =  cut-off
>>   coulombtype         =  cut-off
>>
>>   pbc                 =  no
>>
>>   nstlist             =  0
>>   ns_type             =  simple
>>   rlist               =  0       ; this means all-vs-all (no cut-off),
>> which
>>   gets expensive for bigger systems
>>   rcoulomb            =  0
>>   rvdw                =  0
>>
>>   comm-mode           =  angular
>>   comm-grps           =  system
>>
>>   optimize_fft        =  yes
>>
>>   ; V-rescale temperature coupling is on
>>   Tcoupl              =  v-rescale
>>   tau_t               =  0.1
>>   tc_grps             =  system
>>   ref_t               =  376.32
>>   ; Pressure coupling is off
>>   Pcoupl              =  no
>>   ; Generate velocites is on
>>   gen_vel             =  yes
>>   gen_temp            =  270
>>
>
This doesn't make much sense to me.  If you're generating velocities, you
should be generating them for the target temperature.  If not, your
thermostat has to do some funny things to get it back on track.  With
V-rescale (or Berendsen, for that matter), you may not have an issue since
it relaxes quickly.  Other thermostats will cause you grief.

-Justin


>   gen_seed            =  -1
>>
>>   ;
>>   ; Implicit solvent
>>   ;
>>   implicit_solvent    =  GBSA
>>   gb_algorithm        =  Still ; HCT ; OBC
>>   nstgbradii          =  1
>>   rgbradii            =  0   ; [nm] Cut-off for the calculation of the
>> Born radii. Currently must be equal to rlist
>>   gb_epsilon_solvent  =  80    ; Dielectric constant for the implicit
>> solvent
>>   ; gb_saltconc       =  0     ; Salt concentration for implicit
>> solvent   models, currently not used
>>   sa_algorithm        =  Ace-approximation
>>   sa_surface_tension  = -1
>>
>>  --
> gmx-users mailing list    gmx-users at gromacs.org
> http://lists.gromacs.org/**mailman/listinfo/gmx-users<http://lists.gromacs.org/mailman/listinfo/gmx-users>
> * Please search the archive at http://www.gromacs.org/**
> Support/Mailing_Lists/Search<http://www.gromacs.org/Support/Mailing_Lists/Search>before posting!
> * Please don't post (un)subscribe requests to the list. Use the www
> interface or send it to gmx-users-request at gromacs.org.
> * Can't post? Read http://www.gromacs.org/**Support/Mailing_Lists<http://www.gromacs.org/Support/Mailing_Lists>
>



-- 

==========================================

Justin A. Lemkul, Ph.D.
Postdoctoral Associate

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

jalemkul at outerbanks.umaryland.edu | (410) 706-7441


==========================================