I actually thought about doing something like that when I first started
doing simulations with LAMMPS. However, I realized relatively quickly
that it wasn't possible OR practical to do so. Imagine this scenario:
start with a very energetic atom so dt/reset picks a time step of 1E-7 ps.
Say you want to dump every 1 fs, so you use the fictional command
dump_time 1 all atom 0.001 dump.myfile
where 0.001 is the time interval. However, after a few thousand steps,
your energetic atom has lost energy, so now dt/reset chooses a time step
of 1E-3 ps. In order for the dump command to create dumps at the
appropriate intervals, you have to dump EVERY time step now! And if you
decide you want every 0.1 fs early on, to catch the detail of the really
fast-moving atom, you then need to write TEN dumps every time step once
things slow down. This probably isn't what you want, since (a) your dump
files would be ridiculously big, and (2) the atoms won't move much in
one time step (which of course is the point of dt/reset in the first
place). And of course they won't move at ALL in 0.1 time steps.
I assume what you really want is a movie that shows frames in real time
that correspond to equivalent lengths of simulation time (e.g., 1ps passes
every second of movie). This can be simulated, in principle, by frame
copying in a post-processing environment. In practice, I haven't tried to
do it yet, but the thought has crossed my mind. Instead, what I did was
write a script that processes my output files and grabs the real time
value from the dt/reset fix, then creates subtitles for the movies that
indicate the "real" time corresponding to each frame (which then advances
at a non-constant rate in the movie).
Karl D. Hammond
hi karl,
I actually thought about doing something like that when I first started
doing simulations with LAMMPS. However, I realized relatively quickly
that it wasn't possible OR practical to do so. Imagine this scenario:
start with a very energetic atom so dt/reset picks a time step of 1E-7 ps.
Say you want to dump every 1 fs, so you use the fictional command
dump_time 1 all atom 0.001 dump.myfile
where 0.001 is the time interval. However, after a few thousand steps,
your energetic atom has lost energy, so now dt/reset chooses a time step
of 1E-3 ps. In order for the dump command to create dumps at the
appropriate intervals, you have to dump EVERY time step now! And if you
decide you want every 0.1 fs early on, to catch the detail of the really
fast-moving atom, you then need to write TEN dumps every time step once
things slow down. This probably isn't what you want, since (a) your dump
files would be ridiculously big, and (2) the atoms won't move much in
one time step (which of course is the point of dt/reset in the first
place). And of course they won't move at ALL in 0.1 time steps.
this raises another interesting question:
what would be a more effective/suitable
file format for storing data in situations
like you describe, or the more common
case, where a significant chunk of atoms
simply don't move. also, what would be
a good "approximate" way to store trajectories
in a way that a visualization program can
easily and reasonably accurately interpolate
between actually stored frames and
do so with high-frequency "noise" removed,
so that one can get a better look at
longer-timescale behavior.
i don't know a good answer to that, i only
have a few ideas, that might be worth
exploring. any input, potential use cases,
and suggestions on this kind of topic
would be highly welcome.
I assume what you really want is a movie that shows frames in real time
that correspond to equivalent lengths of simulation time (e.g., 1ps passes
every second of movie). This can be simulated, in principle, by frame
copying in a post-processing environment. In practice, I haven't tried to
do it yet, but the thought has crossed my mind. Instead, what I did was
interesting. indeed this could be scripted into a program like VMD.
cheers,
axel.
Hello,
@ Karl: You might be right, saying that dumping every certain time interval is not practical while using fix dt/reset. But I also needed something similar for another reason, so I also tried to get it work with the dumping.
Using “if-loops” like that works:
hi sebastian,
[...]
- the only thing which I didn't get working is the themo_style custom
keywords tpcpu and spcpu, to get information about how fast LAMMPS is in
which part of my loops, which would be a very important information for me
(LAMMPS says "Invalid keyword in thermo_style custom command").
whenever you encounter a problem like this, please always
tell us which version of lammps are you using.
Can you tell me what is the problem about this?
well, either your version of lammps is too old (those
flags were added quite a while ago, but still...) or
there is a bug that needs to be tracked down.
please note, that those keywords require at least two
consecutive steps to collect sufficient time information.
you may also consider adding "pre no" "post no" to your
short "run"s inside the loop to save setup time.
cheers,
axel.