I am running ReaxFF and occasionally I get the hbondck error. I have
found in the mailing list that increasing the skin might help with the
problem, so I would like to ask for clarification. I run with
neigh_modify delay 0 every 1 check yes
to be sure I don't miss any interactions. I find that for my setup, I
actually get highest performance with
neighbor 0.0 bin
as opposed to higher skin length values. That means I could also
switch to "check no", above, if I understand the documentation
correctly.
I would like to know if ReaxFF uses the skin length for something
other than neighbor searching (which could influence the above error)
and if it could therefore be important to increase it even though I
don't want it for performance.
If this is not the case, I would like to resolve the error otherwise.
I am confident that the time step is short enough for the given system
and would like to avoid decreasing it (I am using 0.5 fs for water).
Is there something in reaxc_defs.h that I can increase to avoid this
particular problem?
I am running ReaxFF and occasionally I get the hbondck error. I have
found in the mailing list that increasing the skin might help with the
The most helpful way to eliminate this error is by increasing the buffer
for memory allocation, i.e., the safezone and mincap keywords.
problem, so I would like to ask for clarification. I run with
neigh_modify delay 0 every 1 check yes
to be sure I don't miss any interactions. I find that for my setup, I
actually get highest performance with
neighbor 0.0 bin
as opposed to higher skin length values.
Of course if you have zero skin distance you get higher performance. But
re-neighboring every step is an overkill that significantly reduces the
performance - eliminating the performance gain from a zero skin distance.
You should re-neighbor every 10, 50, or 100, with a proper skin distance
(e.g. 1 or 2 angstroms).
That means I could also
switch to "check no", above, if I understand the documentation
correctly.
I would like to know if ReaxFF uses the skin length for something
other than neighbor searching (which could influence the above error)
and if it could therefore be important to increase it even though I
don't want it for performance.
ReaxFF uses the skin distance just like other styles in LAMMPS do.
If this is not the case, I would like to resolve the error otherwise.
I am confident that the time step is short enough for the given system
and would like to avoid decreasing it (I am using 0.5 fs for water).
0.5 fs for water is a huge time step - you might even want to reduce it to
0.1 for water. A sensitivity test will tell you what time step size to use
for water.
I am running ReaxFF and occasionally I get the hbondck error. I have
found in the mailing list that increasing the skin might help with the
The most helpful way to eliminate this error is by increasing the buffer for
memory allocation, i.e., the safezone and mincap keywords.
Thanks, will try that.
problem, so I would like to ask for clarification. I run with
neigh_modify delay 0 every 1 check yes
to be sure I don't miss any interactions. I find that for my setup, I
actually get highest performance with
neighbor 0.0 bin
as opposed to higher skin length values.
Of course if you have zero skin distance you get higher performance. But
re-neighboring every step is an overkill that significantly reduces the
performance - eliminating the performance gain from a zero skin distance.
You should re-neighbor every 10, 50, or 100, with a proper skin distance
(e.g. 1 or 2 angstroms).
My understanding was that with these settings and a skin > 0, it will
perform the check every step, but only regenerate the lists if needed.
Is that not the case? If not, how do I set that up? It is not entirely
clear from the documentation whether "every 1" or "check yes" takes
precedence.
That means I could also
switch to "check no", above, if I understand the documentation
correctly.
I would like to know if ReaxFF uses the skin length for something
other than neighbor searching (which could influence the above error)
and if it could therefore be important to increase it even though I
don't want it for performance.
ReaxFF uses the skin distance just like other styles in LAMMPS do.
OK, good, I just wanted to make sure there are no side effects.
0.5 fs for water is a huge time step - you might even want to reduce it to
0.1 for water. A sensitivity test will tell you what time step size to use
for water.
0.5 fs is actually well established for various flexible water models,
including DFT. Unless you need very accurate NVE or have some other
consideration, there is no need for 0.1 fs.
Of course if you have zero skin distance you get higher performance. But
re-neighboring every step is an overkill that significantly reduces the
performance - eliminating the performance gain from a zero skin distance.
You should re-neighbor every 10, 50, or 100, with a proper skin distance
(e.g. 1 or 2 angstroms).
My understanding was that with these settings and a skin > 0, it will
perform the check every step, but only regenerate the lists if needed.
Is that not the case? If not, how do I set that up? It is not entirely
clear from the documentation whether "every 1" or "check yes" takes
precedence.
[...]
0.5 fs for water is a huge time step - you might even want to reduce it to
0.1 for water. A sensitivity test will tell you what time step size to use
for water.
0.5 fs is actually well established for various flexible water models,
no. that would only work "ok" with using heavy hydrogens. 0.2fs 0.25fs
is a careful choice for DFT *and* flexible classical water potentials.
including DFT. Unless you need very accurate NVE or have some other
consideration, there is no need for 0.1 fs.
please keep in mind, that the charge equilibration needed in ReaxFF
may be more sensitive to convergence issues due to noisy integration
than DFT.
Thank you, that is exactly what I wanted to achieve. I only do "run 1
pre no post no" when running through Python, but should have done the
test you suggest in a separate simulation.
Of course if you have zero skin distance you get higher performance. But
re-neighboring every step is an overkill that significantly reduces the
performance - eliminating the performance gain from a zero skin distance.
You should re-neighbor every 10, 50, or 100, with a proper skin distance
(e.g. 1 or 2 angstroms).
My understanding was that with these settings and a skin > 0, it will
perform the check every step, but only regenerate the lists if needed.
Is that not the case? If not, how do I set that up? It is not entirely
clear from the documentation whether "every 1" or "check yes" takes
precedence.
forgot this one:
these are two different issues and neither has precedence, but they
work in tandem.
the skin distance determines how much safety distance is given when
building neighbor lists.
if you set it to 0.0, there is no safety and you would be forced to do
the neighbor list rebuilds as often as determined through every/delay.
check yes would have no effect. check yes is triggering a neighbor
list rebuild as soon as one atom has moved further than half the skin
from the position of the last neighbor list build.
That was my original understanding, that's why I said that with skin
0.0 I could also have check no. Thank you for confirming. My concern
was that with the way the documentation is worded I was not able to
exclude the possibility that "every 1" takes precedence over a
non-zero skin and "check yes".
OK, let me rephrase that - "commonly used with flexible water models,
including DFT-based BO AIMD". I know that that in itself does not say
anything, of course. But it is a fair point, I will check a bit more
carefully, especially considering the charge equilibration.