fix ave/atom issues: deciphering "dump custom and fix not at compatible times"

LAMMPS LAMMPS Mailing List Mirror
1

Hi Everyone,

I have run into a fix ave/atom related error using LAMMPS, and I could not find a mailing list thread discussing this already.

I want to use this fix to average per-atom values over a run.
My understanding from the manual (link), is that to average at the timestep 100 over the 6 preceeding timesteps 90,92,94,96,98,100: Nevery=2, Nrepeat=6, and Nfreq=100.

Nrepeat is 6, and not 5, because you have to count the starting step 90 as well.
Nfreq seems to be the 100th timestep since the run, and not the 100th timestep overall in the simulation.

The manual also says: “The per-atom values can only be accessed on timesteps that are multiples of Nfreq since that is when averaging is performed.”

Seems pretty straightforward, but here’s the problem:

fix avg all ave/atom 2 6 100 x y z #syntax: fix ID group-ID ave/atom Nevery Nrepeat Nfreq value1 value2 ...
run 400 every 200 "write_dump all custom ${filename} id type mass f_avg[*]"

This script is supposed to average values every 100th timestep. At the 200th timestep, the fix should have been evaluated twice.
Also, at the the 200th run the dump script should be executed.

However, I get the error:

ERROR: Dump custom and fix not computed at compatible times (../dump_custom.cpp:340)
Last command: write_dump all custom ${filename} id type mass f_avg[*]

I am stumped as to why this might be happening. Would greatly appreciate any leads on this matter.

Stay safe and healthy,

Best,
Praneeth

2

please take note what is the initial timestep number.
the selection of the timestep is based on the timestep number, not on how many timesteps have been executed in the run.
if you first do a minimization, that initial number may be not a multiple of 100

… and why do you use run every with write_dump and not just the dump command for regular dump output?

axel.

3

Dear Axel,

Thanks for the quick response! The issue is solved! … partially.

The script works when written this way:
fix avg all ave/atom 2 6 100 x y z
dump d all custom 200 foo id type mass f_avg[*]
run 400

but the error` "```ERROR: Dump custom and fix not computed at compatible times"seems to show up again when written like:fix avg all ave/atom 2 6 100 x y z run 400 write_dump all custom foo2 id type mass f_avg[*]``

The script will also not work when written in this more clumsy way:
fix avg all ave/atom 2 6 100 x y z
run 400 #every 200 "write_dump all custom foo id type mass f_avg[*]"

This is counter intuitive because all the snippets are essentially the same thing… and I personally would be happy if snippet #2 with the write_dump would work as it is more convenient for my postprocessing scripts.

I am attaching a modified version of the lammps/bench/in.lj and the corresponding output to this email. Could anyone please take a look? Thank you!

P.S. To answer your question “… and why do you use run every with write_dump and not just the dump command for regular dump output?” :
It was an artifact of my effort to make a minimal working example from my existing script, which already happened to have a write_dump command.

Thanks,
Praneeth

in.lj (1.29 KB)

lj.out (2.31 KB)

4

Dear Axel,

[…]

but the error` “```ERROR: Dump custom and fix not computed at compatible times”`` seems to show up again when written like:

fix avg all ave/atom 2 6 100 x y z
run 400
write_dump all custom foo2 id type mass f_avg[*]

that is for technical reasons. the write_dump command is not really a standalone command, but rather sets up a dump style as with the dump command, and then triggers its output once. for that it sets the dump frequency to “1”, which collides with your fix’ output frequency of 100.

this is not going to be easy to resolve. in the case of write_dump, a different kind of test should be made, that does not make sense for the regular dump command. however, getting this into that code anyway and without interfering with normal operations is non-trivial. and replicating the dump code for the write_dump command is not going to happen.

so for the time being you will have to make do with just the dump command.

axel.