Incorrect/Extra Mass being generated Insert/Stream command

Submitted by rahulsoni on Wed, 08/03/2016 - 13:25

I have been trying to fill a rotating mill volume by the insert/stream command. The commands looks like something below:
fix ins_balls all insert/stream seed 5330 distributiontemplate pdd_feed_balls maxattempt 1000 mass ${mass_of_balls} massrate ${feed_rate_balls} overlapcheck yes vel constant 0. 0. ${downward_velocity} insertion_face ins_face01 extrude_length 0.5
fix ins_particles all insert/stream seed 3350 distributiontemplate pdd_feed_particles maxattempt 1000 mass ${mass_of_particles} massrate ${feed_rate_particles} overlapcheck yes vel constant 0. 0. ${downward_velocity} insertion_face ins_face02 extrude_length 0.5

where, the calculated values by liggghts based on inout are as below.
mass_of_balls = 10.048 kg, mass_of_particles = 5.0868 kg, feed_rate_balls = 4.0198 kg, feed_rate_particles = 2.0345 kg, downward_velocity = -0.2 m/s

However, the part of output looks something like this:

#setting run
run 1
WARNING: Fix mesh: Mesh contains highly skewed element, moving mesh (if used) will not parallelize well (../surface_mesh_I.h:607)
INFO: Particle insertion ins_balls: 9.192657 particles every 658130 steps - particle rate 3.677067, (mass rate 4.019199e+00)
9 particles (mass 9.837402e+00) within 0 steps
INFO: Particle insertion ins_particles: 696.651189 particles every 658130 steps - particle rate 278.660831, (mass rate 2.034719e+00)
696 particles (mass 5.082037e+00) within 0 steps
Memory usage per processor = 9.22893 Mbytes
Step Atoms KinEng CPU
0 0 -0 0
INFO: Particle insertion ins_balls: inserted 9 particle templates (mass 1.328632e+01) at step 1
- a total of 9 particle templates (mass 1.328632e+01) inserted so far.
INFO: Particle insertion ins_particles: inserted 696 particle templates (mass 8.181179e+00) at step 1
- a total of 696 particle templates (mass 8.181179e+00) inserted so far.
1 705 -0 0.0369699
Loop time of 0.0369873 on 4 procs for 1 steps with 705 atoms

It is clear that the mass of balls supposed to be fed, calculated to be fed and actually feed are 10.048 kg, 9.837402e+00 kg and 1.328632e+01 kg, respectively. Similarly, for particles these values are 5.0868 kg, 5.082037e+00 kg and 8.181179e+00 kg, respectively. Please see the attached pdf file for highlighted values for your convenience.

Thus, the difference between supposed mass to be fed and actually fed are calculated below:
Balls: Mass actually fed - Mass supposed to be fed = 1.328632e+01 kg - 10.048 kg = 3.23832 kg
Particles: Mass actually fed - Mass supposed to be fed = 8.181179e+00 kg - 5.0868 kg = 3.094379 kg

Now, my obvious point is that why LIGGGHTS is feeding significantly extra mass (approx 3 kg which is approx 32% and 60.74%, respectively) in the system, even after it calculated/targeted the right value to be fed.

AttachmentSize
Plain text icon in.txt18.59 KB
Plain text icon log.txt354.73 KB
PDF icon log.mill_.pdf111.28 KB
ckloss's picture

ckloss | Tue, 09/13/2016 - 15:36

Hi rahulsoni,

your script is a bit too complicated to be easily understood and reproduced. In 3.5. we enforce seeds to be large primes and different
Please re-run the simulation in 3.5 and if the issue persists, please post a simple case for debugging.

Thanks and Best wishes!
Christoph

akhilkm | Fri, 01/03/2020 - 17:14

i have been trying to simulate granular shockwave over a cylinder. I try to vary the insertion velocity by keeping the mass flow constant for 3 cases ( 2.4kg/s,4.8kg/s and 7.2 kg/s ) i vary velocity as 0.25m/s,0.5m/s,0.75m/s, 1m/s ,2m/s ... till 8m/s for each cases.

i obtained the volume fraction and velocity of insertion by post analysing the output data ( by meshing the domain ). the mass flow rate must be a property of mainly volume fraction and velocity (for a given density of particle and for unit surface area) hence i tried multiplying volume fraction and velocity at points just after insertion.

so, the product of vol fract and velocity increases as i increase velocity from 0.25m/s to about 1m/s after which it approximately maintains a precise value ( but still not accurate) .

i doubt whether the insertion surface meshing has anything to do with this issue..

expecting your reply

Thank you
Akhil K Mathews
Mtech at IIT Kanpur