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 [[email protected]]
on behalf of Bruno Chareyre [[email protected]]
Sent: July 29, 2015 2:24 PM
To: [email protected]
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
[[email protected]<mailto:[email protected]>]
on behalf of Bruno Chareyre
[[email protected]<mailto:[email protected]>]
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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>>
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 :
[email protected]<mailto:[email protected]>
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 : [email protected]<mailto:[email protected]>
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 : [email protected]<mailto:[email protected]>
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 : [email protected]
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
