Ah, last thing : generateCloud don't find any problem to fill non-aligned boxes (in the cases I tested at least), but I still don't know why... Maybe it's generating in axis aligned box then wrapping? I didn't take time to verify. It can't affect older scripts anyway.
B. On 19/01/11 19:28, Bruno Chareyre wrote: > 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 : [email protected] >>> Unsubscribe : https://launchpad.net/~yade-dev >>> More help : https://help.launchpad.net/ListHelp >>> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~yade-dev >> Post to : [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 - 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 : [email protected] Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
