← Back to team overview

yade-dev team mailing list archive

Re: ScGeom vs Dem3DofGeom

 

In fact, the triaxial test could be done with facets if only the reason of instabilities could be found. It is probably just a small bug, but I have no idea where to start (I never read in details the code generating facets and controlling them, I use only boxes) and no time for that now.
You can try to pinpoint the problem, it would be good to find it.

Bruno


uc scholtes a écrit :
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 <eudoxos@xxxxxxxx <mailto:eudoxos@xxxxxxxx>>

        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
    <https://launchpad.net/%7Eyade-dev>
    Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx
    <mailto:yade-dev@xxxxxxxxxxxxxxxxxxx>
    Unsubscribe : https://launchpad.net/~yade-dev
    <https://launchpad.net/%7Eyade-dev>
    More help   : https://help.launchpad.net/ListHelp


------------------------------------------------------------------------

_______________________________________________
Mailing list: https://launchpad.net/~yade-dev
Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp


--
_______________
Bruno Chareyre
Associate Professor
Grenoble INP
Lab. 3SR
BP 53 - 38041, Grenoble cedex 9 - France
Tél : 33 4 56 52 86 21
Fax : 33 4 76 82 70 43
________________




References