[gmx-users] in vacu simulation

[Juliette N.]

On 15 February 2012 23:05, Mark Abraham <Mark.Abraham at anu.edu.au> wrote:

>  On 16/02/2012 2:08 PM, Juliette N. wrote:
>
>
>
> On 15 February 2012 21:00, Mark Abraham <Mark.Abraham at anu.edu.au> wrote:
>
>> On 16/02/2012 12:22 PM, Justin A. Lemkul wrote:
>>
>>>
>>>
>>> Juliette N. wrote:
>>>
>>>> Hi all,
>>>>
>>>> I am trying to run simulation in vaccum using the the changes shown
>>>> below to the usual mdp file.
>>>> pbc              =  no
>>>>
>>>> ;coulombtype         =  PME   ;vdw-type            =  Shift
>>>> ;        Cut-offs
>>>> rlist               =  0   rcoulomb     =  0
>>>> rvdw              =  0
>>>>
>>>> nstlist             =  0               ns_type          =  simple
>>>>
>>>> Can anyone help me with some short questions please?
>>>>
>>>> 1- for pbc=no, I need to comment
>>>>
>>>> ;coulombtype         =  PME   ;vdw-type            =  Shift
>>>> so it defaults to vdw-type =  Cut-off which are not suitable
>>>> algorithms. Is using cut offs justified for in vacu runs?
>>>>
>>>>
>>> Plain truncations in condensed-phase systems lead to artifacts.  Neither
>>> of those conditions apply here, as you're using infinite cutoffs.
>>>
>>>
>>>> 2- I am not clear about using infinite cutoffs. Why one refers to
>>>> infinite cutoffs when
>>>>
>>>> rlist               =  0   rcoulomb     =  0
>>>> rvdw              =  0     ?
>>>>
>>>> My understanding is that this settings means zero cutoff i.e no
>>>> interaction is calculated. Why does this setting refer to infinite rc?
>>>>
>>>>
>>>>
>>> That's the way the code works.  There are various parameters that can be
>>> set to -1, for instance, and that doesn't mean quantities are calculated
>>> every -1 steps ;)
>>>
>>> Setting cutoffs to zero in this manner mean *all* interactions are
>>> calculated, not none.  Prove it to yourself with a zero-step MD run.  The
>>> nonbonded energy terms will not be zero, as they would in the case that no
>>> interactions would be calculated.
>>>
>>>
>>  Or read about pbc=no in manual section 3.4.9 like I suggested Juliette
>> do earlier this week...
>>
>
> Thanks Justin and Mark. I think you meant 7.3.9 which I did when you
> referred me to that. My problem was that I did not expect rc=0  is *just
> defined* as infinite cutoff in gromacs. To me rc=0 looked more equivalent
> to no interaction than infinite cutff off (all interactions).
>
>
> Sure, but reading the documentation is usually a better idea than making
> assumptions :)
>
> The underlying reason for this behaviour is that it is much easier for the
> person writing the code to have one parameter that occasionally has a
> "special" meaning when it takes a nonsense value (like rc<=0) then it is to
> have a slew of parameters that have to be managed when they are input (and
> checked, and documented) and then possibly passed through a cascade of
> functions (lots of bureaucracy and chances to make errors) before they are
> used. The alternative costs the programmer more time. In an ideal world
> there would be an infinite amount of such time, but given the amount most
> people are prepared to pay for scientific software, that time is severely
> limited.
>
>
>  And also I dont see why do we need to change rc to infinite. I mean if
> force fields dictate cutoffs based on a distance where nonbonded
> interactions are close enough to zero (negligible), what  purpose use of
> infinite cutoff serve?
>
>
> Efficiency, like I said in the first post in this thread. Given that your
> force field was parametrized with given cut-offs for the condensed phase,
> to what purpose do you wish to calculate in vacuo? The perturbation from
> calculating in vacuo will be much larger than the perturbation from the use
> of infinite cut-offs.
>


Thank you. I am looking at potential of a single molecule in vacu for heat
of vap purposes at different temperatures by changing ref_temp and gen_temp
for each run.

>
> Mark
>
> --
> gmx-users mailing list    gmx-users at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-users
> Please search the archive at
> 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
>



-- 
Thanks,
J. N.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-users/attachments/20120215/e0c74abd/attachment.html>