Variables like shear diplacements should be computed exactly the same
way, based on motion, whatever the dynamic status.
I prefer to compute those based on position/orientation, although it
has nothing to do with the point and merits of clarifying isDynamic
position. The isDynamic switches everywhere are frustrating.
Yes, I typed "motion" instead of "velocity" because I knew we had the
choice between vel and pos in some places. The classical Cundall
equations use velocity, so we will have both cases.
- Set a sphere !isDynamic (or block some DOF's)
- Assign it a velocity and a rotationalVelocity (or assign components
corresponding to the fixed DOF's)
- Run
- The sphere move at constant velocity (or with one component
constant), and interact with other bodies the usual way, with no
extra engine.
I doubt this is terribly useful, it gives you just constant linear
motion (I never needed it, really). I think the clarity/simplicity
argument at other places is stronger.
You may be right. It would make translationEngine or rotationEngine
useless though, which is good in itslef (we can remove them :)). Also
think about all problems like rod penetration in a packing, or triaxial
test at constant strain rate, they all define a linear motion.
It is currently not possible for at least two reasons. One reason can
be seen in updateShearForce :
Was copied from ElasticContactLaw, with all the peculiarities this
particular copy of the code has. And it is good that it will be
unified removing what is not universally needed.
Yes, that is why I was quoting your new class instead of the 6 separate
classes containing the same code. It prooves your change is usefull. ;)
Conclusion : I would remove the parameters ks, isDynamic1, isDynamic2
from the function :
updateShearForce(Vector3r& shearForce, Real ks, const Vector3r&
prevNormal, const RigidBodyParameters* rbp1, const
RigidBodyParameters* rbp2, bool isDynamic1, bool isDynamic2, Real dt,
bool avoidGranularRatcheting)
Updating the shear force (instead of shear disp.) is correct, I
changed my mind while typing this mail. We need to rotate the current
force, not only compute the new displacement. The multiplication by
ks can still be moved out of the update function.
I would rather multiply it in the function itself. Otherwise (as far
as I see) the function would take shearForce as argument, modify it
in-place (rotation etc) but return displacement difference. Highly
unintuitive:
shearForce+=ks*deltaShearDisplacement(shearForce,...); // broken:
shearForce will be modified in-place, but overwritten by the addition
again, with the first modification being lost.
The problem : people not using ElasticContact law (Tien, JF Jerier,
viscous law of Sergei perhaps, etc.) will have to define ks when this
parameter perhaps does not exist in their model. This code you
copy/pasted is the same in many constitutive laws, but not in _all_
constitutive laws.
Intuition is a matter of how you introduce things. Say, this function
rotates the interaction and return the shear displacement, would it make
more sense? Rotating the contact force is not really modifying it, is
it? ;)
An alternative would be to store shearDisplacement (instead of
shearForce) from previous step and incrementally update that ones.
Then it would make sense to multiply by ks in the constitutive law itself.
Ok, we are facing the conflict between incremental and total
formulations again. It needs to think twice to keep both of them
possible in simple code.
Incremental approach : the constitutive law needs current (rotated)
force AND the increment of shear displacement OR shear velocity. The
total displacement is undefined and we don't need it.
Total approach : computing the interaction needs initial orientation
(stored in the geometry class already, storing the shear displacement
would be a bit redundant) and current orientation. Does it need to
rotate the force at all? Perhaps this updateShearForce is needed only
with the incremental approach after all?
Bruno
--
_______________
Chareyre Bruno
Maitre de conference
Grenoble INP
Laboratoire 3SR - bureau E145
BP 53 - 38041, Grenoble cedex 9 - France
Tél : 33 4 56 52 86 21
Fax : 33 4 76 82 70 43
________________
_______________________________________________
Mailing list: https://launchpad.net/~yade-dev
Post to : [email protected]
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
