ConstitutiveModelsApplication project

[josep-m-carbonell]

This issue is to discuss about having a constitutive models application that will include all the capabilities related to material modelling. As well it will be the reference to extend custom constitutive models in other applications.

That will mean to migrate the constitutive models from the SolidMechanicsApplication to the ConstitutiveModelsApplication and all variables related to the Material Properties.

The proposed structure for C++ objects is the following:

  elasticity_models (which will contain the objects:)
          hyperelastic_laws
                       hyperelastic_models
          hypoelastic_laws
          linear_elastic_laws

   plasticity_models (which will contain the objects:)

           hyperelastic_plastic_laws
                        flow_rules
                        hardening_laws
                        yield_criteria             
            linear_elastic_damage_laws
            linear_elastic_plastic_laws

From that structure the thermal, UP, hydromechanic.... laws could be derived.

There will be the possibility of testing a constitutive law from python. There will be the possibility of writing a constitutive law from python, interpreted for C++ with as a python_outfitted_constitutive_law.

At the same time it will integrate the new json input for the constitutive law.

During this process some extensions to the current design of the constitutive laws can be discussed and incorporated to improve and extend the current capabilities.

 **Please feel free to make questions give your opinion and make suggestions**      

@KratosMultiphysics/technical-committee @KratosMultiphysics/structural-mechanics @KratosMultiphysics/pfem @KratosMultiphysics/dem @KratosMultiphysics/poromechanics @KratosMultiphysics/multiscale

[ipouplana]

Then, the idea is to move all constitutive laws into this application? If it is so, we would use this application similarly as the ExternalSolversApplication? Or should we derive from it?

[rubenzorrilla]

Regarding the fluid dynamics constitutive laws, should they be moved to this new app as well?

[pooyan-dadvand]

I see that this would increase the modularity of the code but I don't like the idea due to different reasons:

• I usually opt for self contained applications unless there is a clear index of some shared module or third party libraries like external solvers. And in my opinion this division would damage the integrity of solid mechanic app.
• I don't see many use cases in which only one of the solid mechanic app or the constitutive law app can be used without importing the other. So this splitting only adds another import line to pythons which exposes some unnecessary implementation details to whom wants to use it.
• One may not even read an input file without both of them while elements are defined in one and properties in the other.
• The dividing the variables between two applications is tricky and any duplication at this moment is a pain to deal with (I know that we plan to improve this part of Kratos) and many variables would end up in core which won't be an optimum solution now.
• In python scripts in which the namespace is explicitly defined this change leads to large refactoring. (I should add that I have not check if this is the case for SolidMechanic/StructuralMechanic apps

So I think that at least now is not the best moment for such a division. Nevertheless I'm completely open to other opinions and admit that some of my criteria are subjective.

[josep-m-carbonell]

@pooyan-dadvand and @KratosMultiphysics/technical-committee

• The input and the python imports are not a major problem:

Right now, the inputs are separated. The constitutive law is created using a "prototype" object in materials.py, and then it is passed to the properties objects. This will be replaced in the future for a similar process taking json parameters, and joining material properties and constitutive law. So the only python that must import this application will be this python. The elements are provided in the mpda with an Id of the property. Therefore there is not a real conjunction of this entities.

• The separate possible uses:

I think that we must promote the functionality of a constitutive model without passing through an element. Using a well defined deformation case, we can ask to the constitutive law the resultant material response. There are currently some tests to do it from a python script. In this case, the constitutive model application can work without the need of the solid mechanics or any other application. (Some feedback from people working in material science is needed here)

This can be used to test if a law is working correctly and maybe useful for another type of analysis, fatige, multiscaling.... (Some feedback from people working in these fields is also needed here).

(- This is independent to this project but : I would like also to open a issue to ask people the need of some redefinition of the design to extend the use of the same concepts in the code. For example a common definition of the yield functions to have the possibility of using it in different applications, DEM constitutive models, Contact Frictional Models..... This will make the application more general and not only something customised to the SolidMechanicsApp.)

• The variables:

  The purpose is to take the variables to be used in the constitutive law, and define, create and register them in this application. Once this is done, take them out from the SolidMechanicsApplication. Right now the variables of properties are not manipulated so much in python scripts

• The refactoring:

  The SolidMechanicsApplication will have the need of the ConstitutiveModelsApplication, that's true. It increases the refactoring. It is the same relationship that currently exists between the Solid and the Structural applications. A good solution will be the fusion of the Solid and the Structural applications. A clear division of an application with the material technology (ConstitutiveApp) and an application with the elements technology (SolidMechanicsApp/StructuralMechanicsApp => SolidMechanicsApp or another name). (joining the current names of the licences, if everybody agrees @KratosMultiphysics/technical-committee "Better Late than never" )

So the proposed change is huge. But I think it is the moment to decide this, to create a good division and a stable structure/disposition for the future core/stable applications.

@ipouplana Of course not all constitutive laws must be programmed in the constitutive models application. You could continue to have your own constitutive models. You just will have to change the dependency if your constitutive law is derived from the one defined in the SolidMechanicsApp, if they are removed and located in the ConstitutiveModelsApp

@rubenzorrilla This is not decided yet, the fluid dynamics team must see what is more convenient.

[RiccardoRossi]

Hi all, i'll begin by saying that it is not unattractive to me to have a ConstitutiveLawApplication.

I should say however that the point that Pooyan rises about variables is a very valid one. Since the variables to be employed would have to be used in multiple applications this is definitely a potentially major issue. Since i really would prefer not to have compile time dependencies between applications, the only solution i see is to define them in the core, which is definitely not a nice option. I am not sure wheter i consider this a blocker or not, i will think more about this...

[josep-m-carbonell]

Hello

I understand the problem about the variables. -We can not define the same variable in two applications. -When you are using application (1) and application (2) in your solution. If a variable is defined in the application (1) and we need to use it in the application (2) there are two ways to avoid conflicts: 1) Include and compile the application (1) when compiling the application (2). Therefore you don't have to define the variable twice and there is a unique definition. 2) Define this variable in the kratos core, and erase the definition in application (1). Then all applications can use this variable and it is unique.

Rigth now, if you want to use the SolidMechanicsApplication and also use, in your application, some variables defined in the SolidMechanicsApplication; you must apply option one. I understand that this is a problem, but I don't see that it will be different or worse if a ConstitutiveModelsApplication is created. Maybe I missing some aspects..? ¿

Another problem to remember here about the variables:

• When you use more than one application you do not know what nodal variables are going to be called inside the c++ objects. Well, maybe you know them, but it is easy to forget or not add some of them in the model_part. So, if you do not add one of them in the model_part, the first time you use it, it is added to the modelpart. But depending on the name (the alphabetical order) it will destroy some other variables. Usually dofs are destroyed. Therefore you must add all variables to avoid problems, but at the same time there is no place to check if you are missing any of them (maybe they are used in an application that you do not control)

[vryy]

Hello, I'd like to add my thought here regarding using the variable in different application. That can be done, by using a dirty hack, i.e by getting it from the kernel and static_cast as needed. Of course you have to include the other application in the python script and know exactly the type of this variable to avoid seg-fault error

Example script: Variable<int>& INTEGRATION_ORDER_var = static_cast<Variable<int>&>(KratosComponents<VariableData>::Get("INTEGRATION_ORDER")); mpElement->SetValue(INTEGRATION_ORDER_var, mRepresentativeIntegrationOrder);

Let me know if this practice may create some problem, i.e. memory leak, break the kernel, ...

[pooyan-dadvand]

Let's turn back to the original discussion and don't mix it with variables problems.

• About the input I see your point that they are in different files but again for reading the entire model you would always need both of them. Again, exposing an implementation detail to users which can be avoided

• I don't get your use case for individual use..... if it is for a test I don't agree with it and for me it is not an enough reason. For me a use case would be an application in GUI which uses only one application. (As @josep-m-carbonell mentioned more comments are welcomed in this part.)

• I should add that from my point of view a good reason for such a division would be to separate the teams involved in it. This would be the case if kratos used by material groups.

• The problem of variables is a serious one at the moment. I know a clear solution to that but it will take me sometime to implement it. So at least I would try to avoid duplicated variable and more application dependency until then.

• Now I see that @josep-m-carbonell is also notes the fact that this division would drastically reduce the integrity of solid mechanic application. In my opinion dividing application by material and element concept is much better division than what we have now.

As @josep-m-carbonell mentioned this would be a huge refactoring. So the question would be:

• what we gain with that
• why we should do it now

[josep-m-carbonell]

I think we need to know the opinion of another Kratos developers too. Of course there are some advantages and disadvantages. They have been exposed here. I will open a issue with the variables problem to be discussed apart. I will copy the posts related to that issue there.

[maceligueta]

Honestly, I was expecting a short list of advantages in any of your messages ( @josep-m-carbonell , @RiccardoRossi ). The list of disadvantages posted by @pooyan-dadvand is very clear and convinces me a lot. Still two questions by Pooyan remain unanswered:

• what we gain with that?
• why should we do it now?

As @josep-m-carbonell said, from the DEM application we would like to use Yield Surfaces, Flow Rules, etc... But I don't think a migration to a different app would be sufficient. A bigger change would be needed and it would not be urgent from my side.

[loumalouomega]

I agree with decomposition of the CL, but if and only if we check that is not breaking anything and we add the corresponding tests, and correct the ones not working. Additionally this is a huge step forward and we should send an email to inform to anyone related with Kratos.

[RiccardoRossi]

@maceligueta just to say that i am not pushing in any direction. Mostly reading the discussion and thinking about for the moment

@loumalouomega if we take any decision we will definitely do as you say...but this is just at the level of discussion for now

[josep-m-carbonell]

@maceligueta and @pooyan-dadvand

Well I think that the list of disadvantages that Pooyan listed are very general, we currently have these problems in kratos, there is nothing new that will be introduced for the use of a new application. That creates an artificial unbalanced comparison between advantages and disadvantages.

-- In the input, of course you have to import the applications where the constitutive laws are implemented if you want to create and assign a constitutive law to elements. How you avoid this ? If I have some constitutive laws implemented in the PfemSolidMechanicsApplication I will have to import that application to use those laws. Is this a new "disadvantage" ? , it is not new.

-- Testing is a good reason, organization is a good reason, the use by the material groups (a new strategy to implement a constitutive law is needed for them, something easy and clear. Maybe the option to implement it in python) . If an application do not have a GUI, because it is a more abstract application it has no reason to exist ¿?... There are some applications of this type. However I can imagine a simple GUI where you select graphically some points in the strain state and you get the graphs for the stress state, the return mapping lines and the graph of the evolution of the yield surfaces.

-- The problem of the variables (something general of kratos) and the integrity of the SolidMechanics, a proposal is made to organize it in a better way.

@maceligueta: If you see any new advantage or disadvantage you can post it here.

What we gain with that ?

A better structure and order, a clear functionality and definition of each application.

Why should we do it now?

We are discussing it, to do it now, to do it next month or to do it never. If we bet on the change, I think it is better to do it sooner than later. When it will be ready and could replace the current functions. What we must wait for ? When some of the Kratos exposed problems will be solved (i.e. variables problem), in one or two years ? ( I'm trying to be realistic not, I'm not criticizing )

There is also another reason: to introduce the set of hyperelastic models for the treatment of different rubber materials the structure of the current hyperelastic constitutive laws must be enlarged. Important changes are needed. The "custom_constitutive" folder in the SolidMechanicsApp, will self-contain such amount of folders and sub-folders, that its structure and size will be comparable to a single large application.

....

[maceligueta]

@josep-m-carbonell : about your sentence

If I have some constitutive laws implemented in the PfemSolidMechanicsApplication .

For those of us who don't know the details, why are these CL in the PfemSolidMechanicsApplication instead of the SolidMechanicsApplication? Why are not all of them in the SolidMechanicsApplication?

[josep-m-carbonell]

Each developer has constitutive laws in their own applications.... The constitutive law base class is in Kratos not in the SolidMechanics. Are you proposing to put all of them in the same application ?

[maceligueta]

I was not proposing anything, just asking why they are in different places. If the reason is Each developer has constitutive laws in their own applications, this is not a technical reason. On top of that, for the PfemSolids and the SolidMechanics the developers are the same person. Apart from this, maybe all the Solid Models should be in the SolidMechanics application, but I don't even know if this makes sense. What would we gain if we join all the constitutive models in one application but then each application is only compatible with a small portion of them?

[josep-m-carbonell]

"PfemSolids and the SolidMechanics the developers are the same person" This is not true. I have not implemented any of the ConstitutiveLaws in the PfemSolidMechanicsApp.

I do not understand your "technical" reasons. I'm sorry. Are you complaining about some lack of order or inconsistency in the applications of kratos?

About the compatibility. Not everything is not compatible with everything. What can we do?

[maceligueta]

I am sorry, @josep-m-carbonell , I will correct "PfemSolids and the SolidMechanics the developers are the same person" for "PfemSolids and the SolidMechanics the supervisor is the same person".

About technical reasons I mean that the Mohr-Coulomb's constitutive law (just an example that was implemented in PfemSolidsApp) is of general interest of many people that use the SolidsApp. However, it was written in a different application. A technical reason would be 'the constitutive laws in PfemSolids have an enriched API, which make all the CL's incompatible with the ones in SolidsApp'. The reason you provided (

Each developer has constitutive laws in their own applications

) in this case is more a personal decision than a technical decision. Unless I am missing something important. And that's why I asked at first:

For those of us who don't know the details, why are these CL in the PfemSolidMechanicsApplication instead of the SolidMechanicsApplication? Why are not all of them in the SolidMechanicsApplication?

By knowing a precise answer to this I might have a better understanding of the utility of joining all the Constitutive Models in one single application.

[josep-m-carbonell]

Well, I don't know if having constitutive laws in different applications is a personal or technical decision. The constitutive laws in the PfemSolidMechanicsApp are implemented for the use in a phd thesis, and this corresponds to a Lab application. Of course this application can use the constitutive laws implemented in the SolidMechanicsApp. Not all constitutive laws are compatible with all elements and this applies to both applications.

I do not propose to joint all constitutive laws to one application. I have just proposed to migrate the ones in the SolidMechanicsApp to a ConstitutiveModelsApp. I would like the people to contribute asking for new features and proposals for the new ConstitutiveModelsApplication.

Right now I got only posts which wander: mmm...." to be or not to be" that is the question.... . Unfortunately we are not going anywhere.

[vryy]

Dear @josep-m-carbonell , if you're considering new features for the new ConstitutiveModelsApplication, how about making a solid interface to commercial FEM program, i.e Abaqus (Umat/Vumat), Plaxis (UDSM), Marc/Mentat (Hypela2)? The current Umat interface in ConstitutiveLawsApplication needs some improvement. Do you think it's wise to keep it in the current ConstitutiveLawsApplication or merge them to new ConstitutiveModelsApplication.

[josep-m-carbonell]

Thank you @vryy for your comment. I think that when the interface to a commercial code or another external library (with particular importance if it is not open source) a particular treatment must be considered. In Kratos, I think, it is preferred to encapsulate these API features in separate applications. Perhaps an improved application for Umat with more descriptive name should be implemented. ConstitutiveLawsApplication is too general and does not describe correctly what is implemented inside, which is the interface to Umat. I think that other interfaces to commercial codes can be considered also to be implemented to extend capabilities.

[loumalouomega]

@vryy @josep-m-carbonell I didn't know about the UMAT "standard" (http://imechanica.org/files/Writing%20a%20UMAT_0.pdf), It looks very promising, I think that if we define an API compatible with this then could be interesting to have an specific application for the CL.

@RiccardoRossi I have been thinking that we can use AD for the definition of the Jacobian in implicit CL, we can take a look into that in a future

[GuillermoCasas]

Dear all, Interesting discussion. I have little experience with constitutive laws. My question is conceptual. How is an application containing the constitutive law concept an application at all? Why should all this not be moved to the kernel if indeed its scope is larger than SolidMechanicsApplication?

I know we have ExternalSolversApplication. But, in fact, I see it as an exception, which actually slightly abuses the intended use of the applications. Am I wrong?. Should applications not contain the information related to specific problems?

[josep-m-carbonell]

@GuillermoCasas you are right, a conceptual definition of what an "Kratos application" is or has to be, has not been considered at all. As engineers we usually go straight forward to the practical implementation of something we need and we have integrated it in the most suitable place to boost the performance, flexibility and the expand-ability of the code. Maybe the application of what is "conceptually correct" is not fitting exactly with the capabilities and performance we are looking for. We can survive without proving that 0=0.

[pooyan-dadvand]

You are right @GuillermoCasas , it make sense that if there are many (more than two) applications that should derive their classes from the one defined in constitutive law app. For example for ExternalSolversApplication you don't need to include them in your cpps and you can use the solvers directly in Python. For constitutive laws we added the base class to the core to avoid cpp dependency. This can be done also for yield or hardening classes if is necessary. In this way one can only import the other apps in order to use their constitutive laws without having compile time dependency.

[GuillermoCasas]

Thank you, that makes sense.