You may find some inspiration in previous post as this error keeps coming back with ReaxFF for similar reasons.
You should also take a look at the documentation, because you are using the temp keyword with fix nve (it may not trigger any error because temp 900.0 900.0 100.0 seem to be ignored by LAMMPS, but I don’t get the logic of having this command + Berendsen thermostat):
Hi Simon, we (LAMMPS developers) probably should make fix ... nve temp ... error out.
But it’s correct to combine fix nve with fix temp/berendsen. Like some other thermostats (such as fix langevin), fix temp/berendsen doesn’t do its own integration of motion, and requires fix nve as an integrator to move the atoms.
Yes, I too find weird that nve makes no check for optional arguments apart from counting that there are at least 3. Perhaps a rest from old checking methods, since this fix is short and rather straight forward, I guess it is not revised that often.
Note that this is not the case for nve_noforce and nve_limit which require exactly 4 arguments. nve/sphere on the other hand makes the same check as plain nve and should maybe be corrected.
The reason for the lack of checking is that there are fix classes that are derived from fix nve that do take arguments. This results in a problem, because the base class constructor is run before it is run for the derived classes, so it is not possible to remove arguments from the list. And from the constructor we don’t have access to virtual functions yet, so adding an options() virtual function is not helping either. You also cannot simply check for just fix “nve” alone since there are accelerated suffixed versions of it.
That said, we added a utility function utils::strip_style_suffix, that can handle the case of a suffix added via the -sf command line flag (it does not help when people put fix nve/kk explicitly in their inputs). So that a check for plain “nve” and then erroring out with extra arguments is possible.
I’m going to try this out in Collected small changes and fixes by akohlmey · Pull Request #4357 · lammps/lammps · GitHub now. If I get it to work, it should cover most cases since few people use explicit suffixes in their inputs.
@wangchao There are a number of problems with your input.
for ReaxFF you need to use a shorter timestep than the default, specifically when your system contains hydrogen atoms and when you are running at a very high temperature
please also check your log file or screen output. There should be a warning about the neighbor list settings being changed due to your settings for fix reaxff/species. averaging over 100 steps is not going to work for anything with a large-ish timestep that is not a solid at the selected temperature. So I would first test without fix reaxff/species, use a shorter timestep and tweak timestep and neighbor list settings so you can get stable dynamics that can conserve energy
the hbondchk warning has multiple causes, one is that you run in parallel with MPI but your distribution of atoms changes a lot over the course of the simulation. The default implementation of ReaxFF assumes that the system is already somewhat equilibrated and thus makes some guess for how many hydrogen bonds might need to be stored during the entire run. The error can happen when this limit is crossed. There are several ways to address this: a) switch to the KOKKOS version of ReaxFF, which is more robust in those cases, b) run without or with fewer MPI processes and use some OPENMP parallelization (can also be applied to KOKKOS, btw), c) break down the run into multiple small chunks where you store intermediate results in data files and the use “clear” and “read_data” to start over with adjusted heuristics for the amount of hydrogen bond storage required.
From remote it is impossible state which of these points impact your simulation or whether all of them in combination are the cause of the error message.
Tracking this down in stages and carefully is essentially your job. As mentioned before, this error has been reported multiple times and more details advice has been given (beyond the one listed by @simongravelle).
Please also let me add that using fix temp/berendsen is a particularly bad choice to heat up a system. Its algorithm is meant for bulk liquids at ambient temperature, but for high temperatures, it will increase the difference between hot and cold atoms, which is the opposite of what you usually want to achieve in these scenarios. I would thus switch to a dissipative thermostat, like one of the many langevin style thermostats supported by LAMMPS. Those will try to homogenize the temperature distribution instead.
Thanks, this explains the format and the way the fix checks if ir is not ^nve/sphere. Makes sense.
It would still be nice to find away to error out that useless arguments are provided to plain nve. I hope your patch can solve this. Else there must be another way.
IMO anyone and everyone should be using the KOKKOS version of ReaxFF. Not only is it more memory robust and will never have these hbondchk errors, it is also faster on CPUs, at least in most cases that I’ve benchmarked, or same speed at the very least.
