Hi, It's commited. Attributes doc should be ok but header doc and sphinx doc are TODOs. All scripts I could find seems to run unmodified. I replaced definition of trsf and refSize by setters in the scripts (couldn't find a better way since integrateAndUpdate can't really do the job now). Setters are defined in such a way that they reproduce the older functionality (trsf=0 only if Hsize is axisAligned). Hsize setter allows arbitrary shape. The beauty of this is that there is no change at all in collider and display, since they use shearTrsf, itself defined on the basis of Hsize, indepently of trsf! There are a few places where I replaced refSize by size, it should be safe at first sight but I'll double check.
> The fact that flipCell can be encapsulated inside the collider is nice, for instance. Oh wait, this one is not done yet, ok? Cheers! Bruno I would like to just ask for 2 things: > > > 1. Make sure that the old interface (setting refSize etc) works, there > is already quite a few people having script that use it and they > should not break (the scripts I mean, but perhaps people would break > as well). > > 2. Update not only the documentation of the class, but also the DEM > formulation chapter on periodic cell > (https://www.yade-dem.org/doc/formulation.html#periodic-boundary-conditions) > > Cheers, v. > >> Hi Vaclav, thanks for reply. >> I actually finished the implementation in the meantime. >> >>> Cell.trsf defines the current (not initial) transformation of the cell >>> with regards to the reference configuration, which is always >>> axis-aligned box with size Cell.refSize. (Footnote: although I did not >>> check bzr log, I am quite sure it was me who introduced Cell.trsf.) >>> Cell.trsf is accumulated from Cell.velGrad. >> Yes, that's what I described : trsf is defining the initial _geometry_. >> (footnote : my bad, sorry. I only introduced incrementation on velGrad >> basis then.) >>> If you suggest to define the reference (initial) geometry by using >>> general parallelepiped (instead of axis-aligned box), I would oppose; >>> not that it does not make sense geometrically, but brings quite a bit >>> of complexity where the current facilities are enough. >> That is what I suggest indeed. >> Actually, this suggestion came after fixing an obvious mistake in Cell >> interface, which triggered a code cleaning spree. >> It would make things simpler and help clarify in the long run, else I >> would not bother. PBCs and related engines code is excessively complex >> and overconstrained currently. Removing the axis-aligned constraint >> makes things more general without adding any complexity. >> >> PBCs offer the opportunity of writing (1) frame invariant and (2) >> shape-independant mechanics by just controlling velGrad and stresses in >> periodic engines, but this advantage is not really used currently. >> One reason is the lack of clear split between what is needed/modified >> for mechanics, for contact detection, and for graphical representation. >> Overall, mixing all of them results in contaminating the mechanical >> parts with frame-dependant and (initial)shape-dependant code, which is >> never a good thing. >> >> A few examples : >> - velGrad is describing a mechanical effect and is reflected in trsf, >> but at the same time trsf is used to describe the initial geometry. So, >> it is useless for the user, who has to maintain his own material >> transformation. Even worst, trsf can be changed for contact detection >> (flipCell), while this could be hidden away in collider internals. >> - shearTrsf and friends are not describing shear in the mechanical >> sense. It is only something that we use for colliding and display, it >> results in misleading semantic. >> - refSize is (partialy) describing the initial shape, so it should not >> influence mechanics at all. Unfortunately, it is used in many places in >> PeriEngines, it is used to redefine Hsize at each step (not needed), can >> be modified by users and even by OGLrenderer (?!). It sounds insecure. >> >> The suggested change is a small step in the good direction regarding >> this sort of problems (introducing velGrad and Hsize was on the same >> line btw). >> >>> 2. If you need reference (initial) cell that is already deformed, then >>> you can always "subtract" (in the sense of transformation matrices, >>> i.e. something like A^-1*B*(A^-1)^T) the initial trsf from the current >>> one to get the part that corresponds to material transformation. >> It would work, but this is the sort of complexity that arbitrary initial >> shapes would remove. >>> Do you have some concrete scenario in mind? Not saying that it can not >>> exist, but I've never seen the initial sample to be periodic obliquely. >> Check Jan's scripts (reason why I mentionned him in o.p.)? I do have >> scenarii too. Also important, it clarifies and help writing frame >> invariant mechanics. >> >> Local diffs pass reg. tests and gives stable stress-strain behaviour >> starting from non-rectangular box. refSize is not used anywhere, except >> in OGLRenderer. Functionalities used in existing scripts (refSize=..; >> trsf=...) are preserved, though it doesn't really help simplifying the >> code. The new thing is you can prescribe arbitrary initial geometry >> (Hsize=...) while keeping trsf null. >> Would you give it a chance? >> >> Bruno >> >> >> >> _______________________________________________ >> 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 - France 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
