← Back to team overview

yade-dev team mailing list archive

Re: Dem3DOFGeom : ScGeom

 

Hi Chiara,

You said once that you were using updateShear=true. It was actually the only reason to keep shear and updateShear in this WT* 2365 commit. ;-) If it no longer applies, I'll remove this, in order to make ScGeom contains the bare minimum. If somebody need it again, he can derive an Ig containing shear, and update it with ScGeom::rotate(shear), as you say. He can also use Dem3Dof and get the total shear value from it.

Bruno



On 15 July 2010 21:00, chiara modenese <c.modenese@xxxxxxxxx <mailto:c.modenese@xxxxxxxxx>> wrote:

    This is because ScGeom algorithms don't need total strain (*). (*)
    One exception : HertzMindlin, thats why I suggested deriving it
    from Dem3Dof rather than ScGeom.

    Hi guys, perhaps I am escaping something. Why would HM need total
    strain? As it is now it is incremental, same way as computed in PFC.
    Anyway, PFC or not I have been studying Mindlin's paper and I plan
    to code the exact formulation in the future. And again it is all
    incremental. So no problem on my side with the current design.


One more note. Even if ScGeom is using the incremental formulation, it is always possible to calculate the total shear elastic, and eventually also plastic, displacement. It can be done, incrementally, in Law2 if needed. Same way we get the shear force. What is the problem with that?

Chiara

------------------------------------------------------------------------

_______________________________________________
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
------------------------------------------------------------------------


Ce message entrant est certifié sans virus connu
Analyse effectuée par AVG - www.avg.fr Version: 9.0.839 / Base de données virale: 271.1.1/3007 - Date: 07/15/10 13:09:00







Follow ups

References