yade-dev team mailing list archive

[Bruno Chareyre <bruno.chareyre@xxxxxxxxxxxxxxx>]

 >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 !

I know, that's why it was my first item. My point was that it is presently
hardcoded in this way. No way to change it while other definitions would
not make less sense.

>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)

It is not far really, this is a theoretical method without a step() :
InsertionSortCollider().__call__()
bodyPairs=O.interactions

with the only problem that for the moment it would hide virtual
interactions (hence doesn't work practicaly). Easy to fix.

>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)..

Well, there seem to be a dilatancy thing in the code which I interpreted as
a damage model. Nevermind.

>I agree it makes sense to at least discuss a possible removal of JCFpm law.

I never suggested to remove it or even to change it, but please don't
mention this kind of thing in yade-users when it is off topic. Let's keep
answers simple and to the point.
Also I would like to make sure that nobody will write yet another law just
because he wants remote interactions, bonds, or however they are called.

As you say, the fact that current practice is how it is does not mean that
it must remain.
We should definitely advise new users to define remote interactions in
their own way when we have a chance, because it will be more efficient in
the end.
A typical thing with current remote-interaction-people is that they drag
two different scripts and some position files, which I find tedious and
superfluous (especially when I'm supposed to download three files to help
debugging...). If people learn how to manipulate interactions properly they
will need just one file - a very basic example I agree.

>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....

I hope it will happen soon then. :)
But honnestly removing a law takes 10sec. I can do it for you before you
get a position if that's what you want to do!

Bruno


On 29 July 2015 at 23:42, Jerome Duriez <Jerome.Duriez@xxxxxxxxxxx> wrote:

>  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
>
>