yade-dev team mailing list archive

[Jerome Duriez <Jerome.Duriez@xxxxxxxxxxx>]

Ok, one happy end of this discussion is that we agree that more lines than a single "unp = penetrationDepth" are required to build a stress free initial bond network. And in fact I think we finally agree on all points, since I understand/share your preferences for python scripting with respect to C++, even though I do not seek as much you do replacing C++ lines with python ones.

I add just some precisions about this particular example. First, regarding this hypothesis:
"- should the interaction network be based on a constant multiplier applied to all sphere radius?"

It is exactly what JCFpm users currently do ! Taking advantage of Bo1_Sphere_Aabb.aabbEnlargeFactor and Ig2_Sphere_Sphere_ScGeom.interactionDetectionFactor and using one initial time step to construct the initial bond network. According to Jan's answer #1 of the Launchpad question, it seems other cohesive-law users do exactly the same.
Then, regarding your suggestion:
"for p in bodyPairs: #user defined list, the collider should provide help, not a big deal to implement if not yet available
    i=createInteraction(p.id1,p.id2)"
I think the manual definition of such "bodyPairs" on the python-side is up to now far from the Yade-usage of lot of users / devs... (though I do not say it is a reason to keep the current situation)


Second, regarding damage, I just mentionned "damage measurements parameters" which are just broken bonds numbers. Nothing that enters in the constitutive law itself (in case you understood this)..


I agree it makes sense to at least discuss a possible removal of JCFpm law. But probably, this would require another communication channel, more efficient than emails, to discuss the ideas about the specific IGeom, IPhys, Ig2 and Ip2 functors. And, first of all, someone willing to implement it.
As for me, I do not work anymore with this law, and my first contribution to a Law2 extermination in Yade would be Law2_ScGeom6D_NormalInelasticityPhys_NormalInelasticity which I wrote myself -- contrary to JCFpm law -- and which is probably, unfortunately, much less useful than JCFpm. I swear to do this in the first year I get a permanent position....


Jerome



________________________________
From: Yade-dev [yade-dev-bounces+jerome.duriez=ucalgary.ca@xxxxxxxxxxxxxxxxxxx] on behalf of Bruno Chareyre [bruno.chareyre@xxxxxxxxxxxxxxx]
Sent: July 29, 2015 2:24 PM
To: yade-dev@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Yade-dev] [Yade-users] [Question #269724]: What are particular features of CpmMat model?

On 29/07/15 17:49, Jerome Duriez wrote:

    * constructing by hand all the interactions of the initial bond network (that's what you mean when you say that time integration is not needed to detect interactions, I guess ?)
Yes.
    * computing by hand the corresponding penetrationDepth
    * applying unp = penetrationDepth
I'm not saying it is difficult / impossible, but hopefully we will agree that such kind of things do not usually enter script definitions (or at least make script definitions more complex). Whereas a classical step execution does it like a charm. What do you think ?
On a different problem and a few years back I was thinking more or less as you think now: "I need to simulate isotropic compression + deviatoric loading, so let a c++ code do all that: generate the particles, compress isotropicaly, decide when to switch to triaxial, output results to text files". A single c++ class (the triaxial preprocessor you can still find in the GUI) would do all this by just clicking play button.
At that time there was no functional scripting langage. Now that we have one, I find it much more convenient to  write all the above steps one by one in a script (and I deprecated TriaxialCompressionEngine). You may think it is a pain for me, I have to do every step "by hand" (50+ lines) while I could just click and play.
Well, it is simply much more flexible.

The situation is very similar in this initial bond network problem. You support having everything planned in advance in some c++ code (so everything is decided by clicking the play button or writing O.step()).  I claim it should be left to the user, be it at the price of more scripting, and in any case it does not justify writing additional Material/Ig2/Ip2/Law2 families just for this.

If you think to it:
- should the interaction network be based on a constant multiplier applied to all sphere radius?
- should it be based on a fixed distance regardless of individual sphere sizes instead?
- or even should it get the next closest sphere recursively until a fixed number of N bonds are created for each sphere?
You can imagine plenty variants of this sort, all equally acceptable, but the current O.step() method will not allow that. It would need tedious implementation, many flags in Ip2/Ig2/Law, horrible documentation, and still it would never cover all possible wishes.

So, like for the triaxial case. Let's forget that and let's write scripts. Is it really difficult? Besides setting dt=0 for one step, this is an option:

#Before any timestep:
for p in bodyPairs: #user defined list, the collider should provide help, not a big deal to implement if not yet available
    i=createInteraction(p.id1,p.id2)
    i.unp=i.geom.penetrationDepth

Difficult?


- for the joint-contact handling: in fact the Law2 currently takes care of modifying the normal [1] and computing a consistent relative normal displacement (a projection of the classical "penetrationDepth") [2]. It also updates damage measurements parameters in IPhys, and outputs a text file when required (if I do not forget something else).
Ok, if there is a damage model it can be a valid reason. You tell it only now? ;)
I was mainly reacting to the idea that creating bond networks needs a special law (because I've seen that a lot in the past).
Outputing text file: not really something that needs to be writen in c++.

Thinking about it, I fully agree that [1] and [2] would better fit in a new Ig2... But we would then get a new IGeom (or change the meaning of ScGeom attributes ?), in addition to the JCFpm IPhys. And Law2_ScGeom6D_CohFrictPhys_CohesionMoment does not apply... What could be the solution ?
There can be a new Ig2 functor without a new interaction geometry, since the user decide which functors are used. If there was not the damage part it would boil down to tricking the normal and relative displacement in a specific Ig2, then CohesionMoment could be used I think.

Cheers

Bruno



________________________________
From: Yade-dev [yade-dev-bounces+jerome.duriez=ucalgary.ca@xxxxxxxxxxxxxxxxxxx<mailto:yade-dev-bounces+jerome.duriez=ucalgary.ca@xxxxxxxxxxxxxxxxxxx>] on behalf of Bruno Chareyre [bruno.chareyre@xxxxxxxxxxxxxxx<mailto:bruno.chareyre@xxxxxxxxxxxxxxx>]
Sent: July 28, 2015 8:25 PM
To: Yade developers
Subject: Re: [Yade-dev] [Yade-users] [Question #269724]: What are particular features of CpmMat model?

Second thoughts:
Now I understand [1] a bit more but actually it solves a problem created ex-nihilo.
There should not be any O.step() between appending bodies and setting unp=un, since obviously there is no reason to time-integrate before the initial conditions are completely defined.
In this example time integration is used as a trick to detect interactions if I understand correctly. The trick is not needed, but I understand the idea. If you really want to do that you can just step with O.dt=0. I would not recommend it though, since it is less flexible than defining initial state completely in python script.
Bruno

[1] https://answers.launchpad.net/yade/+question/266828<https://answers.launchpad.net/yade/+question/266828>, #4 especially

On 29 July 2015 at 03:51, Bruno Chareyre <bruno.chareyre@xxxxxxxxxxxxxxx<mailto:bruno.chareyre@xxxxxxxxxxxxxxx>> wrote:
Hi Jérôme,
I don't see what you mean, sorry.
Setting unp=un is explicitely making current state the equilibrium state, without the need of any additional "trick", else please explain why you think it is not enough.
Handling modified normals (second specific feature) is the job of Ig2 functor, not Law functor.
So overall I think the law you mention is really redundant.

Let me know what you think about this. We should reach consensus about such things, else users are all confused by different replies.
Thanks

Bruno


On 28 July 2015 at 21:36, Jérôme Duriez <question269724@xxxxxxxxxxxxxxxxxxxxx<mailto:question269724@xxxxxxxxxxxxxxxxxxxxx>> wrote:
Question #269724 on Yade changed:
https://answers.launchpad.net/yade/+question/269724

Jérôme Duriez posted a new comment:
Yes Bruno, I know this "trick" too, which may require one or two more
lines than the one you quote (see
https://answers.launchpad.net/yade/+question/266828, #4 especially).

Yade suffers probably from having too many laws, but as for
Law2_ScGeom_JCFpmPhys_JointedCohesiveFrictionalPM, I do not think this
not so interesting discussion may conclude it is not justified, since I
mentioned earlier a second specific feature about the discontinuity
contacts.....

--
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<https://launchpad.net/%7Eyade-users>
Post to     : yade-users@xxxxxxxxxxxxxxxxxxx<mailto:yade-users@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~yade-users<https://launchpad.net/%7Eyade-users>
More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~yade-dev<https://launchpad.net/%7Eyade-dev>
Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx<mailto:yade-dev@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~yade-dev<https://launchpad.net/%7Eyade-dev>
More help   : https://help.launchpad.net/ListHelp





_______________________________________________
Mailing list: https://launchpad.net/~yade-dev
Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx<mailto:yade-dev@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp




--
_______________
Bruno Chareyre
Associate Professor
ENSE³ - Grenoble INP
Lab. 3SR
BP 53
38041 Grenoble cedex 9
Tél : +33 4 56 52 86 21
Fax : +33 4 76 82 70 43
________________