Hi all,
At the end of an NPT relaxation, before switching to NVE (and fixing the volume), I'd like to make sure that I fix the volume corresponding to the pressure I was aiming for during the NPT. In other words I'd like to avoid starting my NVE production with a volume that corresponds to the maximum or minimum of the pressure curve, which fluctuates a lot in MD (for small systems at least).
The same concern may arrise when thermostatting and I think some people impose the temperature at the end of the thermalization with:
velocity all scale ${target_temperature}
Similarly, is there a command that I could call at the end of an NPT run and that would change the volume to the one corresponding to the target pressure?
Thanks,
Jonathan Severin
Hi Jonathan
The following command may be helpful.
http://lammps.sandia.gov/doc/fix_box_relax.html
Arun
Hi Arun,
I didn’t know box_relax offered a Ptarget keyword. Thank you I’ll try it.
Jonathan
Hi all,
At the end of an NPT relaxation, before switching to NVE (and fixing the
volume), I'd like to make sure that I fix the volume corresponding to the
pressure I was aiming for during the NPT. In other words I'd like to avoid
starting my NVE production with a volume that corresponds to the maximum or
minimum of the pressure curve, which fluctuates a lot in MD (for small
systems at least).
what i would recommend is the following:
- equilibrate with npT and record a suitably chosen sliding window average
of the x, y, and z dimensions (or volume) of the box
- use change_box to adjust to a suitable averaged volume at the end of the
run and switch to nVT while recording the (sliding window) averaged
pressure.
- if you meet the target pressure (note, that small changes in volume have
large changes in pressure due to the low compressibility of condensed phase
media), switch to nVE, otherwise manually adjust the volume slightly and
repeat until you are happy
- continue with nVE *without* rescaling of velocities. while your final
instantaneous temperature may not be your desired target, it is
*consistent* with the average and the instantaneous potential energy. if
you change the kinetic energy, you'll undo part of your equilibration.
consider your system like a kid on a swing (i.e. a harmonic oscillator): at
the turning points, the kinetic energy (i.e. temperature) is zero (but
potential energy maximal) and in the middle position kinetic energy is
maximal (but potential energy minimal). if you rescale, you would slow
down, when in the center, or add a kick when at the turning point and thus
change the equilibrium state.
The same concern may arrise when thermostatting and I think some people
impose the temperature at the end of the thermalization with:
velocity all scale ${target_temperature}
these people may have a misconception of what equilibration means. to me
this does not make sense, considering the reasoning and protocol from above.
Similarly, is there a command that I could call at the end of an NPT run
and that would change the volume to the one corresponding to the target
pressure?
see above.
axel.
Hi Axel,
Thank you for the advice. I was doing more or less what you describe, but in 2 separate phases: first the NPT, then some post process analysis to identify the correct volume and then a new run at constant volume. But it is somehow inconvenient to have 2 separate phases for one simulation (especially given the queueing time on HPC clusters…). I hope to find a way to do the window averaging and conditional switch to NVE in an automated process.
Jonathan
Hi Axel,
Thank you for the advice. I was doing more or less what you describe, but
in 2 separate phases: first the NPT, then some post process analysis to
identify the correct volume and then a new run at constant volume. But it
is somehow inconvenient to have 2 separate phases for one simulation
(especially given the queueing time on HPC clusters...). I hope to find a
way to do the window averaging and conditional switch to NVE in an
automated process.
http://lammps.sandia.gov/doc/fix_ave_time.html
as for making effective use of HPC clusters. that is more a matter of planning your work than anything else.
- most of the time, equilibration is only a very small part of the total run, so it doesn’t really matter if you “lose a slot” for that.
- if equilibration takes about as much time as production or more, then you are likely running many different systems. for that you can just bundle multiple systems into a single equilibration submission and run them one after the other.
- automating steps really only makes sense when something is very deterministic and doesn’t need the human eye for making qualified choices. translated into compute simulation this means, that you will have to run your equilibration much longer, to be dead certain, that the final average is fully converged. for different systems, different time periods may be needed and runs may have to be repeated. so your automated script may end up consuming much more CPU time, than the human managed. which of those is the greater bother (wasted CPU time or more manual work) is an individual choice.
axel.