yade-dev team mailing list archive

[Bruno Chareyre <bruno.chareyre@xxxxxxxxxxx>]

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     : yade-dev@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~yade-dev
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~yade-dev
>> Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx
>> 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
________________