ContactPostStep
est supprimée pour une gestion élément par élément via la routine endALE
. Le but est de faire quelques opérations de post-traitement supplémentaires (du genre recalculer dev_sigma_z).MDE_NEXT
(par défaut à 1) permettant de ne pas extrapoler les déplacements lors du calcul de la première config d'un pas de temps. easZarbi
montrant un phénomène étrange dans l'EAS actuel: il est tout à fait possible d'avoir un incrément de contrainte lorsque le tnseur gradient de défo est nul. Le test consiste à cisailler un mono en t=[0,1]. Le cisaillement est ensuite maintenu en t=[1,3]. On observe une diminution des contraintes progressive lors des pas de temps de cette seconde phase. La cause est assez simple: les forces EAS qui doivent être nulles dépendent des contraintes et des modes et ne s'annulent pas quand les modes sont nuls. L'élément calcule donc des modes qui entrainent un incrément de contrainte. J'ai découvert ce phénomène étrange en débugant l'ALE sur l'EAS.mtALE/BensonLimiter.cpp added mtALE/BensonStencil.cpp added mtALE/LinearRecFacetFluxElement.cpp added mtALE/BensonLimiter.h added mtALE/BensonStencil.h added mtALE/LinearRecFacetFluxElement.h added mtALE/ConvectionStep.inl added apps/ale/testConv3Dcomp2D.py added apps/monosMeca/easZarbi.py added gen4/tests/geo9d.py added mtALE/ContactPostStep.cpp deleted mtALE/ContactPostStep.h deleted
— Romain BOMAN 2009/01/07 10:10