← Back to team overview

yade-dev team mailing list archive

[Branch ~yade-dev/yade/trunk] Rev 2540: 1. Add optional MatchMaker to Ip2_FrictMat_FrictMat_FrictPhys to decide how to compute contact fr...

 

------------------------------------------------------------
revno: 2540
committer: Václav Šmilauer <eu@xxxxxxxx>
branch nick: yade
timestamp: Fri 2010-11-12 08:11:52 +0100
message:
  1. Add optional MatchMaker to Ip2_FrictMat_FrictMat_FrictPhys to decide how to compute contact friction angle.
modified:
  pkg/dem/Ip2_FrictMat_FrictMat_FrictPhys.cpp
  pkg/dem/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/Ip2_FrictMat_FrictMat_FrictPhys.cpp'
--- pkg/dem/Ip2_FrictMat_FrictMat_FrictPhys.cpp	2010-10-13 16:23:08 +0000
+++ pkg/dem/Ip2_FrictMat_FrictMat_FrictPhys.cpp	2010-11-12 07:11:52 +0000
@@ -41,7 +41,7 @@
 	//same for shear stiffness
 	Real Ks = 2*Ea*Ra*Va*Eb*Rb*Vb/(Ea*Ra*Va+Eb*Rb*Va);
 	
-	contactPhysics->frictionAngle = std::min(mat1->frictionAngle,mat2->frictionAngle);
+	contactPhysics->frictionAngle = frictAngle ? std::min(mat1->frictionAngle,mat2->frictionAngle) : (*frictAngle)(mat1->id,mat2->id,mat1->frictionAngle,mat2->frictionAngle);
 	contactPhysics->tangensOfFrictionAngle = std::tan(contactPhysics->frictionAngle); 
 	contactPhysics->prevNormal = normal;
 	contactPhysics->kn = Kn;

=== modified file 'pkg/dem/Ip2_FrictMat_FrictMat_FrictPhys.hpp'
--- pkg/dem/Ip2_FrictMat_FrictMat_FrictPhys.hpp	2010-10-13 16:23:08 +0000
+++ pkg/dem/Ip2_FrictMat_FrictMat_FrictPhys.hpp	2010-11-12 07:11:52 +0000
@@ -9,6 +9,7 @@
 #pragma once
 
 #include<yade/pkg-common/Dispatching.hpp>
+#include<yade/pkg-common/MatchMaker.hpp>
 
 class Ip2_FrictMat_FrictMat_FrictPhys: public IPhysFunctor{
 	public:
@@ -16,7 +17,9 @@
 			const shared_ptr<Material>& b2,
 			const shared_ptr<Interaction>& interaction);
 	FUNCTOR2D(FrictMat,FrictMat);
-	YADE_CLASS_BASE_DOC(Ip2_FrictMat_FrictMat_FrictPhys,IPhysFunctor,"Create a :yref:`FrictPhys` from two :yref:`FrictMats<FrictMat>`. The compliance of one sphere under symetric point loads is defined here as 1/(E.r), with E the stiffness of the sphere and r its radius, and corresponds to a compliance 1/(2.E.r)=1/(E.D) from each contact point. The compliance of the contact itself will be the sum of compliances from each sphere, i.e. 1/(E.D1)+1/(E.D2) in the general case, or 1/(E.r) 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.\n\n The shear stiffness ks of one sphere is defined via the material parameter :yref:`ElastMat::poisson`, as ks=poisson*kn, and the resulting shear stiffness of the interaction will be also an harmonic average.\n\n The friction angle of the contact is defined as the minimum angle of the two materials in contact.\n\nOnly 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\tYou have to suppose some exact type of IGeom in the Ip2 functor, but you don't know anything about it (Ip2 only guarantees you get certain IPhys types, via the dispatch mechanism).\n\n\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 IGeom type of the interation passed to that particular Ip2 functor.");
+	YADE_CLASS_BASE_DOC_ATTRS(Ip2_FrictMat_FrictMat_FrictPhys,IPhysFunctor,"Create a :yref:`FrictPhys` from two :yref:`FrictMats<FrictMat>`. The compliance of one sphere under symetric point loads is defined here as 1/(E.r), with E the stiffness of the sphere and r its radius, and corresponds to a compliance 1/(2.E.r)=1/(E.D) from each contact point. The compliance of the contact itself will be the sum of compliances from each sphere, i.e. 1/(E.D1)+1/(E.D2) in the general case, or 1/(E.r) 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.\n\nThe shear stiffness ks of one sphere is defined via the material parameter :yref:`ElastMat::poisson`, as ks=poisson*kn, and the resulting shear stiffness of the interaction will be also an harmonic average.\n\nThe friction angle of the contact is defined as the minimum angle of the two materials in contact.\n\nOnly 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\tYou have to suppose some exact type of IGeom in the Ip2 functor, but you don't know anything about it (Ip2 only guarantees you get certain IPhys types, via the dispatch mechanism).\n\n\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 IGeom type of the interation passed to that particular Ip2 functor.",
+		((shared_ptr<MatchMaker>,frictAngle,,,"Instance of :yref:`MatchMaker` determining how to compute interaction's friction angle. If ``None``, minimum value is used."))
+	);
 };
 REGISTER_SERIALIZABLE(Ip2_FrictMat_FrictMat_FrictPhys);