yade-dev team mailing list archive

[noreply@xxxxxxxxxxxxx]

------------------------------------------------------------
revno: 2107
committer: Bruno Chareyre <bchareyre@r1arduina>
branch nick: trunk
timestamp: Fri 2010-03-26 23:25:20 +0100
message:
  - Fix syntax error + small changes in the documentation.
modified:
  pkg/dem/Engine/Functor/Ip2_FrictMat_FrictMat_FrictPhys.hpp


--
lp:yade
https://code.launchpad.net/~yade-dev/yade/trunk

Your team Yade developers is subscribed to branch lp:yade.
To unsubscribe from this branch go to https://code.launchpad.net/~yade-dev/yade/trunk/+edit-subscription.

=== modified file 'pkg/dem/Engine/Functor/Ip2_FrictMat_FrictMat_FrictPhys.hpp'
--- pkg/dem/Engine/Functor/Ip2_FrictMat_FrictMat_FrictPhys.hpp	2010-03-26 20:39:30 +0000
+++ pkg/dem/Engine/Functor/Ip2_FrictMat_FrictMat_FrictPhys.hpp	2010-03-26 22:25:20 +0000
@@ -16,7 +16,7 @@
 			const shared_ptr<Material>& b2,
 			const shared_ptr<Interaction>& interaction);
 	FUNCTOR2D(FrictMat,FrictMat);
-	YADE_CLASS_BASE_DOC(Ip2_FrictMat_FrictMat_FrictPhys,InteractionPhysicsFunctor,"Create a :yref:`FrictPhys` from two :yref:`FrictMats<FrictMat>`. The compliance of one sphere under symetric point loads is defined in here as 1/(E.D), with E the stifness of the sphere and D its diameter, and corresponds to a compliance 1/(2.E.D) from each side. The compliance of the contact itself will be the sum of compliances from each sphere, i.e. 1/(2.E.D1)+1/(2.E.D1) in the general case, or 1/(E.D) in the special case of equal sizes. Note that summing compliances corresponds to an harmonic average of stiffnesss, which is how kn is actually computed in the :yref:Ip2_FrictMat_FrictMat_FrictPhys functor. The friction angle of the contact is defined as the minimum angle of the two materials in contact. \n\n\ Only interactions with :yref:`ScGeom` or :yref:`Dem3DofGeom` geometry are meaningfully accepted; run-time typecheck can make this functor unnecessarily slow in general. Such design is problematic in itself, though -- from http://www.mail-archive.com/yade-dev@xxxxxxxxxxxxxxxxxxx/msg02603.html:\n\n\t\t\tYou have to suppose some exact type of InteractionGeometry in the Ip2 functor, but you don't know anything about it (Ip2 only guarantees you get certain InteractionPhysics types, via the dispatch mechanism).\n\n\t\t\tThat means, unless you use Ig2 functor producing the desired type, the code will break (crash or whatever). The right behavior would be either to accept any type (what we have now, at least in principle), or really enforce InteractionGeometry type of the interation passed to that particular Ip2 functor.\n\nEtc.");
+	YADE_CLASS_BASE_DOC(Ip2_FrictMat_FrictMat_FrictPhys,InteractionPhysicsFunctor,"Create a :yref:`FrictPhys` from two :yref:`FrictMats<FrictMat>`. The compliance of one sphere under symetric point loads is defined here as 1/(E.D), with E the stiffness of the sphere and D its diameter, and corresponds to a compliance 1/(2.E.D) from each contact point. The compliance of the contact itself will be the sum of compliances from each sphere, i.e. 1/(2.E.D1)+1/(2.E.D1) in the general case, or 1/(E.D) in the special case of equal sizes. Note that summing compliances corresponds to an harmonic average of stiffnesss, which is how kn is actually computed in the :yref:Ip2_FrictMat_FrictMat_FrictPhys functor. The friction angle of the contact is defined as the minimum angle of the two materials in contact. \n\n Only interactions with :yref:`ScGeom` or :yref:`Dem3DofGeom` geometry are meaningfully accepted; run-time typecheck can make this functor unnecessarily slow in general. Such design is problematic in itself, though -- from http://www.mail-archive.com/yade-dev@xxxxxxxxxxxxxxxxxxx/msg02603.html:\n\n\t\t\tYou have to suppose some exact type of InteractionGeometry in the Ip2 functor, but you don't know anything about it (Ip2 only guarantees you get certain InteractionPhysics types, via the dispatch mechanism).\n\n\t\t\tThat means, unless you use Ig2 functor producing the desired type, the code will break (crash or whatever). The right behavior would be either to accept any type (what we have now, at least in principle), or really enforce InteractionGeometry type of the interation passed to that particular Ip2 functor.\n\nEtc.");
 };
 REGISTER_SERIALIZABLE(Ip2_FrictMat_FrictMat_FrictPhys);