clear
units metal
atom_style atomic
atom_modify map yes
read_restart restart.nvtvc.2600.pure.5ns #make vacancy
group silicon type 1
group carbon type 2
group del id 1521
delete_atoms group del compress no
reset_atom_ids sort yes
velocity all create 2600.0 87287 rot yes dist gaussian
pair_style edip/multi
pair_coeff * * /usr/local/Cellar/lammps/20220623/share/lammps/potentials/SiC.edip Si C
fix 1 all nvt temp 2600.0 2600.0 $(120.0*dt)
I am using LAMMPS version 20 Nov 2019, moreover If I somehow manage to bypass this error I found this mapping error for compute voronoi/atom command although I have clearly specified mapping.
ERROR: Compute voronoi/atom occupation requires an atom map, see atom_modify (src/VORONOI/compute_voronoi_atom.cpp:133)
Last command: compute voro all voronoi/atom occupation
You have to check carefully that your command is using all ASCII characters. If you cut-n-paste from some PDF file or webbrowser, they may have replaced some ASCII characters with similar looking UTF-8 characters so it “looks better”. This happens particularly often with whitespace.
Newer LAMMPS versions can detect such cases, and for known cases even correct the input file while reading it.
I have to try to type the command once again but getting the same errors , can you suggest how i can use pre compiled Latest version of LAMMPS without installation ? here is the error I am getting
mpirun -np 10 lmp -in in.voronoi
No protocol specified
LAMMPS (20 Nov 2019)
Reading restart file …
restart file = 20 Nov 2019, LAMMPS = 20 Nov 2019
restoring atom style atomic from restart
orthogonal box = (-0.283837 -0.283837 -0.283837) to (26.4678 26.4678 26.4678)
1 by 2 by 5 MPI processor grid
pair style edip/multi stores no restart info
1728 atoms
read_restart CPU = 0.00148796 secs
864 atoms in group silicon
864 atoms in group carbon
1 atoms in group del
Deleted 1 atoms, new total = 1727
Reading potential file /usr/local/Cellar/lammps/20220623/share/lammps/potentials/SiC.edip with DATE: 2017-05-16
Resetting global fix info from restart file:
fix style: nvt, fix ID: 1
ERROR: Compute voronoi/atom occupation requires an atom map, see atom_modify (src/VORONOI/compute_voronoi_atom.cpp:133)
Last command: compute voro all voronoi/atom occupation
Primary job terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
mpirun detected that one or more processes exited with non-zero status, thus causing
the job to be terminated. The first process to do so was:
Dear Dr akohlmey.For now I am not allowed to install the latest version on server so I couldn’t make test, but I noticed the problem didn’t arise when I dont read restart file and provide the lamps data file. can you suggest something in this case, except converting restart file to data file using lammps scripts and than using it for further calculation. I am looking for more smart option.
Dear Srtee ,offcourse one can do that but if Lammps has more smart functionality of doing calculations why not we should use it, self post processing is more probable for making mistakes i want to avoid that. there must be some solution of this.
This is nonsense. You can always compile/download and install software into your home directory. Otherwise such servers would be of no use to computational scientists that use only in-house code. I have been running simulations since grad school, 25 years ago and on any machine I have always used self-compiled versions of the software, because I wanted to make certain I have an executable that is giving the best performance and perfectly optimized for both, the hardware in question and the simulations that I was planning to run.
So what keeps you from placing the atom_modify command after the read_restart command?
Converting the restart to a data file and using that as a starting point for a new simulation is actually quite a smart option, since it strips off all legacy settings that you would inherit from the restart file. Also it makes your simulation more reproducible, since with the data file, you can re-run the simulation, if needed, with a different LAMMPS version. With binary restarts there are limitations, since there are occasionally changes and bugfixes to the restarting procedure that are not backward compatible. Restart file should primarily be used for continuing a trajectory, where you want to inherit all settings.
If you cannot trust yourself to properly set up a simulation from scratch that is continued from a previous simulation that you have set up, you have a much bigger problem than the specific detail at hand.
You are giving LAMMPS too much credit here. LAMMPS is not really smart. It does exactly what you tell it to do and most commands are rather single minded in what they are doing. That people do smart things with LAMMPS is mostly due to how people utilize the LAMMPS features in a smart way and how they plan their simulations. As I have already pointed out, your insistence on using a binary restart file is not exactly a smart choice in my book.
Dear Dr. Akohlmey Although I have already catch the mistake and solved the problem. but thank you so much for so much inofrmation, and especially telling me
I was overconfident with LAMMPS and I was actually making my problem more complex. This pushed me making a cross test on using binary restart for continuing simulation and I can plan my simulation accordingly. Thank you once again and have a wonderful weekend