[Kratos] ConstitutiveLaw interface

Janosch Stascheit janosch.stascheit en rub.de
Vie Jun 4 09:38:43 CEST 2010


Hi KRATOS team,

I fully agree with Riccardo's suggestions. I think if we create a pure
virtual function GetStrainSize and GetWorkingSpaceDimension, we can
completely leave out the template parameter.

I will implement the proposed changes and repost the draft as soon as
possible.

Best regards
Janosch

Am Donnerstag, den 03.06.2010, 10:53 +0200 schrieb Riccardo Rossi:
> On Wed, 2010-06-02 at 18:29 +0200, Janosch Stascheit wrote:
> > Hi all,
> > 
> > Nelson's proposal looks quite fine in principle. As far as I can judge
> > from a first glance, the principle is very similar to the one we are
> > actually using. I have prepared the draft of a nee base class definition
> > for the constitutive law.
> > 
> > Three comments:
> > 1. I guess that the abbreviations used are referring to a kind of
> > enumeration? In this case, a complete list of variables and enumerations
> > would be nice. As far as I remember, we agreed to use Kratos variables
> > for the most common material parameters (like Density, Young's modulus)
> > and the MATERIAL_PARAMETERS vector for the specific ones of particular
> > models, right?
> 
> I completely agree about 1
> 
> > 
> > 2. A more formalised description of the input format would be handy. In
> > the file Nelson sent, I am still not quite sure about how to actually
> > define the material models
> 
> Not sure i understand your point...
> 
> > 
> > 3. This one is essential: please stick to English language comments and
> > names; and please use correct names if referring to particular persons
> > (like, for example "Mohr-Coulomb" and not "Morh-Colulomb"). This may
> > sound stupid as it is not important for the compiler. But it improvest su
> > usability and comprehensibility a lot. With respect to this issue, maybe
> > we should think about installing a kind of glossary to make sure we are
> > talking about the same things (e.g. fluency criterion <-> flow rule).
> 
> Concerning the naming of Mohr-Coulomb, Von Mises etc i completely agree.
> This is very important also because of the image it gives of the group!
> 
> concerning fluency criteria etc, could someone write a comment about
> that? in any case not all constitutive laws will use the fluency
> criteria stuff ... well the word is to Nelson on the subject
> 
> 
> > 
> > Attached, you will find my draft base class constitutive_law_new.h, a
> > respective constitutive model von_mises_3d_new and a respectively
> > changed kinematic_linear_element as a proof of concept. Some
> > explanations can be found in the additional text file.
> > 
> > Any comments and suggestions will be appreciated.
> 
> Comments on the proposal for the 
> constitutive_law_new.h
> 
> do we really need a template parameter? if it is not 100% needed than
> better to remove it to reduce the computational time
> 
> if we decide that GetValue has to give back something from the base
> class, than
> it should return Vector() and Matrix() empty objects. I don't think it
> makes sense they return objects of size 1
> 
> concerning the SetValues, we could think of making them "pure" so to
> oblige people to implement them. 
> Pooyan, what's your opinion about this?
> 
> We need also the functions
> InitializeNonLinearIteration
> FinalizeNonLinearIteration
> FinalizeSolutionStep (here for example we need to save the values)
> 
> In my opinion CalculateMaterialResponse should have flags like 
> bool calculate_stress
> int calculate_tangent (this could be a int so to use it for algorithmic
> tangent or any other choice)
> bool save_internal_variables 
> 
> Volumetic response should work with doubles ...
> virtual void CalculateVolumetricResponse( const double&
> volumetric_strain,
>                                                       double& pressure,
>                                                       double&
> bulk_modulus,
>                                                       const ProcessInfo&
> CurrentProcessInfo,
>                                                       const Properties&
> props, 
>                                                       const
> GeometryType& geom,
>                                                       const Vector&
> ShapeFunctionsValues )
> 
> 
> and i think that the deviatoric one should assume a deviatoric strain
> tensor is provided
> 
> i believe that CalculateStressAndTangent is not needed anymore ...
> although one can implement it and use it internally as a private
> function.
> 
> on the other hand i think that CalculateCauchyStress should be public
> 
> furthermore i would like to propose the functions (virtual pure!!)
> 
> GetStrainSize
> GetWorkingSpaceDimension
> 
> finally we were discussing with Pooyan the possibility of introducing a
> function 
> "ValidateMaterial" (virtual pure once again)
> to be used in checking that the properties provide all of the variables
> needed for the calculations. If we like we could even check in there if
> the 
> numbers given make sense or not...
> 
> okk ... i wrote a lot ... 
> hope this can be useful
> 
> ciao
> Riccardo
> 
> > 
> > Best regards
> > Janosch
> > _______________________________________________
> > Kratos mailing list
> > Kratos en listas.cimne.upc.edu
> > http://listas.cimne.upc.edu/cgi-bin/mailman/listinfo/kratos
> 
> _______________________________________________
> Kratos mailing list
> Kratos en listas.cimne.upc.edu
> http://listas.cimne.upc.edu/cgi-bin/mailman/listinfo/kratos



More information about the Kratos mailing list