[lammps-users] Dump at offset timesteps

Hello lammps-users,

I am running some simulations that require post-processing dump files. Currently, the dump command I use writes the dump files at intervals of 10000 timesteps:

dump id all custom 10000 dump.vibrate.*.bin &
      id type radius x y z vx vy vz

However, I now find myself also needing dumps that are 100 timesteps after the ones that are currently output. So, for instance, at timesteps 10000, 10100, 20000, 20100, 30000, 30100, etc.

Is there an easy way to do this in LAMMPS? I don't want to just dump every 100 timesteps as that would be a huge amount of data.


How about doing two separate (but identical) dumps with the second one delayed by 100 timesteps relative to the first. This can be done by issuing the first dump command, running 100 timesteps, issuing the second dump command, and then continuing for the long run.


The problem with that solution is the dumps only happen on timesteps which are a multiple of N (= 10000), starting at 0. So if I do:

dump 1 all custom 10000 dump.test.1 &
      id type radius x y z vx vy vz
run 100
dump 2 all custom 10000 dump.test.2 &
      id type radius x y z vx vy vz
run ${run_time} upto

I get timestep 0 in dump.test.1 and timesteps 10000, 20000, 30000, etc. in both dump.test.1 and dump.test.2 files.

A good solution might be to add a keyword "start" to the dump_modify command. There is already a "first" keyword, but it doesn't seem to do this.

Yes, you're right. How about using a loop structure something like this:

Dump 1 n=10000
Start loop
  Dump 2 n=100
  Run 100
  Undump 2
  Run 9900
End loop


That almost works. It is impossible to create a single dump.test.2 containing all the timesteps I want using this method, as it will be overwritten each time through the loop. But I can work with one dump file per timestep.

In fact, only one dump command is necessary using this method. Here is the solution that works for me:

# variables for convenience
variable run_time equal "100000"
variable output_time equal "10000"
variable output_after_time equal "100"
variable output_remaining_time equal "v_output_time - v_output_after_time"
variable num_loops equal "v_run_time / v_output_time"

# fancy loop for dumping
label loop_output
variable i loop \{num\_loops\}    dump 1 all custom {output_after_time} dump.test.* &
                 id type radius x y z vx vy vz
   run \{output\_after\_time\}    undump 1    run {output_remaining_time}
next i
jump in.test loop_output

This will create files dump.test.0, dump.test.100, dump.test.10000, dump.test.10100, etc. The log output is really messy because of all the looping, but that's ok.

Thanks a bunch.

See the 7Aug10 patch. I saw a way to generalize this.
There is now a stagger() and logfreq() math function
allowed for variables, and you can use the dump_modify every
variable command to use a variable to generate the
sequence of timesteps at which dump snapshots will be
written. The stagger() option does what you initially
requested in this thread.


Wow, thanks Steve. The stagger() function is exactly what I needed. Here is my new use case:

variable output_timesteps equal "stagger(10000, 100)"

dump 1 all custom 1 dump.test.* &
             id type radius x y z vx vy vz
dump_modify 1 every v_output_timesteps
run ${run_time}

This works great. There are a few issues though:

1) It doesn't dump on timestep 0. This can be solved by inserting "run 0" after the dump command, but before the dump_modify command.

2) The variable doc page says "Thus if stagger(1000,100) is used in a variable by the dump_modify frequency command..." This should probably be "...the dump_modify every command..."

3) Is there a way to do this with thermo output also? I liked being able to thermo and dump at the same frequency.

Thanks a lot!

The dump modify doc page mentions that you need to use dump_modify first yes
if you want the first step when using the variable. I'll change the doc
for the other one. Need to think about doing this for thermo also.


3) Is there a way to do this with thermo output also?

Added a 12Aug patch with a thermo_modify every option
for this.