Hallo to everybody,
right now I'm trying to verify experimental results of a so called "uniaxial compression test". In this test, a present pebble bed is compressed by a slowly moving wall until reaching a specific strain rate (1,25 % in this case). While compressing, the effective force on the wall is measured.
These results have already been verified using another DEM-Software.
Now I'm trying to verify these results using LIGGGHTS. My results highly deviate (about factor 300) from the existing verified ones, though.
I'm using (mostly) the same parameters and properties which are used in the simulation with the other DEM-SOftware, like:
- geometrical size
- number of particles
- density
- particle diameter
- youngsmodulus
- poissonsRatio
- coefficientRestitution
- coefficientFriction
Are there any other parameters or properties which I didn't adjust yet and which might have an effect on my results?
Kind regards,
Philipp
ckloss | Sat, 06/16/2012 - 11:16
Hi Philipp, how do you
Hi Philipp,
how do you control strain in your LIGGGHTS simulation? I think that is a crucial point
Cheers, Christoph
knoe_ph | Mon, 06/18/2012 - 11:23
Hi Christoph,I control the
Hi Christoph,
I control the strain rate by moving my topwall, which is at the position of the particle with the highest z-coordinate (z0). If the z-coordinate of the highest particle reaches a certain value (z0-0.0125*z0 where 0.0125 is the 1.25% strain to be achieved and z0 the initial height of the top particle), the fix_move command will be unfixed.
I also changed my youngsModulus during simulation which I'm not quite sure if it worked at all. I had to start my Simulation with a lower YoungsModulus (90.e7), elsewise I wasn't able to reach a specific packing factor. After reaching this packingfactor I increased slowly the youngsmodulus to 90.e9 by using this code:
fix m1 all property/global youngsModulus peratomtype 90.e7 90.e7
.
.
.
->Packingfactor achieved
unfix m1
variable a loop 10
label loop
variable b equal $a*90.e7*10
print current YoungsModulus = ${b}
fix m1 all property/global youngsModulus peratomtype ${b} ${b}
run 100
unfix m1
next a
jump in.${NAME} loop
fix m1 all property/global youngsModulus peratomtype 90.e9 90.e9
I'm not sure if the Youngsmodulus was changed internally or if LIGGGHTS continues simulating with youngsmodulus=90.e7 (which would explain my wrong results)
--------------------------------------------------------------------------------------------------------------
For the compressing part, my input script looks like this:
variable z_dehn equal "v_z0 - 0.0125 * v_z0"
fix press all move/mesh/gran linear 0 0 -0.01 units box deckel 1
fix out all print 100 "$t,${f_deckel_z},${hoehe_abs},${Packingfactor}" append post_${NAME}/dump/verdichten.csv screen no title "t,f_deckel_z,hoehe_abs,Packungsdichte"
label compress
undump I_stl
undump dmp
variable dump equal 1000
thermo ${dump}
dump I_stl all mesh/gran/VTK ${dump} post_${NAME}/dump/Zylinder-*.vtk stress stresscomponents
dump dmp all custom ${dump} post_${NAME}/dump/settle.* id type type x y z ix iy iz vx vy vz fx fy fz omegax omegay omegaz radius
variable zmax equal bound(all,zmax)
variable f_zylinder_z equal f_zylinder[3]
variable f_deckel_z equal f_deckel[3]
variable hoehe_abs equal "v_zmax"
run 100
variable z_max_radius equal "v_zmax + v_Partikelradius"
if ${z_max_radius} > ${z_dehn} then "jump in.${NAME} compress"
unfix press
ckloss | Mon, 06/18/2012 - 19:27
Well, the script is a bit too
Well, the script is a bit too complicated to "debug" at a glance... but I think the key thing might be the volumefraction... you said with your "real" Youngs modulus you did not reach the desired packing fraction... Do you have an idea why? what packing fraction do you want to achieve?
Christoph
knoe_ph | Tue, 06/19/2012 - 09:41
Hi Christoph,my desired
Hi Christoph,
my desired packing factor would be 60% (in fact it would be about 63%, but im not even close to reach this value, 60% seems to be the maximum which can be achieved, and only after alot of wiggling runs).
With the "real" youngsmodulus, i am stuck at around 58 % any more wiggling doesnt have anymore effect on the packingfactor.
Using the lowered youngsmodulus I am able to achieve the 60% mark, not sure why though. I was thinking it may have something to do with the computed forces on the particles and their influence on neighboring particles.
By the way I am calculating my packing factor by using the formula ((volume of all particles summed up) / (ground area * (z_coordinate of highest particle + particle radius))). Is there any better or more accurate way to calculate it?
What do you mean by saying the key thing might be the volumefraction?
Kind regards,
Philipp
cstoltz | Tue, 06/19/2012 - 19:25
Philipp, Regarding the
Philipp,
Regarding the calculation of volume fraction, I would calculate it based on some subdomain within the main body of the particles so as to eliminate wall and surface effects. If your system size is large enough, these will be negligible, but otherwise could lower the volume fraction somewhat.
Regarding the particle fraction vs Young's modulus observation, did you change the time step in accord with a change in modulus? I'm wondering if the time step in the high modulus case is too large and allowing the particles to effectively vibrate without properly settling.
Best regards,
Chris
knoe_ph | Wed, 06/20/2012 - 09:40
Hallo Chris, I had the same
Hallo Chris,
I had the same idea and defined a region within the main body, then calculated the packing factor of this region. As result I got clearly higher packingfactors (around 65 %) compared to the original result. Still not sure if this is the most accurate way though.
When changing my YoungsModulus I did also change the timestep accordingly (otherwise it came to warnings and error messages as I recall).
Kind regards,
Philipp
ckloss_ | Sat, 06/23/2012 - 17:53
That's a good point - when
That's a good point - when you evaluate volume fraction in some center region and pack so to reach 63% (instead of the 65), do you reach a better agreement then?
Might be that the erroneous results stem from the fact that the particles were 'overpacked'...
Christoph