Hello Team,
Greetings. I'm new to the LIGGGHTS software and trying to insert particles using the following script. I get an error which says
"ERROR: Fix insert/pack (id vlfrINJ3): overflow in particle number calculation: inserting too many particles in one step (../fix_insert_pack.cpp:345)"
I want to insert same particle(s) using two particle types as I want to track later type during simulation. There are being injected by vlfrINJ3 fix. Upon seeing this error, I reduced volFrac to a very low number but still I get same error? What could be the mistake in this?
Also, I've increased the simulation box domain by three times the actual size to accommodate particles but still the error stops the case from running.
Thank you,
Jagan1Mohan.
--------------------------------------------------------------------------------------------------------------------------------
echo both
log log.liggghts_VolFrac # Name specific file.
thermo_log thermo_VolFrac.txt # Writes thermo_style variables.
units si
atom_style granular
atom_modify map array # sort 1 1
boundary ff ff ff
newton off
communicate single vel yes
processors * * *
# wall: type 1; atom_1: type 2; atom_2: type 3.
variable radPart2 equal 0.000345 # White.
variable rhoPart2 equal 2500.0
variable radPart3 equal 0.000346 # Black.
variable rhoPart3 equal 2500.0
##### ONLY FOR VOLFRAC INJECTION #####
variable volfracPart2 equal 0.115857 # Volume Based Injection.
variable volfracPart3 equal 0.000001 # Volume Based Injection. ## THIS VALUE IS TOO LESS EVEN THOUGH I GET ERROR?
##########
##### SIMULATION BOX #####
#read_restart fileRestartBin.dat
region outerCYL cylinder z +0.0 +0.0 +0.039 -0.001 +0.285 units box side in
region innerCYL cylinder z +0.0 +0.0 +0.024 -0.001 +0.285 units box side out
region mySIMBOX intersect 2 outerCYL innerCYL
create_box 3 mySIMBOX
region outerCYLINJ cylinder z +0.0 +0.0 +0.0375 +0.001 +0.284 units box side in
region innerCYLINJ cylinder z +0.0 +0.0 +0.0255 +0.001 +0.284 units box side out
region myVolFrac intersect 2 outerCYLINJ innerCYLINJ
##########
##### GEOMETRY AS STL FILES #####
fix ZMAX all mesh/surface file tayCou_25_38_95_TOP.stl type 1 scale 1.0
fix ZMIN all mesh/surface file tayCou_25_38_95_BOT.stl type 1 scale 1.0
fix XMAX all mesh/surface file tayCou_25_38_95_OUTER.stl type 1 scale 1.0
fix XMIN all mesh/surface file tayCou_25_38_95_INNER.stl type 1 scale 1.0
##### WALLS BOUNDARY CONDITION #####
fix boxwalls all wall/gran model hertz tangential history mesh n_meshes 3 meshes ZMIN XMAX XMIN
##########
neighbor ${radPart2} bin # 0.003 bin
neigh_modify delay 0 # every 1 check no
##### MATERIAL PROPERTIES #####
fix m1 all property/global youngsModulus peratomtype 5e6 5e6 5e6 # Minimum allowed is 5e6.
fix m2 all property/global poissonsRatio peratomtype 0.25 0.25 0.25
fix m3 all property/global coefficientRestitution peratomtypepair 3 0.06 0.06 0.06 0.06 0.06 0.06 0.06 0.06 0.06 # Minimum allowed is 0.06.
fix m4 all property/global coefficientFriction peratomtypepair 3 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20
##### USED FOR BOTH FACE INJECTION AND VOLFRAC #####
fix partDATA2 all particletemplate/sphere 15485863 atom_type 2 density constant ${rhoPart2} radius constant ${radPart2}
fix partDENS2 all particledistribution/discrete 15485867 1 partDATA2 1.0
fix partDATA3 all particletemplate/sphere 15485863 atom_type 3 density constant ${rhoPart3} radius constant ${radPart3}
fix partDENS3 all particledistribution/discrete 15485867 1 partDATA3 1.0
##########
pair_style gran model hertz tangential history
pair_coeff * *
fix integrate all nve/sphere
fix grav all gravity 9.810 vector 0.0 0.0 -1.0
timestep 0.000001
fix timeStepCheck all check/timestep/gran 1 0.1 0.1 warn yes error yes vmax 10 # v = sqrt(2gH) + init_vel in S.I.
thermo 1
thermo_style custom time atoms ke fmax vol cpu
##### INJECTION VIA VOLFRAC #####
fix vlfrINJ2 all insert/pack seed 49979687 distributiontemplate partDENS2 vel constant 0.0 0.0 -5.0 insert_every once overlapcheck yes all_in yes volumefraction_region ${volfracPart2} region myVolFrac
fix vlfrINJ3 all insert/pack seed 49979687 distributiontemplate partDENS3 vel constant 0.0 0.0 -5.0 insert_every once overlapcheck yes all_in yes volumefraction_region ${volfracPart3} region myVolFrac
##########
dump dumpRES all custom/vtk 1 tayCouVolFrac_*.vtk id type radius x y z vx vy vz fx fy fz omegax omegay omegaz
run 1
unfix vlfrINJ2
unfix vlfrINJ3
--------------------------------------------------------------------------------------------------------------------------------
Riccardo Maione | Mon, 12/16/2019 - 15:23
Hello jagan1mohan,
Hello jagan1mohan,
why don't you use a single particledistribution/discrete in your simulation? I find it strange that it is giving you this error, but this would give you a start...
Best wishes,
Riccardo
jagan1mohan | Mon, 12/16/2019 - 23:19
Hello Riccardo
Hello Riccardo, I'm using 2 different atom types of same material as I want to visualize a particle flow pattern. This would be more clear if particles are bi-colored.
It appears to me as a bug in the code. When I do the same thing for a different geometry it works.
Also, another observation is if I keep the particle radii and densities exactly same, the code does not release second type of particles at all. This is also bit strange.
Perhaps, developer community of DCS has better insight into this.
Thank you,
Jagan Mohan.
Riccardo Maione | Tue, 12/17/2019 - 10:15
you can still use two atom
you can still use two atom types with 1 particle distribution discrete for example with something like this :
fix partDATA2 all particletemplate/sphere 15485863 atom_type 2 density constant ${rhoPart2} radius constant ${radPart2}fix partDATA3 all particletemplate/sphere 15485863 atom_type 3 density constant ${rhoPart3} radius constant ${radPart3}
fix partDENS3 all particledistribution/discrete 15485867 2 partDATA2 0.50 partDATA3 0.50
fix vlfrINJ3 all insert/pack seed 49979687 distributiontemplate partDENS3 vel constant 0.0 0.0 -5.0 insert_every once overlapcheck yes all_in yes volumefraction_region ${volfracPart3} region myVolFrac
still if it works on another geometry maybe there is a problem in how your geometry is defined, i don't think it's a bug.
jagan1mohan | Wed, 12/18/2019 - 07:14
Thank you very much..
Hello Riccardo, Thank you for this new information. I did not know this, would try out and let you know today.
I'm new to LIGGGHTS and learning it. In my volume fraction based initialization, I observe that particles are attracted towards each other as they fall under gravity after initialization. I've attached an image for your reference.
1. How to know what are different forces in play? I think, gravity, contact_normal, contact_tangential are acting but anything else besides these?
2. Can we write additional lines to in.* file to estimate different forces on each particle? Not pair-wise but individual forces on each particle with time like we write velocity components in "dump".
Thank you,
Jagan1Mohan
Riccardo Maione | Wed, 12/18/2019 - 09:38
Hello Jagan,
Hello Jagan,
no problem, happy to help :D. I am sorry but i cannot see the image, anyhow:
1. How to know what are different forces in play? I think, gravity, contact_normal, contact_tangential are acting but anything else besides these?
well from what i see in your script it seems you have only these forces. For what concerns gravity, i don't think it's much of a problem right? however for the contact forces you can use the compute pair/gran/local command (https://www.cfdem.com/media/DEM/docu/compute_pair_gran_local.html?highli...) which will give you every force from pairwise interactions, you can even output force chains informations with this, give it a try
2. Can we write additional lines to in.* file to estimate different forces on each particle? Not pair-wise but individual forces on each particle with time like we write velocity components in "dump".
You already do this with dump custom fx fy fz for every particle.
Regards,
Riccardo
jagan1mohan | Fri, 12/20/2019 - 16:41
Speed up....
Hello Riccardo, I've submitted a simulation with suggestions as outlined on 12/17/2019 post in which I'm using only one particledistribution/discrete command. It is still in progress and all particles haven't yet settled to base of geometry (I periodically check thermo output, VTK files to ensure everything is running okay). The script I'm using is very much same as pasted above with a modification as per your last post.
1. Could we make any other modification by which we can speed this up? I'm using 1E-6 timestep with timestepcheck command in place and almost no loss of particles. Can we try with higher time-step and ensure particles are not lost, particle fill height as close as to experiments and without loss of accuracy? (these are very important as this is a starting file for next much larger simulations).
2. Is there anything such as variable time-step in LIGGGHTS wherein time-step is auto-computed and no loss of accuracy?
Thank you,
Jagan Mohan.