yade-dev team mailing list archive

[Bruno Chareyre <bruno.chareyre@xxxxxxxxxxx>]

Hi Vaclav, I'll try to answer, but don't trust me. My opinion is still 
changing each day... ;-)
> What I need is that if I set 'strain' to be something, than strain
> matrix will have those values. Currently your code resets this.
>
>   
Yes, I knew I was reseting things that you wanted user-fixed, but I 
didn't understand clearly what you wanted to do. The question is : what 
is "strain" for you?
If it describes the final deformed state that you want, it is wrong 
(i.e. perhaps what you want but theoreticaly wrong, for instance as you 
noted before, setting a constant volume strain like e11= -e22 will 
result in a volume change, we have to get rid of the small strain 
framework, and think in terms of exact velocities/transformations 
instead). I'm a bit lost in your equations, because there is this 
reference size that is modified in engines, in order to make wrong 
equations give correct results. I don't say it cannot work, but it is 
complex and misleading.

> You are computing strain from _shearTrsfMatrix, but that is
> "wrong" (i.e. not what I wanted). Those variables marked with underscore
> are really _caches_, precomputed values. Therefore
>
> 1. I propose:
>
> shearInc=dt*velGrad;
> strain=strain+_shearInc*(strain+Matrix3r::IDENTITY)-Matrix3r::IDENTITY;
> _shearTrsfMatrix=strain+Matrix3r::IDENTITY;
> // ...
>
>   
I don't understand the second equation (if strain=0, it will result in 
strain=-1!). You are assuming transformation = Id + strain, which is not 
true.
The current equations are (could be done in engines I agree) :

shearInc=dt*velGrad;
_shearTrsfMatrix = _shearTrsfMatrix + _shearIncrt*_shearTrsfMatrix;


In this case, _shearTrsfMatrix is the final transformation (not only 
shear of course) and is enough to compute everything we need in Yade. We 
don't need to define any sort of strain in the simulation, and this is a 
good thing, because there is no unique way to define a "strain" based on 
a transformation, just check the number of possible relations between 
strain and F here : http://en.wikipedia.org/wiki/Finite_strain_theory

> (note: for undeformed cell, strain matrix has 0s on the diagonal,
> whereas _shearTrsfMatrix has 1s on the diagonal)
>
>   
You cannot deduce after this remark that strain=Trsf-Id. I think this is 
really the source of our disagreement, and why I cannot comply to your 
variables and interface.

> 2. Why do we need the Hsize matrix? If we don't, the original
>
> _size=refSize+diagMult(getExtensionalStrain(),refSize); 
>
> will work just fine.
>   
We don't really need Hsize probably, but this definition of _size is 
wrong, since _size can be influenced by non-diagonal terms.
Also note that Hsize makes drawing the deformed cell easy, since the 
deformed cell is the parallelepiped defined by the 3 vectors in Hsize 
(columns).

> 3. We call it "velocity gradient", shouldn't it be just "strain rate"?
>
>   
No, strain rate is the symmetric part of velGrad only. It is not enough 
to define a displacement/velocity field.

> 4. Proposal to have refSize==Vector3r(-1,-1,-1) and raising exception if
> it is not set during computation. That would avoid "if refSize[0]!=1"
> kind of conditions which can break easily.
>
>   
It would fix the problem perhaps but I still don't really like this. 
There is a large excess of variables for now, and I would prefer to 
remove refSize and keep only _size (or the opposite).
We need to clarify their meaning because, at least on my side, I used 
your variables to represent objects not exactly corresponding to the 
name of the variable (e.g. shearTrsf is in fact just Trsf).

I'd like to restrict variables to :

1 - Something to represent sizes (currently a vector3r + angles, I'd 
prefer the matrix Hsize, which contains everything and doesn't need 
complex conversions to/from angles). Either intitial or current sizes 
but not both, since one can be deduced using :

2 - The matrix of transformation. The one called shearTrsf in my code.

3 - The velocity gradient, user defined.

4 - The displacementGradient, computed internally via dt, OR user 
defined when the user prefers to define a constant deformation 
"per-step" whatever dt.

Nothing more is needed. Could be removed :
- strain, refSizes or _size, cosMatrix.

I understood removing this would mean a lot of changes in the rest of 
your code, so I tried to compute things using my way, and to define in a 
second step the variables needed in the rest of the code.
I agree there are still problems.

Last thing : I'm not sure you can split shear and stretch ratios like 
you are trying to do now. At least, it doesn't make sense for me.

Bruno

--

_______________
Chareyre Bruno
Maître de Conférences

Grenoble INP
Laboratoire 3SR - bureau E145
BP 53 - 38041, Grenoble cedex 9 - France
Tél : 33 4 56 52 86 21
Fax : 33 4 76 82 70 43
________________