Re: [Yade-dev] Cell deformation handling
Hi Bruno, I think it makes sense what you write and it is good that you did the implementaiton that works. The fact that flipCell can be encapsulated inside the collider is nice, for instance. 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
Re: [Yade-dev] Cell deformation handling
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
[Yade-dev] Cell deformation handling
Hi (Jan, Vaclav), If I understand correctly (looking at scripts), Cell::trsf is currently used to define the initial geometry of the period (e.g. applying rotations). Is that correct? I didn't expect this usage when I introduced it, as it was supposed to record cumulated transformations. The annoying thing is that it is impossible to uncouple initial geometry and material transformation in this approach. For instance, it is not possible to have trsf=Zero for initial cells that are not an axis aligned. My suggestion is to define the initial geometry using Hsize, instead of refSize and trsf (the old behaviour would still be possible). I started implementing that, but before I commit anything, did I overlook something? Bruno -- ___ 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
