> isDynamic means : acceleration = force/mass. > !isDynamic means : acceleration is something else, or even it is left > undefined. > > However, !isDynamic doesn't mean that a body has no velocity. This > velocity can be constantly zero, or constantly something, or > constantly changing based on a kinematic engine. Seems OK, except the we need to make sure it doesn't break with the current DiiExMachina that frequently modify positions themselves (RotationEngine and friends), i.e. remove the position update from those engines. It will be more consistent. Engines will be "allowed" only to change positions indirectly, through velocity change. > 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. > - 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. > > 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. > > 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. If you return void, it is clear what is meant: updateShearForce(shearForce,ks,...); 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. > > However, I suspect there would be a problem with kinematic engines, > because Newtons law and engines would both set the positions. Oh, I wrote the above before carefully reading (just saying the same thing). I prefer the engines fixed rather than adding new flag. _______________________________________________ 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
