Hello everyone,
I’ve been using LAMMPS with the MedeA software (don’t know if it is important)
I did tests using write_restart at the end of a calculation then read_restart at the beginning of the other. And I did the same with write_data and read_data.
I’ve got a problem with both the methods :
With the restart method:
ERROR: Invalid flag in header section of restart file (…/read_restart.cpp:912)
And with the data method :
ERROR: No bonds allowed with this atom style (…/read_data.cpp:1182)
I’m guessing it is the same issue but with different methods.
I am using the same version of LAMMPS and MedeA.
Thank you,
Hugo.
Which is the exact LAMMPS version that you are using?
Which LAMMPS version did generate the restart file?
What is the output up to the error message?
You are guessing wrong. The data file contains far less information than the restart file and some of that needs to be set before reading the data file. The specific error is due to not setting the correct atom style, which is one of the settings that is stored in a restart file, but not in a data file.
Please note that I probably won’t be able to change the version if it’s a version problem.
I am using the 29 Oct 2020 version.
the restart file is from the 29 Oct 2020 version.
the output :
Running LAMMPS on 32 cores :
Using executable /home/acimas/MD/TaskServer/Tools/LAMMPS29Oct20/Linux-x86_64/LAMMPS
LAMMPS (29 Oct 2020)
OMP_NUM_THREADS environment is not set. Defaulting to 1 thread. (…/comm.cpp:94)
using 1 OpenMP thread(s) per MPI task
Reading restart file …
restart file = 29 Oct 2020, LAMMPS = 29 Oct 2020
restoring atom style full from restart
ERROR: Invalid flag in header section of restart file (…/read_restart.cpp:912)
Last command: read_restart /home/acimas/MD/Jobs/dir500/661/Stage_2/save_last_frame
Hope that answers your questions 
Thanks. This helps, but it also raises some additional issues.
The error message you describe could only happen, if you would move a restart file between different platforms. I have compiled a LAMMPS executable for the same version and modified the “rhodo” benchmark input to write out a restart file and then in a second run to read the system from the restart file instead of the data file. On my machine there is no problem restarting with that version. Can you reproduce the error by modifying the rhodo input deck? If yes, please provide the two versions (one for writing, one for reading) for further inspection.
There is no easy explanation for what could be the reason for this unexpected behavior. At the moment, I can only speculate. Here are some possible reasons:
- your restart file was transferred to a different computer with FTP in text mode
- your restart file was damaged (unlikely)
- your file system is corrupted or your hard drives are failing (very unlikely)
- your file was corrupted because multiple simulations are trying to write to it at the same time (very unlikely)
- you are using a feature in LAMMPS that has an incorrect restart support (unlikely)
- there is a bug somewhere (which may or may not be fixed in a more recent version)
Without a way for me to reproduce the issue, I will not be able to make a suggestion on avoiding it. Using read_data is a possible option, but you need to use it correctly or else you get errors due to missing settings. Since we won’t be applying any bugfixes to versions that have been superseded, it would be very important to us to know if this issue can be reproduced with the latest LAMMPS version. While you may not be able to replace the version of LAMMPS on your MedeA appliance, you should be able to install it on a different machine. The easiest would be to install a precompiled version e.g. on Fedora/CentOS/RHEL/SuSE Linux as RPM or on Windows with an installer package. That way you could confirm whether the issue is still present in the latest version of LAMMPS (we released version 4 May 2022 just yesterday) and thus needs to be investigated further or whether it is already resolved.