Thanks. That was a new thing for me to learn. On 15 February 2012 23:19, Mark Abraham <mark.abra...@anu.edu.au> wrote:
> On 16/02/2012 3:14 PM, Juliette N. wrote: > > > > On 15 February 2012 23:05, Mark Abraham <mark.abra...@anu.edu.au> wrote: > >> On 16/02/2012 2:08 PM, Juliette N. wrote: >> >> >> >> On 15 February 2012 21:00, Mark Abraham <mark.abra...@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. > > > So it's much more bureaucracy every nstlist>0 steps to take your N atoms > and look at their distance from the other N-1 atoms and make lists of which > ones are inside rc than it is to just compute them all every step and know > that if they're further than rc then the effect is tiny. For small enough > N, the later is guaranteed to be faster... > > Mark > > -- > gmx-users mailing list gmx-users@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-requ...@gromacs.org. > Can't post? Read http://www.gromacs.org/Support/Mailing_Lists > -- Thanks, J. N.
-- gmx-users mailing list gmx-users@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-requ...@gromacs.org. Can't post? Read http://www.gromacs.org/Support/Mailing_Lists