yade-dev team mailing list archive

[Bruno Chareyre <bruno.chareyre@xxxxxxxxxxx>]

Hi Jan,

I just added a getStress function because we needed it urgently with
Donia (and there was no function to get the simplest Sum(fi*lj) for
anything but Dem3Dof).
You may have a look at it (it's in fact just a copy of the code in
PeriTriax, and will replace it eventualy).
Feel free to modify/re-use. We will see if it is necessary to keep it in
the end.
If you write a more complete function, I think it should give what this
function gives by default.

I think it is better not to drag the reversedForce/Dem3Dof flags. If
necessary the sign of the returned stress can be inverted in the places
where the function is used.
A few answers to your emails are below.
On my side, I'm thinking about a function to evaluate stress around a
point, using a weighted average of per-body stress. It is an independant
problem since it will use getStressForEachBody().


On 17/03/12 18:10, Jan Stránsky wrote:
> - create separate functions for normal and shear contribution (as it is
> in utils.normalShearStressTensors)
> - other functions can be combined from this function (total stress
> vector, symmetrized stress vector etc.)
Ok for combining outputs from normalShear as long it does not imply more
loops on interactions. Currently, this normalShear function is bad
because it performs two loops, one for shear and one for normal. We have
applications where the stress is computed at each step, so we sick an
optimal algorithm for just getting the total stress.
For symmetrizing the tensor, I would personnaly tend to symmetrize it in
my scripts without checking in the documentation if it is possible to
get it already symmetrized... Well, it can't hurt if a function can do
that anyways.
> for the implementation applicable to both Dem3dofGeom and SCGeom, it
> would be nice if the IGeom class had giveLength() method. It would be in
> GenericSphereContact class and each inherited class would overload it in
> its specific way. Would you agree with this approach?
This is a good idea. The problem is it would have to be virtual, hence a
problem in terms of optimality. As you can see in the new getStress,
there is no need to get I->geom to compute stress. I->phys is enough as
long as we don't deal with reference configuration.
Therefore this virtual giveLength() should only be used for the special
case of lagrangian stress (how do you call it?) which uses refLength. I
don't know what means refLength in ScGeom to be honnest, but we will
find out. ;)
By the way, it seems to me that refLength, if used, is combined with
current normal. Wouldn't it be more more consistent to use refNormal? If
so, reference positions could be used, hence nothing would depend on
interaction geometry.
 
> I was also thinking about computation of (secant) stiffness matrix of
> periodic cell, the formulas for estimation (even though pretty good
> according to my recent tests) are very similar as for stress
> computation. The only problem is that current normal and shear stiffness
> of the interaction is needed (and in general it can differ from IPhys.kn
> or IPhys.ks as each material model treat them in different way). The
> solution would be very similar to the stress one, i.e. each IPhys class
> would have giveCurrentKn() and giveCurrentKs() methods (which would
> return kn and ks by default). Again, would you agree with such
> implementation?
Ok.
Do you really mean "secant" (F/U), not "tangent" (dF/dU)? If it was
tangent, it could also serve for applying globalStiffnessTimeStepper to
arbitrary laws.

Bruno