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
