Particle packing - How to avoid overlap

Hi Varun,
there was a bug in pack.inSphere predicate. The fix is committed to the git
repository. How did you install yade?
cheers
Jan

2016-04-29 20:21 GMT+02:00 VG <email address hidden>:

> New question #292846 on Yade:
> https://answers.launchpad.net/yade/+question/292846
>
> I am generating a pack of spheres (lets call them aggregates), using
> makeCloud. Each of those spheres consists of a packing of smaller particles
> glued together using cohesive material model. I am using randomDensePack to
> generate this packing of particles within each sphere.
>
> Now, when I visualize the packing, I notice that sometimes there is an
> overlap between the particles of two different aggregates. I want to avoid
> this, since it results in internal stresses in the initial condition. Is
> there a better way to generate this kind of packing ?
>
> Here is the minimal working example script:
>
>
> from yade import pack,qt,plot,utils,export,ymport
> from math import *
>
>
> #############################################################################
> # Set up run
>
> #############################################################################
> run_name="test_aggregates"
> data_root_dir="."
>
>
>
>
>
> #############################################################################
> # Materials
>
> #############################################################################
>
> sample_material=CohFrictMat(
> young=4e9
> ,poisson=0.25
> ,density=1400
> ,frictionAngle=radians(30)
> ,normalCohesion=1e8*1.2
> ,shearCohesion=.4e8*1.2
> ,momentRotationLaw=True
> ,label='sample_mat')
> O.materials.append(sample_material)
>
>
> #############################################################################
> # Component dimensions and operating condition
>
> #############################################################################
> # Sample dimension
> sample_radius=5e-4
> # Sub-particle dimension
> particle_radius=2.5e-4
>
>
> #############################################################################
> # Geometry
>
> #############################################################################
>
>
>
> xExt=4*sample_radius
> yExt=4*sample_radius*2
> zExt=xExt
> xLim=xExt
> yLim=yExt/4
> zLim=zExt
>
>
>
>
> #############################################################################
> # Particle Packing
>
> #############################################################################
>
> min_corner= (0,yLim,0)
> max_corner= (xLim, yExt-yLim, zLim)
>
> sp=pack.SpherePack()
> sp.makeCloud( min_corner,max_corner, rMean=sample_radius, periodic=False)
>
> print "Generated ",len(sp)," aggregates"
>
> ###########################################
> # Sample
> ###########################################
> for s in sp:
> sphere=pack.inSphere((s[0][0],s[0][1],s[0][2]),s[1])
> sp1=pack.randomDensePack(
> sphere
> ,spheresInCell=2000
> ,radius=particle_radius
> ,memoizeDb='/tmp/triaxPackCache.sqlite'
> ,returnSpherePack=True
> )
>
> sp1.toSimulation(material='sample_mat',color=(0.9,0.8,0.6))
> print 'Generated ',len(sp1),' particles'
>
> Gl1_Sphere(stripes=True)
>
>
>
> Thanks
> Varun
>
>
> --
> You received this question notification because your team yade-users is
> an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp
>

Hello Jan,

I installed Yade using the below instructions for pre-built package on website: https://yade-dem.org/doc/installation.html

sudo bash -c 'echo "deb http://www.yade-dem.org/packages/ trusty/" >> /etc/apt/sources.list'
wget -O - http://www.yade-dem.org/packages/yadedev_pub.gpg | sudo apt-key add -
sudo apt-get update
sudo apt-get install yadedaily

Thanks
Varun

In this case, after update of yadedaily, the fix should be there soon
cheers
Jan

2016-05-02 1:27 GMT+02:00 VG <email address hidden>:

> Question #292846 on Yade changed:
> https://answers.launchpad.net/yade/+question/292846
>
> VG posted a new comment:
> Hello Jan,
>
> I installed Yade using the below instructions for pre-built package on
> website: https://yade-dem.org/doc/installation.html
>
> sudo bash -c 'echo "deb http://www.yade-dem.org/packages/ trusty/" >>
> /etc/apt/sources.list'
> wget -O - http://www.yade-dem.org/packages/yadedev_pub.gpg | sudo apt-key
> add -
> sudo apt-get update
> sudo apt-get install yadedaily
>
> Thanks
> Varun
>
> --
> You received this question notification because your team yade-users is
> an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp
>

Yadedaily should be relatively updated.
Last week there were 2 uploads.

Anton

I got the update last week, but it is still showing me the problematic overlap. From what I see, the overlap is usually between the two particles of different aggregates (spheres). Is it related to the bug you mentioned ? Or is there another better way of generating the packing which would avoid such overlap ?

Thanks
Varun

Hi Varun,
your approach is OK. The fix was made on 30th April (now 2 days ago) [1],
so probably the fix is not yet at yadedaily..
Jan

[1]
https://github.com/yade/trunk/commit/f5337c1c444e15e2a8a829f935854c54f4ffb99a

PS: if you have some randoms in your simulation (typically makeCloud), try
to use some kind of seed to make sure your script shows the problem. In my
case, I had to run it several times before seeing the overlaps.. There is
no seed in randomDensePack, but you can use memoizeDb and provide the
database file.

2016-05-02 19:02 GMT+02:00 VG <email address hidden>:

> Question #292846 on Yade changed:
> https://answers.launchpad.net/yade/+question/292846
>
> VG posted a new comment:
> I got the update last week, but it is still showing me the problematic
> overlap. From what I see, the overlap is usually between the two
> particles of different aggregates (spheres). Is it related to the bug
> you mentioned ? Or is there another better way of generating the packing
> which would avoid such overlap ?
>
> Thanks
> Varun
>
> --
> You received this question notification because your team yade-users is
> an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp
>

Hello Jan,

Thanks for your help.
Do you know when yadedaily would be updated again or usually how often is it updated ?

Thanks for your tip about the seed, while using makeCloud. I will certainly use that in future scripts.

Regards
Varun

Thinking about this problem more, this might not actually be a bug. As you outlined, the difference between the previous version and "fixed" version is:
- Previous version: Pack all the smaller spheres within the predicate (bigger sphere), such that the centers of smaller spheres are within the boundary of predicate.
- Fixed version: Only the smaller spheres which are entirely contained within the predicate are considered.

What the fixed version does can also possibly be attained by pack.inSphere((s[0][0],s[0][1],s[0][2]),(s[1]-particle_radius)).
Correct me if I am wrong.

That still doesn't solve the physical problem I am trying to set up. I should give a better description of the problem I am trying to solve, if there is a better set up possible for the problem:

-- I have a granular sample with given input particle size distribution. Under mechanical loading, these particles will break and I want to get the resulting particle size distribution.

-- I am representing the input particle size distribution with spherical particles of diameters D1, D2, D3 etc. All of such big particles are composed of smaller particles of diameter 'd', since d is the smallest particle size of interest.

-- Initially, within each big spherical particle, all the smaller particles should be densely packed and connected with cohesive bonds. As the loading is applied, the initially defined cohesive bonds within each big sphere will break progressively leading to smaller fragments, giving a new particle size distribution.

The major problems I am facing in the current script are:

-- Smaller particles from two different predicates (big spheres) tend to overlap.

-- I am noticing that sometimes cohesive bond gets formed between two smaller particles of different predicates. I would like to avoid this, since I only want non-cohesive contact between the two different big spheres.

-- Initially, within a single big sphere itself, sometimes there are particles which are shown not to have any cohesive interaction, leaving that small single particle free to fly.

Are there workarounds which can alleviate these problems ? Or if there is an alternative and better way to set up this problem ?

Thanks
Varun

Hi Varun,

> VG is still having a problem:
> Thinking about this problem more, this might not actually be a bug. As you
> outlined, the difference between the previous version and "fixed" version
> is:
> - Previous version: Pack all the smaller spheres within the predicate
> (bigger sphere), such that the centers of smaller spheres are within the
> boundary of predicate.
> - Fixed version: Only the smaller spheres which are entirely contained
> within the predicate are considered.
>
> What the fixed version does can also possibly be attained by
> pack.inSphere((s[0][0],s[0][1],s[0][2]),(s[1]-particle_radius)).
> Correct me if I am wrong.

The description of previous and fixed versions is correct

in pack.inSphere, it was a real bug. Of course, you can play with settings
like using s[1] or s[1]-particle_radius, but this is different point.

>
> That still doesn't solve the physical problem I am trying to set up. I
> should give a better description of the problem I am trying to solve, if
> there is a better set up possible for the problem:
>
> -- I have a granular sample with given input particle size distribution.
> Under mechanical loading, these particles will break and I want to get
> the resulting particle size distribution.
>
> -- I am representing the input particle size distribution with spherical
> particles of diameters D1, D2, D3 etc. All of such big particles are
> composed of smaller particles of diameter 'd', since d is the smallest
> particle size of interest.
>
> -- Initially, within each big spherical particle, all the smaller
> particles should be densely packed and connected with cohesive bonds. As
> the loading is applied, the initially defined cohesive bonds within each
> big sphere will break progressively leading to smaller fragments, giving
> a new particle size distribution.
>

thanks for clarifying, but your description was OK before :-) how you want
to create the initial packing is the matter of your preferences.
randomDensePack within a big agregate is a good choice. For the big
aggregates, you can use:
- makeCloud like now
- randomDensePack to get denser packing of bigger aggrgates
- use something like randomDensePack on already "meshed" aggregates, see
Klaus's answer #3 in [1]

>
>
> The major problems I am facing in the current script are:
>
> -- Smaller particles from two different predicates (big spheres) tend to
> overlap.
>

this should not happen with newer version

>
> -- I am noticing that sometimes cohesive bond gets formed between two
> smaller particles of different predicates. I would like to avoid this,
> since I only want non-cohesive contact between the two different big
> spheres.
>
> -- Initially, within a single big sphere itself, sometimes there are
> particles which are shown not to have any cohesive interaction, leaving
> that small single particle free to fly.
>

this is material model dependent. I am not very familiar with CohFrictMat,
so somebody else have to help.

Probably open a new question on this topic, since it is different from the
original problem.

cheers
Jan

[1] https://answers.launchpad.net/yade/+question/292672

Thanks for your response, Jan!
For the generation of big aggregates, one of the procedures you suggested is not very clear to me:

>"- use something like randomDensePack on already "meshed" aggregates, see
 > Klaus's answer #3 in [1]"

This procedure talks about creating clumps of spherical particles. As far as I understand, they behave in a rigid manner and probably I can't have breakable cohesive bonds within a clump. Also, I dint quite get what you mean by already "meshed" aggregates ?

I will post another question about the issue with CohFrictMat.

Hi Varun,
I meant to use clumps only for the stage of defining initial packing for
your actual simulation. The steps I meant are: 1) use makeCloud to create
aggregates
2) use randomDensePack to divide each aggregate into a set of spherical
particles
3) apply some compression to make the packing of aggregates denser

1) and 2) you do already, the rest is just to make the packing overall
denser

cheers
Jan

2016-05-04 20:26 GMT+02:00 VG <email address hidden>:

> Question #292846 on Yade changed:
> https://answers.launchpad.net/yade/+question/292846
>
> VG posted a new comment:
> Thanks for your response, Jan!
> For the generation of big aggregates, one of the procedures you suggested
> is not very clear to me:
>
> >"- use something like randomDensePack on already "meshed" aggregates, see
> > Klaus's answer #3 in [1]"
>
> This procedure talks about creating clumps of spherical particles. As
> far as I understand, they behave in a rigid manner and probably I can't
> have breakable cohesive bonds within a clump. Also, I dint quite get
> what you mean by already "meshed" aggregates ?
>
> I will post another question about the issue with CohFrictMat.
>
> --
> You received this question notification because your team yade-users is
> an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp
>

Okay I see, Thanks Jan!

Also, I got the latest update of yadedaily which has the change you mentioned above. The point you mentioned above:

"in pack.inSphere, it was a real bug. Of course, you can play with settings
 like using s[1] or s[1]-particle_radius, but this is different point."

With the new version of yadedaily, it generates the exact same number of particles in an aggregate, as generated when I used "s[1]-particle_radius" instead of "s[1]" with the previous version of yadedaily.

In my opinion, your fix in the code and the use of "s[1]-particle_radius" while generating randomDensepack are doing the exact same things.

For example, in the above script, using a sample_diameter of 2e-4 and particle diameter of 1e-5, results in 3732 particles within an agglomerate results in a packing ratio of 0.466, whereas the previous version lead to 4372 particles and a packing ratio of 0.55.

Hi Varun,
yes, you are right. The s[1]-particle_radius in old and s[1] in new version
should do the same.
cheers
Jan

2016-05-04 23:07 GMT+02:00 VG <email address hidden>:

> Question #292846 on Yade changed:
> https://answers.launchpad.net/yade/+question/292846
>
> VG posted a new comment:
> Also, I got the latest update of yadedaily which has the change you
> mentioned above. The point you mentioned above:
>
> "in pack.inSphere, it was a real bug. Of course, you can play with settings
> like using s[1] or s[1]-particle_radius, but this is different point."
>
> With the new version of yadedaily, it generates the exact same number of
> particles in an aggregate, as generated when I used
> "s[1]-particle_radius" instead of "s[1]" with the previous version of
> yadedaily.
>
> In my opinion, your fix in the code and the use of
> "s[1]-particle_radius" while generating randomDensepack are doing the
> exact same things.
>
>
> For example, in the above script, using a sample_diameter of 2e-4 and
> particle diameter of 1e-5, results in 3732 particles within an agglomerate
> results in a packing ratio of 0.466, whereas the previous version lead to
> 4372 particles and a packing ratio of 0.55.
>
> --
> You received this question notification because your team yade-users is
> an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp
>