[gmx-users] remd

[Richard Broadbent]

On 02/07/13 12:10, Justin Lemkul wrote:
> 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.
>
Yes sorry that's my mistake I should never respond to the mailing list 
before having my morning coffee. Infinite cutoffs are specified with 
rlist=0 etc.

Sorry for the confusion.

Richard
>
>> 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>
>>
>
>
>