Yade

Unifiy stress definitions

Registered by Bruno Chareyre

Not a crucial bug, but it would be nice to clarify the different functions returning homogenized stress (listed below). It needs however the agreement of the different authors. My suggestions are below, for opening the discussion.

Existing functions:
shop::stressTensorOfPeriodicCell -> py::stressTensorOfPeriodicCell
shop::normalShearStressTensors -> py::normalShearStressTensors
shop::getStressLWForEachBody -> py::bodyStressTensors
shop::getStressForEachBody -> no python wrapping, but used in VTK recorder

PeriTriaxController::strainStressStiffUpdate is also implementing its own stress computation, while it could use stressTensorOfPeriodicCell(false) to get the same result (if only the latest was not restricted to Dem3Dof geometries).

In addition, yade.eudoxos.estimateStress, _eudoxos::macroAroundPt are very specific (could be removed if nobody use them).

It seems most functions are variants of the Love-Weber formula sij=Sum(Fi*Lj)/Volume (1), where F is the contact force and L is the vector pos2-pos1. It applies for any shape of bodies in periodic-or-not situations.

1) While this expression can be computed exactly without difficulty, some functions are making approximations: normalShearStressTensors() is using l ~ (R1+R2), which is not equivalent as soon as the normal displacement is not zero (and assumes spherical bodies only); stressTensorOfPeriodicCell(True) is using initialLength*currentNormal for L, which gives another approximation of (1).
A step in the direction of unification would be to use (1) everywhere. Is there an agreement on this aspect?

2) No function contains all the different features currently, which are:
a)- return average stress (in periodic and non-periodic situations)
b)- return per-body stress tensor
c)- split normal/tangent forces, and weak/strong forces
It is maybe difficult to merge a) and b) in a unique function since the return values are of different types, but we could at least merge c) into the other ones, resulting in only two functions, one per-body and one computing the average, each with all possible splits.

I propose a two-step implementation:
- first, introduce the two functions doing everything (periodic or not, normal/shear, weak/strong): one per-body and one for the average.
- second, remove all the other functions (and make the old functions alias-names for the new ones).

It is useless to start the first step if there is no prior agreement on the second one, since it would result in even more functions than before... So what do you all think?

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
Bruno Chareyre
Direction:
Needs approval
Assignee:
Bruno Chareyre
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

>Thanks Jan. I just discover that the whiteboard does not allow replies... Let me rework >Jan's message, and everybody can iterate that way, trying to converge.

>>I would not merge stress of periodic cell and per-body stress, as I am not sure if
>> one can define the "volume of particle" (which would depends on packing)..

>For mean stress, there is also a question on volume if not-periodic, I suggest the same >approach as for porosity: if not periodic, use user provided volume passed as a >variable, else use cell volume.
>For per-body stress, I'm actually already using per-particle volumes, but it depends on >the optional package TesselationWrapper. So we better keep the function as it is now >(using particles volume), and just add the splits.

>>For periodic cell: (1) s_ij = F_i*L_j/V. This can be easily symmetrized if sombody (me
>>for example :-) wants. I would use two argument for this function. One for
>>computing L: current length (C1-C2), distance of centers, and (Cr1-Cr2), refference
>>length computed as difference of reference positions. The second argument would
>>be about volume, either use current or reference volume.

>Ok.

>>PS: to extend the collections of functions, in CpmStateUpdater there is another
>>function for computing per-body stress :-)

>Heh, it was expected. This one is hard to find so it should not be a problem.
>I forgot to mention that Shop::getStressForEachBody is in fact not using (1), since it is >based on contacts cross-sections (and only applies for Dem3Dof). So, the question is, >does somebody (Jan maybe?) need that?

I (Jan) have never used Shop::getStressForEachBody ...

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.
Edit subscription

Subscribers

No subscribers.