Hi Luc,
I think there is an issue as well since I am planning to use the new contact 
law with the triaxial and now I do not know whether to choose Dem3DofGeom or 
ScGeom. Any further suggestion on this side?
Thanks,

Chiara






----Messaggio originale----

Da: [email protected]

Data: 29/01/2010 1.09

A: "yade-dev"<[email protected]>

Ogg: Re: [Yade-dev] ScGeom vs Dem3DofGeom



Not sure, but I think that there is an issue here.

Indeed, as Vaclav said, Dem3DofGeom has a proper representation of facet-sphere 
interaction compared to ScGeom, but, in the same time, the Triaxial Test (and 
it seems that you are planning to use it to test your contact law, like me) has 
to be used with Boxes (which are related to ScGeom) to avoid some errors in the 
calculation from what Bruno said in a previous mail.



In my case, I developed a contact law using Dem3DofGeom that I cannot test 
within the Triaxial. From what I understood, I have to rewrite my contact law 
with ScGeom to suit the Triaxial Test (something like a duplication of 
Law2_Dem3DogGeom_XXX to Law2_ScGeom_XXX with few changes in 
Ip2_XXXMat_XXXMat_XXXPhys?). 


Is this Dem3Dofgeom/Triaxialtest issue real or not? If yes, I would be pleased 
to try to do something. If not, please tell me where I am wrong.



Luc

BTW, I first faced this problem when I wanted to create the "triaxial cell 
"around one of my assembly with the yade.utils function aabbwalls which create 
boxes... 



2010/1/29 Václav Šmilauer <[email protected]>




could you tell me which is in brief the difference between ScGeom and 
Dem3DofGeom?


ScGeom uses incremental computation of shear, whereas Dem3DofGeom uses total 
formulation. ScGeom replaces facet with sphere in facet-sphere contact, 
Dem3DofGeom has proper representation of facet with 0 thickness.



I was suggesting to refactor those 2 (i.e. write it properly and have the same 
interface for both incremental and non-incremental version (so that the law 
would be the same for both), but there was not much reaction...






BTW, about the naming for a new contact law, should I follow the convention 
Law2_>>_>>_>>, shouldn't I?


Yes, please

.


If I have new variables, could I include them in the FrictPhys class? 


Derive your own class from FrictPhys, just like e.g. CpmPhys does.




Should I use the virtual function go? I see that in the ElasticContactLaw used 
in the Triaxial we use the function action..


ElasticContactLaw is old engine that puts the interaction loop inside itself 
and internally calls the elastic LawFunctor anyway. It makes the code slower.



Instead, derive your class from LawFunctor and overrider the ::go method, which 
will always act on 1 interaction only. (Read 
https://www.yade-dem.org/sphinx/prog.html#multiple-dispatch, it can be useful 
although it gets in lots of details on the c++ side)





v



_______________________________________________

Mailing list: https://launchpad.net/~yade-dev

Post to     : [email protected]

Unsubscribe : https://launchpad.net/~yade-dev

More help   : https://help.launchpad.net/ListHelp







_______________________________________________
Mailing list: https://launchpad.net/~yade-dev
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Reply via email to