[lammps-users] Possible error in read_dump command/read_dump feature request

Hi LAMMPS developers,

Thanks a lot for the continued support and updates to the LAMMPS codes. I recently tried out the read_dump command.
I don’t know why I didn’t notice this before, but it is a great feature to have!

I used read_dump to input a configuration of atoms, and I wanted to perform a minimization after this.
Please have a look at the snippet, where “l” is the LAMMPS object in python. (LAMMPS version 29 Oct 2020)

#units, boundaries, box info, etc

1 l.command(“read_dump x y z vx vy vz box yes replace yes add yes”) #input

2 l.command(“compute c2 all pe/atom”) #thermo and pair styles stuff
3 l.command(“neigh_modify every 1 delay 0 check yes”)
4 l.command(“pair_style eam/fs”)
5 l.command(“pair_coeff * * Cu-Zr_4.eam.fs Cu Zr Cu Zr”)
6 l.command(“thermo_style custom step pe ke press temp”)
7 l.command(“thermo_modify format float ‘% .6e’”)

8 l.command(“min_style fire”) #minimization and saving pe/atom data
9 l.command(“minimize 1e-10 1e-10 100 100”)
10 l.command(“fix fpe all ave/atom 1 1 1 c_c2”)
11 l.command(“run 0 pre yes post no”)

12 l.command(“variable pe_reduced equal (pe)") #outputs (thermo info --> variable) 13 l.command("print 'Total PE {pe_red}’”)
14 l.command(“write_dump all custom dump. id type x y z vx vy vz f_fpe”)

In the following output, there is a discrepancy in the potential energy data output from line 13.
The value was in the order of the potential energy per atom, not the total potential energy.
The same snippet, but with a read_data/read_restart command (+relevant additions in initialize section), yields the right values of potential energies.

The a single snapshot of the LAMMPS dump files stores similar or more data than a data file, so I am unsure where there is a loss.
I understand that read_dump is supposed to replace previous info and is unlike the read_data/read_restart where info is added into the system.
So I assume the error is in the implementation of read_dump.

Did I do something wrong? Or is my problem too complicated to solve? In any case, here is also a feature request:
since read_dump is able to read dump files, would it be possible to make it read any per-atom data?
In such a case, one could simply just read in old data and “set” per-atom values such as f_fpe (defined in line 10 of above snippet).
That way, one could read into LAMMPS some per-atom data which is only possible with read_restart (read_data doesn’t recognise custom per-atom values in data file)

If I could get this read_dump command to work perfectly, it would be a great addition to the post-processing scripts.

Thanks a lot for reading this far and I hope my contribution is of some help to the LAMMPS community.

Have a great day!
Praneeth

It is not clear from your description and incomplete inputs what it is exactly that you are trying to do.
If you want somebody to have a closer look you need to a) provide regular LAMMPS input files, and b) set up a minimal example, best based on one of the example systems in the examples tree of the LAMMPS distribution that cleanly demonstrates the mismatch that you are seeing.

axel.

Dear Axel,

Thank you for your response. Over the weekend, I figured out the problem: My mistake was that I did not mention the correct units in my initialization section of the scripts.
In my previous email I had said that the potential energy values were not being read correctly, but it works now.
For anybody reading this mail thread in the future: I was wrong about there being an issue with the read_dump command reading in the values.

As for the feature request, I would still like to request a possibility to read more types of per-atom info from read_dump (such as custom per-atom variables).

This could be helpful in the case of a simulation crash due to wall time limit or a computing node failure during a run, the file with the most recent info would be a dump file,
and not a restart file from before the current run. If one could read a dump file with most info, then it could prevent the need to make a re-run.

Of course, a counter argument could be made by saying that a “run every” command could be used to output the most current restart file. But that would only help as a premeasure,
and not after one’s code has crashed.

Thanks!
Praneeth

[…]

As for the feature request, I would still like to request a possibility to read more types of per-atom info from read_dump (such as custom per-atom variables).

This could be helpful in the case of a simulation crash due to wall time limit or a computing node failure during a run, the file with the most recent info would be a dump file,
and not a restart file from before the current run. If one could read a dump file with most info, then it could prevent the need to make a re-run.

Of course, a counter argument could be made by saying that a “run every” command could be used to output the most current restart file. But that would only help as a premeasure,
and not after one’s code has crashed.

there is no need to use “every” to have regular restart files written, there is the “restart” command and that is how restarts are supposed to be done. it looks like you are not restarting correctly. usually the frequency of restart writing should be chosen so that the overhead is small compared to the overall simulation time (i.e. you can write out restarts more often for “expensive” potentials than for “cheap”) but then also the amount of simulation time lost is generally negligible compare to the manual effort of recovering and restarting. it is generally best practice to break down long and expensive simulations into parts and write out dump and outputs in parts as well, so restarting from the latest restart will only create a small overlap of output data that can be easily eliminated in post-processing. please note that writing formatted dump files is causing significantly more overhead than writing binary (restart) files.

people who don’t write regular restarts during a time consuming simulation are making an easily preventable mistake.

axel.