Sorry, I don't see how this could happen. The code in atom.cpp
simply computes nbin = boxsize/binsize in each dimension and multiplies
them to see if the total # of bins (on a processor) exceeds an integer
count (2 billion).
The default bin size is 1/2 the neighbor cutoff. So you should have 20
bins or so in each dim. I think you'll need to put some debugging
print statements in atom::setup_sort_bins() and see why it is flagging
an error.
Steve
I changed the value of neighbor 0.5 nsq to 2.0 and it run much longer than it used to . From 200.000 to 1.000.000 timesteps.But it happened again at some point around 1.100.000. If i change again from 2.0 to 3.0 would this cause any problem?
I changed the value of neighbor 0.5 nsq to 2.0 and it run much longer than it used to . From 200.000 to 1.000.000 timesteps.But it happened again at some point around 1.100.000. If i change again from 2.0 to 3.0 would this cause any problem?
try reducing the size of your time step. i suspect that you have two
atoms smashing into each other at too high velocity and that would
lead to an overflow of your forces and then all your numbers go
NaN and that will throw off comparisons like the one that gives
you this error messages.
one - not quite physically correct but probably acceptable -
way around this might be to use something like nve/limit
(or writing something similar for nvt, or a general "fix limit")
that will curb the occasional overflow and keep your simulation
going. i am currently considering to implement the latter as
a helpful tool for interactive MD simulations, where 100%
correct physics is a minor concern compared to high throughput
and avoiding crashes through extreme high forces and velocities.
due to the interactive manipulations (which may be unphysical).
cheers,
axel.
Why are you doing Nsq neighboring? It should be very slow for
any reasonable sized system. What is your force cutoff? The neigh
cutoff is force + skin (0.5 in your case). Again, these values should
give you no problem with atom sorting. I imagine, as Axel said, you
have something else fundamentally wrong with your system and
atom sorting is just a red herring.
Steve
I changed it because befiore i had bin and i was getting another error ,and lammps manual was suggesting to change it to nsq. Two molecules may be close at my initial state but i minimize my system first and then i start my simulation.
dimension 3
boundary p p p
units real
atom_style molecular
neighbor 3.0 nsq
neigh_modify delay 5 every 1
# Data file
read_data BUND-SWNT-CO2.dat
# Type 1: CO2 atoms
# Type 2: Carbon atoms
group CO2 type 1
group tubes type 2
pair_style lj/cut 10.0
pair_coeff 1 1 0.468781 3.454 10.0 #CO2-CO2 epsilon(kcal/mol) sigma(A)
pair_coeff 2 2 0.0 3.0 0.0 #C*-C*
pair_coeff 1 2 0.557 3.40 10.0 # CO2-C*
# the tubes are frozen
fix 1 tubes rigid single
fix 3 tubes setforce 0.0 0.0 0.0
velocity CO2 create 300 8745350 loop geom
minimize 1.0e-06 1.0e-8 10000 100000
write_restart co2min-Rav-swnt.restart
I tried to reduce the timestep from 1.0 to 0.5 but the same thing happened.. I have already use fix nve/limit with thrmostat and barostat. Should i reduce it more ? any other suggestions?
Dimitris
There must be something else fundamentally wrong with your simulation
if you can't use neighbor
bins (or atom sorting bins). One possible problem is that you are
using fix rigid
and also npt which will rescale the CNT positions. I would not use
fix rigid, just
don't integrate the CNT, and use the dilate partial keyword with npt
or berendsen.
You should be able to run this system with NVE which is what I would do first
to verify it is well equilibrated and that you can run with both
neighbor and atom sorting
bins and that your thermodynamics is well behaved.
Steve