reference about randomDensePack2

Question

Dear Vaclav,

Following your suggestion, I read through the detailed manual, which is really helpful.

I have run a few cases and learned the basic principles of Woo.

For the examples/densepack.py, I wonder if you could point me to the reference you were using to create the random packing. Apologies if I missed the reference in your manual or in the source code. I would like to learn a bit more about how to create the dense pack.

Your kind help is much appreciated.

DEMWoo

Answer 1

Hi, I added some explanation to randomDensePack2 documentation. If you need more or something is not clear, let me know here and I will put it there again. That way, it is preserved for posterity. The source code to look at is woo.pack._randomDensePack2_singleCell. Cheers, v.

Comments

Dear Vaclav,

Many thanks for your answer and updating the documentation. Apologies for my belated response, too.

However, I still have a few questions:

1. The algorithm computes initial (loose) volume from predicate bounding box using approxLoosePoro, and fills periodic cell of that
   size and aspect ratio (or of a part of it, if maxNum would be
   significantly exceeded) with generated particles. Isotropic
   compression (via woo.dem.PeriIsoCompressor) is subsequently applied
   with a predefined material (young 10MPa, no friction) down to 100MPa
   (and stabilization) and then the sample is unloaded to 1MPa and
   stabilized (those values are currently hard-coded). The resulting
   packing is tiled (if smaller than predicate), clipped by the predicate
   and returned as a woo.dem.ShapePack object (geometry only, no material
   data).

All of these are implemented in the randomDensePack2singleCell as pointed out very kindly by you through the following engines.

    S.engines=[    
    woo.dem.InsertionSortCollider([c() for c in woo.system.childClasses(woo.dem.BoundFunctor)]),
    woo.dem.BoxInlet(box=((0,0,0),iniBoxSize),maxMass=-1,maxNum=-1,generator=generator,massRate=0,maxAttempts=5000,materials=[woo.dem.FrictMat(density=1e3,young=1e7,ktDivKn=.5,tanPhi=.1)],shooter=None,mask=1)
]
    S.engines=[woo.dem.PeriIsoCompressor(charLen=generator.minMaxDiam()[0],
                                     stresses=[-1e8,-1e6],maxUnbalanced=goal,doneHook='print("done"); S.stop()',
                                     globalUpdateInt=1,keepProportions=True,label='peri'),
woo.core.PyRunner(100,'print(S.lab.peri.stresses[S.lab.peri.state], S.lab.peri.sigma, S.lab.peri.currUnbalanced)')]+
woo.dem.DemField.minimalEngines(damping=.7)

1. The packing is not completely overlap-free, thus using options like
   woo.dem.Law2L6GeomFrictPhys_IdealElPl.iniEqlb might be useful,
   depending on the stiffness used in the simulation.

Indeed, I found there are many particles overlapping each other through checking the distance between particles. I wonder if this overlapping results from the initial packing process that starts with randomly generated particles (how about this algorithm?) with overlaps in the space.

As you have pointed out, the overlap-free might be achieved through woo.dem.Law2L6GeomFrictPhys_IdealElPl.iniEqlb, I checked that it is used in the ell0.py example

S.engines=[Leapfrog(reset=True),InsertionSortCollider([Bo1_Ellipsoid_Aabb(),Bo1_Capsule_Aabb(),Bo1_Wall_Aabb(),Bo1_Facet_Aabb()],verletDist=.0),ContactLoop([Cg2_Ellipsoid_Ellipsoid_L6Geom(),Cg2_Wall_Ellipsoid_L6Geom(),Cg2_Facet_Ellipsoid_L6Geom()],[Cp2_FrictMat_FrictPhys()],[Law2_L6Geom_FrictPhys_IdealElPl()])]

I would like to use this to replace the original S.engines. I wonder if you would be kind enough to add another version of randomDensePack2singleCell using woo.dem.Law2L6GeomFrictPhys_IdealElPl.iniEqlb.

In addition, I wonder if it is possible to save the intermediate data of the packing process as I would like to use an animation to see the packing dynamic process (Maybe I need to go back to your detailed manual to find this out).

Finally, Many thanks for your help and kindness in advance.

Best D

---

Hi, the overlaps are not initially there (loose packing, simple random placement in space of non-overlapping particles), but compression of rigid shapes (e.g. spheres) in DEM inherently leads to overlaps, which are how DEM represents what would be intuitively some kind of local deformation on the contact.

iniEqlb was meant to avoid explosion or some other effects of those overlaps, but the overlaps will still be there geometrically. randomDensePack(2) was conceived for modeling solids which are composed of spheres (like concrete block in my thesis) and such overlaps did not really matter.

In general, there is no algorithm generating overlap-free arrangements while maintaining high compacity, respecting PSD and other constraints; one has to sacrifice one or another; there are imaginable methods to improve the result (e.g. static equilibrium analysis) but the goal function must be defined clearly.

For looking at the compression itself, use the debug=True parameter to randomDensePack2. In that case, Scene object will be returned and you can see what is goign on.

Hope this helps. v.

---

Dear Vaclav,

Many thanks for your kind reply.

After a more detailed study of the your Thesis, I've got a better picture of the underlying principles of Woo.

As far as the random dense packing of spheres is concerned, the materials of spheres are hard coded in randomDensePack2singleCell (kindly pointed out and documented by you previously) as

materials=[woo.dem.FrictMat(density=1e3,young=1e7,ktDivKn=.5,tanPhi=.1)];

triaxial compression is then carried out through applying a two-staged stress (it seems that the 'down to 100Mpa' should be 'up to 100Mpa' in the doc string of randomDensePack2).

Now my question is that under the initial loose packing generated through the 'InsertionSortCollider' algorithm, to achieve the maximum possible dense packing fraction with minimum number of overlapping particles, what kind of principles I should follow, e.g. change the maximum applied pressure (100Mpa), unloaded pressure (10Mpa) and maxUnbalanced force in terms of the values of the Young's modulues and ktDivKn, tanPhi. On the other hands, I assume that the paramters of dtSafety and damping are appropriate.

I tried different values of applied pressure and unloaded pressure and got different packing fractions. The thing is that the packing fraction under a relatively larger applied stresses is greater than the theoretical maxium value of 0.64 for monodisperesed spheres (This is due to I did not exclude the overlapping volumes). If I decrease the unloaded pressure, the packing fraction will be reduced as well (surely this is a certainty).

Now, I wonder if it is possible to choose input parameters, e.g. the maximum applied pressure (100Mpa), unloaded pressure (10Mpa) and maxUnbalanced force in terms of the values of the Young's modulues and ktDivKn, tanPhi, dtSafety and damping to calibrating the result with certain known behavior of monodispersed COHESIONLESS (I know Woo are interested mainly cohesive materials) and FRICTIONAL particles.

I really appreciate your great help on this.

D

---

Hi, generally it is hard to define "maximum possible dense packing fraction" (with minimum overlaps); only if you can define that mathematically, you might be able to find an algorithm to compute it.

As a rule of thumb, one does load-unload cycle with zero friction (that eases rearrangement), which is what randomDensePack/randomDensePack2 does. The |max| applied pressure (which I usually call minimum, since compression has negative sign as per continuum mechanics conventions; that's also the reason for compressing "down to 100MPa") will likely change very little -- the packing will stop rearranging at some point and uniform strain will just cause corresponding uniform of the whole packing. The final (unloading) pressure may be made closer to zero, but it will be harder for the packing to stabilize, as there will be less contacts. Contacts always mean overlaps, so you have to steer between these two.

Packing is per se a geometric entity and is not related to cohesion or friction. The way to produce the packing may be related, but does not have to be. I am not aware of any explicit mapping between loading/unloading pressures and resulting features of the packing, and I think it does not exist. The packing algorithm is iterative (and not conservative in the sense of path-independence in the state space), so any mapping will likely be also iterative, or at best empirical/statistical. Play with that, but it is really a research you have to do yourself.