I’ve been trying to simulate the behavior of urea molecules for several weeks. The material parameters are based on literature (Özpınar et. al., An improved generalized AMBER force field (GAFF) for urea, Journal of Molecular Modeling, 2010). I wanted to try two states: some amorphous phase with random placed and oriented molecules and some crystalline state. While it is possible to let the lammps script run with the amorphous phase, it fails using the crystalline one.
Strange thing is, that there is no error message at all. The screen-file’s size is 0 byte and the log-file simply ends at the run-command.
Does anyone have an idea what to try to find the problem?
I’ve attached two folders containing a small example with the crystalline phase (test16a) resp. the amorphous phase (test16b). The lammps script is equal in both cases.
When I run your test16a, I get an error message. I imagine you
do too, you just may be running under some batch system or something
that hides where it is:
WARNING: No fixes defined, atoms won't move (verlet.cpp:52)
Setting up run ...
ERROR on proc 0: Neighbor list overflow, boost neigh_modify one or
page (neigh_half_bin.cpp:231)
The doc pages tell you what this error means and how to fix it. It
usually means
you have a very odd system, so I would check that you are not doing
something crazy.
Also the warning is important if you expect to actually run dynamics.
When I run your test16a, I get an error message. I imagine you
do too, you just may be running under some batch system or something
that hides where it is:
WARNING: No fixes defined, atoms won't move (verlet.cpp:52)
Setting up run ...
ERROR on proc 0: Neighbor list overflow, boost neigh_modify one or
page (neigh_half_bin.cpp:231)
The doc pages tell you what this error means and how to fix it. It
usually means
you have a very odd system, so I would check that you are not doing
something crazy.
the problem is the coulomb cutoff.
the system is only about 11x11x9.5 angstrom
in size, but you select a coulomb cutoff of 20 angstrom.
LAMMPS doesn't like that.
for this small a system, you can just run a kspace style instead.
I already noticed that the large cutoff might cause problems. My problem was that the error message didn't appear on the batch system I use so I had no idea where to search the error. So I will change the neigh_modify soon as possible and possibly also decrease the cut off to speed up. Of course I will check the potential before in order to avoid big errors in the calculation.
So thanks to both of you for your help and have a nice weekend!
Michael