> >> 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 _______________________________________________ yade-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/yade-dev
