Maximum nr of timesteps

Submitted by benjaminoberholzer on Sat, 06/01/2013 - 11:26

Is there a limit to the amount of timesteps that a simulation can be run? Is it possible to run simulations up to, say, 100 billion timesteps?

benjaminoberholzer | Sun, 06/02/2013 - 11:30

Just an update on my progress:

I have tried running several different simulations for 10 billion timesteps, but each of them stops without any warning or error message at 2.14 billion timesteps. At first it did not want to run at all, but I inserted the 'every' keyword on the 'run' command and printed a line every 10 million timesteps, which seemed to get it running

My code is given below for reference. Basically, I am pouring a stream of grains between two frictionless vertical planes spaced closed together. I want the particles to form a pyramid at the bottom of the box so that I can measure the angle of friction.

variable Natom equal 2000 #number of atoms in the simulation

dimension 3
atom_style granular
atom_modify map array
boundary f f f

newton off
communicate single vel yes
units si
timestep 1e-10 #need to link it to sqrt(k/m)

region reg block -1 1 -0.025 0.025 -1 1 units box
create_box 2 reg

neighbor 0.001 bin #for creation of new neighbour pairs - here 1mm
neigh_modify delay 0

pair_style gran/hertz/history 0 0
pair_coeff * *

fix grav all gravity 9.81 vector 0 0 -1
fix zwalls all wall/gran/hertz/history 0 0 zplane -1 NULL 1
fix ywalls all wall/gran/hertz/history 0 0 yplane -0.025 0.025 2

fix vdamp all viscous 0.7
fix integr all nve/sphere #apply nve integration to all particles

region slab block -0.025 0.025 -0.025 0.025 -0.1 0.3 units box
fix insertatoms all pour ${Natom} 1 25017 diam uniform 0.025 0.025 dens uniform 2650 2650 region slab vol 0.15 100

fix Youngs all property/global youngsModulus peratomtype 15000000000 15000000000
fix Poissons all property/global poissonsRatio peratomtype 0.17 0.17
fix restitution all property/global coefficientRestitution peratomtypepair 2 0.00001 0.00001 0.00001 0.00001
fix cohesion all property/global cohesionEnergyDensity peratomtypepair 2 0 0 0 0
fix friction all property/global coefficientRollingFriction peratomtypepair 2 0 0 0 0
fix friction2 all property/global coefficientFriction peratomtypepair 2 0.58 0 0 0

compute 1 all ke
compute 2 all erotate/sphere
thermo_style custom step atoms c_1 c_2
thermo 20000 # every Nsteps
thermo_modify lost ignore norm no
compute_modify thermo_temp dynamic yes

dump 1 all atom 10000000 friction0_58_nofrictionwalls.dump

run 10000000000 every 10000000 "print 'Hello'"

richti83's picture

richti83 | Sun, 06/02/2013 - 15:20

Hi
I never tried this, but 2.14 sounds to me like end of integer ( 2^31 -1 )
http://en.wikipedia.org/wiki/Integer_%28computer_science%29

You could make a loop arround the run command:
label loop
variable i loop 1000
run 1000000
next i
jump in.lmp loop
to overcome this.

Btw: your wall command indicates to me that you are using an old version (1.x.x).

I'm not an associate of DCS GmbH and not a core developer of LIGGGHTS®
but I have 7 years user experience using LIGGGHTS®, ParaView and LINUX

ckloss's picture

ckloss | Mon, 06/03/2013 - 14:02

Hi benjamin,

this 2 billion time-step limit has been dropped in LIGGGHTS 2.X

Cheers
Christoph

sbateman | Mon, 06/03/2013 - 17:36

Also, do you really need a timestep as small as 1e-10 seconds for grains which are 25 mm diameter and a Young's modulus of 15 GPa? Take a look at the documentation for fix check/timestep/gran for some idea of how to determine a good timestep to use.

tdl | Fri, 09/27/2013 - 17:11

Dear All,
I have had the same problem recently, too.
I am simulating a granular system interacting with a vibrated mesh bucket.
My run ends logging the following two lines:

2147480000 40000 0.015651161 0 0.41125712 0.00010684208 -0.032010548 -0.014692901 -0.0072795397 -0.00010645653 0.00014890463 2.2602284e-06 -0.15187425 0.15517072
ERROR: Mesh elements have been lost (multi_node_mesh_parallel_I.h:610)

The first line is the output of a fix print I use to dump statistics. The first column is the current timestep.
The second line is the last output found in the log file.

My script has this structure:

(...) stuff to define the simulation (...)
run 1 # so that the first dump is not empty
(...) definition of dumps and fix print (...)
run 2000000000 upto
run 2000000000

As you can see, the simulation ends after timestep 2147480000 so this is definitely the same problem.

I am running liggghts version 2.3.2 compiled a few months ago (no other issues to report).
Probably I am doing something wrong, can you help me?

Thanks,
Alessandro

ckloss's picture

ckloss | Thu, 10/03/2013 - 16:29

That's because the range of INT variables ends here. This will hopefully be solved in the next major release 3.X

Cheers
Christoph

tdl | Mon, 10/07/2013 - 12:01

As always thanks for your reply :-)
I had assumed that this was already solved and I was doing something wrong.
I worked around that for the time being.
Thank you,
Alessandro