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?
A project by DCS Computing and CFDEMresearch
This website uses cookies to ensure you get the best experience on our website. By continuing to browse the site you are agreeing to our use of cookies. This website uses cookies. By continuing to browse the site you are agreeing to our use of cookies. More info
benjaminoberholzer | Sun, 06/02/2013 - 11:30
Just an update on my progress
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 | Sun, 06/02/2013 - 15:20
Hi
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).
ckloss | Mon, 06/03/2013 - 14:02
Hi benjamin,
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
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,
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 | Thu, 10/03/2013 - 16:29
That's because the range of
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
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