This is clear, but if you want to precompute, you have to place the data
somewhere. There is no place for ScGeom for total strain,
True. This is because ScGeom algorithms don't need total strain (*).
Keeping it in ScGeom would mean dragging this useless variable, the
opposite situation as the useless Vector3's in Dem3Dof now (it is a
problem, i agree). Actually, I think Dem3Dof also apply for contact
point paradigm + total formulation. It gives the consistent picture
ScGeom for incremental and Dem3Dof for total - only
incremental-continuum is missing.
(*) One exception : HertzMindlin, thats why I suggested deriving it from
Dem3Dof rather than ScGeom.
Still I don't see what was the goal state you had in mind when doing that. I
don't see what it improves and where is it supposed to lead.
What are the advantages of inheritance in general? If somebody wants a
viscous law in a Dem3Dof functor, he can currently use Chiara's incident
velocity functions, inherited from ScGeom. After revert, there will be
no incident velocity in Dem3Dof.
Bruno
_______________________________________________
Mailing list: https://launchpad.net/~yade-dev
Post to : [email protected]
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
