| Thread Previous • Date Previous • Date Next • Thread Next |
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.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.
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.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.- 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.
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. ;)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.It is currently not possible for at least two reasons. One reason can be seen in updateShearForce :
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.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: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.shearForce+=ks*deltaShearDisplacement(shearForce,...); // broken: shearForce will be modified in-place, but overwritten by the addition again, with the first modification being lost.
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? ;)
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.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.
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 ________________
| Thread Previous • Date Previous • Date Next • Thread Next |
