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.dur...@ucalgary.ca>: > 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...@lists.launchpad.net] on behalf of Bruno Chareyre [ > bruno.chare...@3sr-grenoble.fr] > *Sent:* July 29, 2015 2:24 PM > *To:* yade-dev@lists.launchpad.net > > *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...@lists.launchpad.net] on behalf > of Bruno Chareyre [bruno.chare...@3sr-grenoble.fr] > *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.chare...@3sr-grenoble.fr> > 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 < >> question269...@answers.launchpad.net> 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-us...@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~yade-users >>> More help : https://help.launchpad.net/ListHelp >>> >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~yade-dev >> Post to : yade-dev@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~yade-dev >> More help : https://help.launchpad.net/ListHelp >> >> > > > _______________________________________________ > Mailing list: https://launchpad.net/~yade-dev > Post to : yade-dev@lists.launchpad.net > 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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~yade-dev > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
