yade-dev team mailing list archive

[Václav Šmilauer <eu@xxxxxxxx>]

What I proposed previously was unnecessarily complicated, since 
reference hSize (Cell::getHSize0) can be computed from trsf and hSize, 
there is no need to keep track of it. The display refHSize is in the 
code, but it will not be used in scripts most the time. Commited in 
r2693, further suggestions welcome.

The only side-effect is that setting hSize directly results in 
O.cell.trsf=Matrix3.Identity (disregarding refHSize)

Setting O.cell.refSize will still work, but will give suggestion -- 
either to use setBox(...) if setting up a new cell, or do nothing, if 
setting to the current size of orthogonal cell. In the future, refSize 
will be read-only to make sure it is not abused.

Setting O.cell.trsf=Identity will make PeriTriaxController automatically 
use the current state as reference, because of getHSize0 uses trsf^-1*hSize.

Cheers, v.

> Hi there (especially Bruno),
>
> I see that the current approach with hSize is more flexible and that 
> we can do without refSize in most cases. Also, it is true that is 
> makes more sense if trsf is just accumulator of velGrad which does not 
> change geometry and can be changed by the user freely, without any 
> impact on current geometry. There are 2 issues to be resolved:
>
> 1. We still need some reference size (or hSize) for defining goal 
> strain in PeriTriaxController and similar engines. How to do that? It 
> should be in the Cell (not in the engine), but then when to set it to 
> the current state? All that I can imagine is to set it when trsf is 
> assigned by the user: then do refHSize=trsf^-1*hSize; then the engine 
> will take as reference geometry what you say is (mechanically) 
> "undeformed" geometry; and do the same when someone sets hSize by hand 
> as well perhaps (?).
>
> 2. For displacement scaling, another reference hSize is needed (which 
> is independent from the "mechanically reference" hSize), which is 
> called a bit confusingly just refHSize in the current code, and which 
> is set (a) when refHSize sub 1. is set and (b) when required by the 
> user (the utils.setRefSe3 and such).
>
> Do you agree with the solutions, i.e. to introduce refHSize and 
> dispRefHSize and update them as described?
>
> Cheers, v.
>
> _______________________________________________
> 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