yade-dev team mailing list archive

[Bruno Chareyre <bruno.chareyre@xxxxxxxxxxxxxxx>]

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