on sample generation to model the real granular sand

A tutorial for triaxial tests is found in scripts/triax-tutorial.
The "session 1" material answers your questions.

Maybe this example helps you:

http://bazaar.launchpad.net/~yade-dev/yade/trunk/revision/2960

Thanks, Mr Jakob. I will try it

> -----原始邮件-----
> 发件人: "Christian Jakob" <email address hidden>
> 发送时间: 2011年11月16日 星期三
> 收件人: <email address hidden>
> 抄送:
> 主题: Re: [Question #178830]: on sample generation to model the real granular sand
>
> Your question #178830 on Yade changed:
> https://answers.launchpad.net/yade/+question/178830
>
> Christian Jakob posted a new comment:
> Maybe this example helps you:
>
> http://bazaar.launchpad.net/~yade-dev/yade/trunk/revision/2960
>
> --
> You received this question notification because you asked the question.

Jakob, this is an interesting and well commented script.
However, I'm surprised that you didn't find problems with this procedure.
Changing shape.radius as you do in this script is not supported (we should forbid that by design). rad1 and rad2 are copied inside the interactions when they are created. Here you change body's sizes but it is not reflected in interactions, leading to inconsistencies.

If I understand your script correctly, I'm affraid the procedure you developped was already present in Yade.

I suggest you have a look at the script I'm mentionning above. Performing a steady particles growth is a simple as this:

triax=ThreeDTriaxialEngine(
       ...
 internalCompaction=True, # If true the confining pressure is generated by growing particles
       ...
)

An even simpler way to see what it does is to generate a triaxial test via the yade interface (and clicking the "internalCompaction" option).

Could you please confirm that this feature is what you had in mind? Then we can remove your script, which seems redundant to me (and uses unsupported operations at the moment).

wangxiaolang, let us know if the triaxial tutorial does not solve your question.

On 17 November 2011 11:20, Chareyre <email address hidden>wrote:

> Question #178830 on Yade changed:
> https://answers.launchpad.net/yade/+question/178830
>
> Chareyre posted a new comment:
> Jakob, this is an interesting and well commented script.
> However, I'm surprised that you didn't find problems with this procedure.
> Changing shape.radius as you do in this script is not supported (we should
> forbid that by design). rad1 and rad2 are copied inside the interactions
> when they are created. Here you change body's sizes but it is not reflected
> in interactions, leading to inconsistencies.
>
Bruno is right, but one possible workaround is that the interactions could
be created again (using O.interactions.clear()) after you change the
radius. I think there should be a comment about this somewhere in
documentation (to say that this sort of operations are not supported for
instance).

Chiara

> If I understand your script correctly, I'm affraid the procedure you
> developped was already present in Yade.
>
> I suggest you have a look at the script I'm mentionning above.
> Performing a steady particles growth is a simple as this:
>
> triax=ThreeDTriaxialEngine(
> ...
> internalCompaction=True, # If true the confining pressure is
> generated by growing particles
> ...
> )
>
> An even simpler way to see what it does is to generate a triaxial test
> via the yade interface (and clicking the "internalCompaction" option).
>
> Could you please confirm that this feature is what you had in mind? Then
> we can remove your script, which seems redundant to me (and uses
> unsupported operations at the moment).
>
> wangxiaolang, let us know if the triaxial tutorial does not solve your
> question.
>
> --
> You received this question notification because you are a member of
> yade-users, which 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
>

As I understand wangxiaolang right, he wants to generate a packing
with given psd AND a given porosity. As far as I know, this is not
possible with SpherePack and makeCloud command. The script I sent can
do that.

I am not familiar with triaxial tests and I am not sure what exactly
internalCompaction does, but I think it simply increases particle
sizes to get a defined porosity/compaction. And there is the point: it
changes the psd curve.
So one can either have an exact psd curve with inexact porosity OR an
exact porosity with inexact psd curve (with makeCloud command).

Until now I did not detect any inconsistencies with my method (I also
use it for PFC) and it works well for loose packings (35 - 45
percent). If there occur some problems with fast particles, the user
can decrease iterPeriod of the calm() function.

If a similar script or function already exists in yade, please let me know.

christian.

Zitat von Chareyre <email address hidden>:

> Question #178830 on Yade changed:
> https://answers.launchpad.net/yade/+question/178830
>
> Chareyre posted a new comment:
> Jakob, this is an interesting and well commented script.
> However, I'm surprised that you didn't find problems with this procedure.
> Changing shape.radius as you do in this script is not supported (we
> should forbid that by design). rad1 and rad2 are copied inside the
> interactions when they are created. Here you change body's sizes but
> it is not reflected in interactions, leading to inconsistencies.
>
> If I understand your script correctly, I'm affraid the procedure you
> developped was already present in Yade.
>
> I suggest you have a look at the script I'm mentionning above.
> Performing a steady particles growth is a simple as this:
>
> triax=ThreeDTriaxialEngine(
> ...
> internalCompaction=True, # If true the confining pressure is
> generated by growing particles
> ...
> )
>
> An even simpler way to see what it does is to generate a triaxial test
> via the yade interface (and clicking the "internalCompaction" option).
>
> Could you please confirm that this feature is what you had in mind? Then
> we can remove your script, which seems redundant to me (and uses
> unsupported operations at the moment).
>
> wangxiaolang, let us know if the triaxial tutorial does not solve your
> question.
>
> --
> You received this question notification because you are a member of
> yade-users, which 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
>

Zitat von Chiara Modenese <email address hidden>:

> Question #178830 on Yade changed:
> https://answers.launchpad.net/yade/+question/178830
>
> Status: Open => Answered
>
> Chiara Modenese proposed the following answer:
> On 17 November 2011 11:20, Chareyre
> <email address hidden>wrote:
>
>> Question #178830 on Yade changed:
>> https://answers.launchpad.net/yade/+question/178830
>>
>> Chareyre posted a new comment:
>> Jakob, this is an interesting and well commented script.
>> However, I'm surprised that you didn't find problems with this procedure.
>> Changing shape.radius as you do in this script is not supported (we should
>> forbid that by design). rad1 and rad2 are copied inside the interactions
>> when they are created. Here you change body's sizes but it is not reflected
>> in interactions, leading to inconsistencies.
>>
> Bruno is right, but one possible workaround is that the interactions could
> be created again (using O.interactions.clear()) after you change the
> radius. I think there should be a comment about this somewhere in
> documentation (to say that this sort of operations are not supported for
> instance).

So after every change in radii we have set

O.interactions.clear()

in the script and everything is ok?

If yes, I will change the script and upload again...

thanks chiara.

>
> Chiara
>
>
>> If I understand your script correctly, I'm affraid the procedure you
>> developped was already present in Yade.
>>
>> I suggest you have a look at the script I'm mentionning above.
>> Performing a steady particles growth is a simple as this:
>>
>> triax=ThreeDTriaxialEngine(
>> ...
>> internalCompaction=True, # If true the confining pressure is
>> generated by growing particles
>> ...
>> )
>>
>> An even simpler way to see what it does is to generate a triaxial test
>> via the yade interface (and clicking the "internalCompaction" option).
>>
>> Could you please confirm that this feature is what you had in mind? Then
>> we can remove your script, which seems redundant to me (and uses
>> unsupported operations at the moment).
>>
>> wangxiaolang, let us know if the triaxial tutorial does not solve your
>> question.
>>
>> --
>> You received this question notification because you are a member of
>> yade-users, which 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
>>
>
> --
> You received this question notification because you are a member of
> yade-users, which 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
>

>
> Until now I did not detect any inconsistencies with my method (I also
>
It is not consistence because changing the size of your particles does NOT
do what you think it should. If you change the particle size you expect
that the interactions would account for this change (right?) but this does
not happen automatically in Yade (it is simply not supported).
Chiara

>It is not consistence because changing the size of your particles does NOT
>do what you think it should. If you change the particle size you expect
>that the interactions would account for this change (right?)

right!

But with O.interactions.clear() this should be fixed, right?

"O.interactions.clear()":
It will most probably break everything. As soon as collider stride is used, interactions are not created at each step, then particles will penetrate each other for a random number of steps without interacting. To overcome that you could disable stride. Overall, stride=off and deleting/creating all interactions at each step could well multiply cpu time by 10.

In addition, the history of the contact is lost, i.e. the tangential force is lost, resulting in instabilities and artificial creep.

Concerning the initial problem of wangxiaolang: Yes, increasing sizes is changing psd homotheticaly. If you want to impose not only the dispersion around mean size but also mean size itself, then you have to generate particles smaller than the target size. If you have target porosity and target final size, it is not difficult to derive how smaller they should be initially. I guess you had to solve this problem somehow in your script, since you are also increasing sizes after all?

Another (simpler but not perfect) option is to generate a packing of arbitrary mean size, then take all positions and sizes and scale them appropriately before using them as an initial geometry.

Maybe making the python function "shape.radius=" return a warning the first time it is called could help avoid problems, since it is indeed not obvious that it breaks. I realized that making radius read-only is not an option since it can still be used in many other situations.

I was checking again your script Jakob. It seems there is a small mistake here:

        Vd_classes[ii] = (Vg_borders[ii+1]+Vg_borders[ii])/2.0 #average volumes in every class
        rad_d[ii] = pow(3*Vd_classes[ii]/(4*math.pi),1.0/3.0) #average radii in every class
        num_spheres[ii] = int(round((3*V_classes[ii])/(4*math.pi*rad_d[ii]*rad_d[ii]*rad_d[ii])))

This is assuming that the average of (x^3) is (the average of x)^3, which is not true. It results in a shifted PSD.
If the size interval is very small, the error vanish, else there is an error. OTOH, this effect is accounted for in makecloud() (which also allows per-number distribution in addition to per-volume).

I understand there is no point for you to learn using makeCloud if you want to keep the exact same procedure as in PFC, but it is not a reason to keep your script in Yade's trunk. makecloud() is a one-line command and is more versatile and robust. The same remark holds for particles growth via triax engines, which should be prefered by anybody who don't come with his own predefined algorithm.

Hello wangxiaoliang,

I think we can build a new script for this. I have a file to generate the packing with a given grain size distribution and a target porosity but it was written in C++ (I did not use python at the time of one year ago):

- First,you create a sphere with radius satisfy:

Real SphereGenerator::GenerateRadius(vector<Real>& sieveDimension, vector<Real>& percentPassed)
{

 typedef boost::random::lagged_fibonacci_01<Real, 48, 44497, 21034> lagged_fibonaccitemp;
 static lagged_fibonaccitemp rng;

   static boost::uniform_real<> one_hundred(0.0,100.0);

 static boost::variate_generator<lagged_fibonaccitemp, boost::uniform_real<> > random1(rng, one_hundred);
   Real random=random1();
 //cerr<<random<<" ";
 int i;//,numberOfSieves=11;
 for (i=0;i!=numberOfSieves;++i)
 {
  if ((percentPassed[i]<random) && (percentPassed[i+1]>=random))
  {
   return (sieveDimension[i] + (random - percentPassed[i])*(sieveDimension[i+1]-sieveDimension[i])/(percentPassed[i+1]-percentPassed[i]))/2;///Fu, 2003;
  }
 }
}

- Create spheres using this function until you get your target porosity, calculated by:

Real CommonFunction::Porosity (MetaBody * ncb, Real& height, Real& BoxDimensionX, Real& BoxDimensionZ)
{
//
 Real SphereVolume=0, radius=0;
        shared_ptr<BodyContainer>& bodies = ncb->bodies;
 BodyContainer::iterator bi = bodies->begin();
 BodyContainer::iterator biEnd = bodies->end();

 for( ; bi!=biEnd ; ++bi )
 {

  if((*bi)->isDynamic)
  {
   Sphere* sphere = YADE_CAST<Sphere*>((*bi)->geometricalModel.get());
   radius = sphere->radius;
   SphereVolume += 4.0/3.0*Mathr::PI*radius*radius*radius;
  }

 }
 return (1-SphereVolume/(height*BoxDimensionX*BoxDimensionZ));
}

- You can place your generated spheres using any of the proposed methods that are available in YADE.

Let me know if it can help you.

Cheers,

Viet

Bruno, in reply to #10 & collider. Read the code first before scaring people. The collider will be notified about deleted contacts via InteractionContainer::dirty flag, which will force re-initialization of collisions at the next step.

One more possible solution.
You can delete the particle and then create a new one at the same
position, but with another radii.

PS Just a guess, sorry. I did not dive into the code.

Anton

PS https://www.yade-dem.org/doc/yade.wrapper.html?highlight=interactioncontainer#yade.wrapper.InteractionContainer.clear (there is a word about collider there, though it is more a notice than explanation)

On 17 November 2011 13:45, Chareyre <email address hidden>wrote:

> Question #178830 on Yade changed:
> https://answers.launchpad.net/yade/+question/178830
>
> Chareyre posted a new comment:
> "O.interactions.clear()":
> It will most probably break everything. As soon as collider stride is
> used, interactions are not created at each step, then particles will
> penetrate each other for a random number of steps without interacting. To
> overcome that you could disable stride. Overall, stride=off and
> deleting/creating all interactions at each step could well multiply cpu
> time by 10.
>
> In addition, the history of the contact is lost, i.e. the tangential
> force is lost, resulting in instabilities and artificial creep.
>
Yes, sorry for wrong suggestion. Killing the interactions is not the
solution (although this would not generate any trouble on the collider side
as Vaclav said).
Chiara

>
> Concerning the initial problem of wangxiaolang: Yes, increasing sizes is
> changing psd homotheticaly. If you want to impose not only the
> dispersion around mean size but also mean size itself, then you have to
> generate particles smaller than the target size. If you have target
> porosity and target final size, it is not difficult to derive how
> smaller they should be initially. I guess you had to solve this problem
> somehow in your script, since you are also increasing sizes after all?
>
> Another (simpler but not perfect) option is to generate a packing of
> arbitrary mean size, then take all positions and sizes and scale them
> appropriately before using them as an initial geometry.
>
> --
> You received this question notification because you are a member of
> yade-users, which 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
>

> "O.interactions.clear()":
> It will most probably break everything. As soon as collider stride
> is used, interactions are not created at each step, then particles
> will penetrate each other for a random number of steps without
> interacting. To overcome that you could disable stride. Overall,
> stride=off and deleting/creating all interactions at each step could
> well multiply cpu time by 10.

The creation of all contacts has only to be done once (after
O.interactions.clear). Is there a command like
O.interactions.recreate() ?

>
> In addition, the history of the contact is lost, i.e. the tangential
> force is lost, resulting in instabilities and artificial creep.

Yes, but the script is just for generating the particles (model preparation).
After this step the user can do what ever he wants (e.g. load it into
a triaxial test).

>
> Concerning the initial problem of wangxiaolang: Yes, increasing sizes is
> changing psd homotheticaly. If you want to impose not only the
> dispersion around mean size but also mean size itself, then you have to
> generate particles smaller than the target size. If you have target
> porosity and target final size, it is not difficult to derive how
> smaller they should be initially. I guess you had to solve this problem
> somehow in your script, since you are also increasing sizes after all?

Yes, first the particles are decreased by factor f = 1/(a*b*c*d*e) and
then they are increased by a, then by b, and so on. Finally they have
exactly their target size.
If one knows f in ThreeDTriaxialEngine, then the particles could be
generated smaller before blowing them up. In this case it seems, that
my script makes the same ...
Can I use this engine without modeling any triaxial tests (as
preparation step for my model)?

cheers,

christian

On 17 November 2011 15:25, Christian Jakob <
<email address hidden>> wrote:

> Question #178830 on Yade changed:
> https://answers.launchpad.net/yade/+question/178830
>
> Christian Jakob proposed the following answer:
>
> > "O.interactions.clear()":
> > It will most probably break everything. As soon as collider stride
> > is used, interactions are not created at each step, then particles
> > will penetrate each other for a random number of steps without
> > interacting. To overcome that you could disable stride. Overall,
> > stride=off and deleting/creating all interactions at each step could
> > well multiply cpu time by 10.
>
> The creation of all contacts has only to be done once (after
> O.interactions.clear). Is there a command like
> O.interactions.recreate() ?
>
You should not use this function (O.interactions.clear()) at all in this
case, that is the main concept. As Bruno said, you do not want to loose the
history of shear forces (for instance). The use of this function is not
really an option for you (sorry again for wrong suggestion).
Chiara

>
> >
> > In addition, the history of the contact is lost, i.e. the tangential
> > force is lost, resulting in instabilities and artificial creep.
>
> Yes, but the script is just for generating the particles (model
> preparation).
> After this step the user can do what ever he wants (e.g. load it into
> a triaxial test).
>
> >
> > Concerning the initial problem of wangxiaolang: Yes, increasing sizes is
> > changing psd homotheticaly. If you want to impose not only the
> > dispersion around mean size but also mean size itself, then you have to
> > generate particles smaller than the target size. If you have target
> > porosity and target final size, it is not difficult to derive how
> > smaller they should be initially. I guess you had to solve this problem
> > somehow in your script, since you are also increasing sizes after all?
>
> Yes, first the particles are decreased by factor f = 1/(a*b*c*d*e) and
> then they are increased by a, then by b, and so on. Finally they have
> exactly their target size.
> If one knows f in ThreeDTriaxialEngine, then the particles could be
> generated smaller before blowing them up. In this case it seems, that
> my script makes the same ...
> Can I use this engine without modeling any triaxial tests (as
> preparation step for my model)?
>
> cheers,
>
> christian
>
> --
> You received this question notification because you are a member of
> yade-users, which 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
>

Chrsitian (not Jakob, sorry)

> Is there a command like O.interactions.recreate() ?

After Vaclav's comment, it is not needed.
I agree that you don't mind loosing contact history if you only want to generate an initial geometry. In that case scaling the whole packing after the densification procedure applies, and it is much simpler. But since it is possible to simultaneously fix porosity, PSD, and keep contact history by combining makeCloud and triax engine, why not do it?

>"If one knows f in ThreeDTriaxialEngine, then the particles could be
>generated smaller before blowing them up. In this case it seems, that
>my script makes the same ..."

Absolutely, modulo the problems discussed above. :)

>Can I use this engine without modeling any triaxial tests (as preparation step for my model)?

Yes sure. It is a boundary conditions controller, and triaxial test is only one specific boundary condition. Have a look at the triax tutorial, if you uncomment only the the first section of the script ("applying confining pressure"), it will do just that.
If something is not clear, let me know, I'm sure it can be improved.

The only thing the script does not do is targetting one specific final size of particles, because with frictional contacts no one cares: the stress-strain behaviour will be the same. In order to target some final sizes, it would need only a few additional lines for smartly tuning initial porosity and particles size.

Last thing: facet boxes have known bugs, aabbWalls is used in the tutorial and I recommend that one until we fix the facets bugs.

Vaclav, thank you for instructing comment. I learned something. :)

>If the size interval is very small, the error vanish, else there is an error.
>OTOH, this effect is accounted for in makecloud()
>(which also allows per-number distribution in addition to per-volume).
>
>I understand there is no point for you to learn using makeCloud if you want to keep the exact same procedure as in PFC, but >it is not a reason to keep your script in Yade's trunk. makecloud() is a one-line command and is more versatile and robust. The >same remark holds for particles growth via triax engines, which should be prefered by anybody who don't come with his own >predefined algorithm.

If makeCloud() can do the same, then I agree with you and we should remove my script.

>The only thing the script does not do is targetting one specific final size of particles, because with frictional contacts no >one cares: the stress-strain behaviour will be the same. In order to target some final sizes, it would need only a few >additional lines for smartly tuning initial porosity and particles size.

Well, lets do it :)

I agree with Jakob, makeCloud can either have an exact psd curve with inexact porosity OR an
exact porosity with inexact psd curve. But it is far from the true triaxial test in lab.

I think we need at least some of the features agree with true triaial sample before any loading( isotropic or shearing)

1, psd agreement
2, porosity
3, particle shape ( some, maybe not ok now)

if not, how can u compare your numerical results with experiments, or it is just a mathematical game?

And how can you say your sample is dense or loose?

As I know, tutorial in "session1" can't solve my questions.

Wangxiaoling, Yade is used by many for generating dense and loose packings.
MakeCloud alone is not doing the trick, you need to combine it with a boundaryController (triaxialEngine's), as in the tutorial.
This is the only way to my knowledge to obtain:
1, specific psd
2, porisity
3, no locked-in forces (i.e. not excessive overlaps, not guaranteed in the previous Jakob's script)

If you mean tutorial-1 script is not doing only and exactly what you want at the moment, I have to agree, but you are free to enhance it in the way that suits your need. The only thing missing there is a loop after the initial growth, reducing friction until a desired porosity is found. You can of course also use Jakob's script, if you think it does what you want.

Chareyre, I have read your comments several times, do you mean the sample after istropic compressed is the initial state?

If so, I don't know how to generate my sample equal or close to the true sample in experiment.

Take one triaxial test for example, if the sand has an initial porosity 0.36, the we need to do consolidation-triaxial shear test.

How can we generate a sample of porosity 0.36 before any load for test in yade with makecloud?

thanks

If you are working with soil sample, the pre-consolidation pressure should exist, right? In that case, compression may be a good choice to generate your sample.

If you don't think so, I can only know three ways:

- After the compression finishes in makecloud, allow the sample to stabilize after removing all external pressures acting on it. Save the positions and radius of all particles only to a file then load the file to have a new sample. By this, your new sample is the same as the previous one but has no interactions between particles (or hope so).
- Don't use compression method, use gravity itself to pack your sample. You will have to modify the code and YADE is an open source code, so this is great.
- There are many other packing methods available, you can define yourself what you like.

Good luck.

> - Don't use compression method, use gravity itself to pack your sample. You will have to modify the code and YADE is an open source code, so this is great.

For this purpose there is in Yade a special engine called "SpheresFactory".
It generates the flow of particles with a predefined PSD.

Anton

>do you mean the sample after istropic compressed is the initial state?

If you are calling isotropic compression the phase where we grow particles, yes, it is what I meant.

>How can we generate a sample of porosity 0.36 before any load for test in yade with makecloud?

How to prescribe porosity and psd without any load is an open question I think. If this is what you have in mind, you should try and imagine a new sort of algorithm (although maybe K. Bagi proposed something that was almost doing that, not sure). There is for sure no script or magic button to do that in Yade.

Saving /loading as suggested by tranviet will erase the interactions, but it is a bit artificial since they will all be back after iteration 1.