yade-dev team mailing list archive

[Jan Stránský <honzik.stransky@xxxxxxxxx>]

Hello (and sorry for late reply),

in Cpm classes the approach is (if I understand correctly) the same as in
JCFpm, see example code in [1]. At interaction born, all interactions are
set forcesfree by default. I am quite happy with the approach, even thought
you need to run one time step.

cheers
Jan

[1] https://yade-dem.org/doc/user.html#creating-interactions



2015-07-29 23:42 GMT+02:00 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] on behalf
> of Bruno Chareyre [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>
> 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> 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
>>> Post to     : yade-users@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~yade-users
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~yade-dev
>> Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~yade-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-dev
> Post to     : 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
> ________________
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-dev
> Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
>