[DISCUSSION] MGISApplication: about material properties

[thelfer]

I create this thread for discussion about a possible new application called MGISApplication which aims at using MFront generated behaviours in Kratos though the MGIS projet (See http://tfel.sourceforge.net/ and https://github.com/thelfer/MFrontGenericInterfaceSupport for dietails). Developments are hosted in the mfront/integration branch.

[thelfer]

The application is based on two main classes:

• MGISConstitutiveLawFactory which loads an MGIS behaviour
• MGISConstitutiveLaw which implements a constitutive equation based on an MGIS behaviour loaded by the MGISConstitutiveLawFactory. This class automatically allocates the memory associated with the material properties, state variables and external states variables.

[thelfer]

About material properties

Once the constitutive law is built by the factory, I want to make some basic checks in the Check method. Indeed the behaviour member contains an MGIS behaviour object which contains the full description of the constitutive law. In particular, it contains the list of material properties which must be defined by the user and given to the constitutive law by Kratos.

So, I tried this:

    for (const auto& mp : this->behaviour->mps) {
      KRATOS_ERROR_IF(!rMaterialProperties.Has(mp.name))
          << "material property '" << mp.name<< "' is undefined\n";
    }

That does not work because the access operator [] of the Property class does not accept a std::string (here the name of the property).

Any idea of how to implement my idea properly ?

[loumalouomega]

Hi, I think what you try to do can be achieved with KratosComponents. The thing is that in order to do that we will need an auxiliar method, because there isn't only one type of Variable, we have variables for every type (class) possible. So for example, imagine you want to access "YOUNG_MODULUS", Young Modulus is a double variable. Therefore: ~~~cpp const Variable<double>& r_variable_young_modulus = KratosComponents<Variable<double>>::Get(" YOUNG_MODULUS "); ~~~ Of course in order to do this in general we will need an auxiliar method based on this procedure. I will detail it later when I have the time to develop my answer.

…

On Tue, 19 Nov 2019 at 16:04, thelfer ***@***.***> wrote: About material properties Once the constitutive law is built by the factory, I want to make some basic checks in the Check method. Indeed the behaviour member contains an MGIS behaviour object which contains the full description of the constitutive law. In particular, it contains the list of material properties which must be defined by the user and given to the constitutive law by Kratos. So, I tried this: for (const auto& mp : this->behaviour->mps) { KRATOS_ERROR_IF(!rMaterialProperties.Has(mp.name)) << "material property '" << mp.name<< "' is undefined\n"; } ~~~ That does not work because the access operator `[]` of the `Property` class does not accept a `std::string` (here the name of the property). Any idea of how to implement my idea properly ? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#5950?email_source=notifications&email_token=AEYQZADALVGNS5I53ME3U63QUP6ARA5CNFSM4JPEEB22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEOP6KI#issuecomment-555548457>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEYQZAF72EX5AJDSYHENS3LQUP6ARANCNFSM4JPEEB2Q> .

[thelfer]

@loumalouomega I am not sure that you completly understood my trouble: the name of the material properties are not known in advance: its defined on the MFront side and it is not known by Kratos. I need I purely dynamic mechanism. For the moment, I make this workaround:

    for (const auto& mp : this->behaviour->mps) {
      KRATOS_ERROR_IF(!rMaterialProperties.Has(Variable<double>(mp.name)))
          << "material property '" << mp.name << "' is undefined\n";
    }

[philbucher]

@thelfer what you describe I see a bit as an issue, since the Variables (Kratos-name) are created at compile time.

Maybe one solution could be a Variable of type std::unordered_map<std::string, double>. This way you would be completely flexible in the usage, but this would not be the best option in terms of performance

to explain myself a bit more:

// assuming you have created the variable `MIGS_MATERIAL_PROPERTIES 
// of type std::unordered_map<std::string, double>:

// accessing the values from inside your law:
const auto& migs_props = rMaterialProperties[MIGS_MATERIAL_PROPERTIES];

const double migs_strain_constant = migs_props["migs_strain_constant"];

[thelfer]

@philbucher That's more or less the spirit. But it would be nice to be consistent with native Kratos' constitutive laws for the end user point of view. I mean that I would like the user to specify a MGIS' material property using the same syntax that the one used to define the YOUNG_MODULUS in native laws.
(My understanding is that rMaterialProperties is more or less directly populated by the user in its input file)

[thelfer]

@thelfer what you describe I see a bit as an issue, since the Variables (Kratos-name) are created at compile time.

Well, that is is also what bothers me. The MGIS project has been created to allow the solver using it to solve arbitrary constitutive laws generated by MFront.

Just to be sure: is creating a Variable<double> on the fly to query the rMaterialProperty object an issue ?

BTW: are material properties uniform (spatially) and constant (in time) in Kratos ?

[loumalouomega]

@thelfer I will answer your questions tonight, I cannot do it right now

[philbucher]

brief answer, also don't have time now:

Just to be sure: is creating a Variable on the fly to query the rMaterialProperty object an issue ?

currently (master as of today) it is not possible but we are working on it => #2902

[loumalouomega]

Short answer to @philip_bucher. You can create variables on the fly, you cannot register them on the fly,

…

On Tue, 19 Nov 2019 at 18:03, thelfer ***@***.***> wrote: @thelfer <https://github.com/thelfer> what you describe I see a bit as an issue, since the Variables (Kratos-name) are created at compile time. Well, that is is also what bothers me. The MGIS project has been created to allow the solver using it to solve arbitrary constitutive laws generated by MFront. Just to be sure: is creating a Variable<double> on the fly to query the rMaterialProperty object an issue ? BTW: are material properties uniform (spatially) and constant (in time) in Kratos ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5950?email_source=notifications&email_token=AEYQZAHIHVT7CI7FCMC2Y2DQUQL73A5CNFSM4JPEEB22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEO6DVA#issuecomment-555606484>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEYQZAGE5OY5YH5RNJB6EUTQUQL73ANCNFSM4JPEEB2Q> .

[loumalouomega]

brief answer, also don't have time now:

Just to be sure: is creating a Variable on the fly to query the rMaterialProperty object an issue ?

currently (master as of today) it is not possible but we are working on it => #2902

Ok, I thought that was already merged :P

[loumalouomega]

@thelfer There is something I need to know in order to propose an alternative implementation considering the current variable definition. If I understood correctly what MGIS does is to convert the MFront law into an include and a library file. Then these two files can be used in the FEM code. It is possible to create a macro which detects all the incudes and adds the corresponding laws in compilation time?

This way we can define the variables and everything in compilation time. In fact this was my original idea for the MGIS application, but maybe you were thinking in something more dynamic and flexible.

[thelfer]

@loumalouomega I see that there is a deep misunderstanding about how MFront works and what MGIS does. Let me clarify.

MFront translates an input file into C++ sources for various solvers (Abaqus/Standard, Abaqus/Explicit, Code_Aster, etc..., In MFront wordings, we says that we provide an interface for those solvers) and compiles them into shared libraries which are meant to be loaded by the calling solver. This allows to completely separe the solver from the constitutive laws.

However, the number of supported solvers tends to grow and more and more developpers of solvers which did not provide support for external constitutive laws became interested by using MFront. I thus decided to create a so called generic interface and the MGIS project.

The MGIS project eases the support external constitutive laws generated through the generic interface. This is explained in this (yet to be published) paper: https://github.com/thelfer/MFrontGenericInterfaceSupport/blob/master/docs/papers/joss/paper.md

Thanks to MGIS, a solver can:

• load an external constitutive law, retrieve meta data (such as the behaviour type, the expected material properties, etc...)
• allocate the memory required to hold the data associated with the constitutive law (internal state variables for instance).
• integrate the constitutive law over a time step
• update or revert the data associated with the constitutive law. Update is done at the end of the time step. Revert is done in case of non convergence over a time step and the solver wants to restart the time step (possibly with a smaller time step).

One must understand that MGIS does not require any a priori knowledge about the loaded constitutive law. So everything is fully dynamic and this is what solver developpers usually want !

Another option would be to create a dedicated MFront interface for kratos that would generate native Kratos' constitutive laws and declare variables at compile-time. This is much more work for me and has lot of disadvantages. I would not recommend to do this. This would also be incompatible with the way I would want to use Kratos (the constitutive laws that I use summarize
years of studies on our materials and can't be shared).

Please discuss this carefully with @RiccardoRossi and other to see what is to most desirable for Kratos.

[loumalouomega]

@loumalouomega I see that there is a deep misunderstanding about how MFront works and what MGIS does. Let me clarify.

MFront translates an input file into C++ sources for various solvers (Abaqus/Standard, Abaqus/Explicit, Code_Aster, etc..., In MFront wordings, we says that we provide an interface for those solvers) and compiles them into shared libraries which are meant to be loaded by the calling solver. This allows to completely separe the solver from the constitutive laws.

However, the number of supported solvers tends to grow and more and more developpers of solvers which did not provide support for external constitutive laws became interested by using MFront. I thus decided to create a so called generic interface and the MGIS project.

The MGIS project eases the support external constitutive laws generated through the generic interface. This is explained in this (yet to be published) paper: https://github.com/thelfer/MFrontGenericInterfaceSupport/blob/master/docs/papers/joss/paper.md

Thanks to MGIS, a solver can:

* load an external constitutive law, retrieve meta data (such as the behaviour type, the expected material properties, etc...)

* allocate the memory required to hold the data associated with the constitutive law (internal state variables for instance).

* integrate the constitutive law over a time step

* update or revert the data associated with the constitutive law. Update is done at the end of the time step. Revert is done in case of non convergence over a time step and the solver wants to restart the time step (possibly with a smaller time step).

One must understand that MGIS does not require any a priori knowledge about the loaded constitutive law. So everything is fully dynamic and this is what solver developpers usually want !

Another option would be to create a dedicated MFront interface for kratos that would generate native Kratos' constitutive laws and declare variables at compile-time. This is much more work for me and has lot of disadvantages. I would not recommend to do this. This would also be incompatible with the way I would want to use Kratos (the constitutive laws that I use summarize
years of studies on our materials and can't be shared).

Please discuss this carefully with @RiccardoRossi and other to see what is to most desirable for Kratos.

Sorry if i confused the behaviours, certainly some time passed since the last time I look at the project and I did not remember the details. I certainly I remember that the we preferred the MGIS interface, we discussed this via mail at that time. In that case we need to discuss a way of proceed in order of being compatible. One dummy way of proceed would be to define in advance generic multi-purpose variables and assign a purpose in running time. For example: DUMMY_DOUBLE_VARIABLE_1, we will consider to be an alias to "young_modulus". This is certainly a mix of what @philbucher proposed but using at the Kratos database interface.

[thelfer]

I would not like the end user to see things like DUMMY_DOUBLE_VARIABLE_1 in its input file. I usually struggle for the end user to have explicit names in their input files to avoid dumb mistakes.

I would like to understand if creating Variable' object on the fly is completly a non sense in Kratos (see also my previous unanswered question).

Another option would also to completly discard standard Kratos mechanism. If you look at the MGISConstitutiveLawFactory::Create method, I have access to an object of type Kratos::Parameters from which I retrieve the names of the library and the behaviour... Maybe I could also get there the values of the material properties....

[loumalouomega]

I would not like the end user to see things like DUMMY_DOUBLE_VARIABLE_1 in its input file. I usually struggle for the end user to have explicit names in their input files to avoid dumb mistakes.

I understand completely, in any case the idea was to use an alias that would be what the suer will see. But i completely understand that this option is not a good alternative.

I would like to understand if creating Variable' object on the fly is completly a non sense in Kratos (see also my previous unanswered question).

@philbucher mentioned #2902, but now I see that that only affects the python interface. But from the C++ point of view you can define a variable on the fly, as the constructor is accessible as you can see in

Kratos/kratos/containers/variable.h

Line 88 in 7590973

Variable(const std::string& NewName, const TDataType Zero = TDataType())

. The thing is that variable will not be registered, and therefore not accessible from any part of the code. And in order to properly use the DataValueContainer you must work with the reference of the variable in order to avoid memory errors, as the DataValueContainer works directly with raw pointers

Kratos/kratos/containers/data_value_container.h

Line 78 in 7590973

typedef std::pair<const VariableData*, void*> ValueType;

.

I will ping here @pooyan-dadvand and @RiccardoRossi to think in practical ways of working with variables created on the fly.

Another option would also to completly discard standard Kratos mechanism. If you look at the MGISConstitutiveLawFactory::Create method, I have access to an object of type Kratos::Parameters from which I retrieve the names of the library and the behaviour... Maybe I could also get there the values of the material properties....

The thing is that the properties are shared between different elements and therefore the information that is "repeated" is stored just once, if you save a Parameters object in each CL in each GP that's a lot of memory. Again, I will ping @pooyan-dadvand and @RiccardoRossi, maybe we can a Parameters as part of the Properties (empty by default), this will add a lot of flexibility certainly, but changing that class requires a consensus in the @KratosMultiphysics/technical-committee

[loumalouomega]

Thinking more about the Parameters, we don't need to add it to the Properties, we can just add a Variables CUSTOM_PARAMETERS or something like that and store it in the properties directly

[thelfer]

@loumalouomega That is beyond my current knowledge of Kratos... I don't get what it implies in practice.

[loumalouomega]

Yes, I understand, sorry if I added to much information. I think that the most suited option would be the variable containing the Kratos::Parameters, that is simple and will provide the flexibility required. El mié., 20 nov. 2019 14:48, thelfer <[email protected]> escribió:

…

@loumalouomega <https://github.com/loumalouomega> That is beyond my current knowledge of Kratos... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5950?email_source=notifications&email_token=AEYQZACW72SXNHOD5LNV64TQUUN2NA5CNFSM4JPEEB22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEERVOQY#issuecomment-555964227>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEYQZADM2OVVMY5JGFUXW4DQUUN2NANCNFSM4JPEEB2Q> .

[thelfer]

Maybe I don't understand things correctly. But I already have access to the Kratos::Parameters in the factory class MGISConstitutiveLawFactory. This means that I can already extract the material properties there. So no need of a new variable, right ?

I also understand that this solution may not solve the following issues:

• material properties won't be shared with the rest of the code
• material properties won't be declared like the ones of native Kratos behaviours

[loumalouomega]

Maybe I don't understand things correctly. But I already have access to the Kratos::Parameters in the factory class MGISConstitutiveLawFactory. This means that I can already extract the material properties there. So no need of a new variable, right ?

I also understand that this solution may not solve the following issues:

* material properties won't be shared with the rest of the code

* material properties won't be declared like the ones of native `Kratos` behaviours

Exactly, doing this in the Create, I assume you will save all these values as internal values of the ConstitutiveLaw therefore repeating the same values in each GP, with the corresponding memory cost. Adding a variable for Kratos::Parameters will solve at least the first issue, the second one we will need to think a little more.

[thelfer]

What if I store the generator creates a shared_ptr of an object containing the material properties and the this shared pointer is shared in each CL ? That shoud somehow mitigate the memory loss, shouldn't it ?

Our discussion seems to implictly answer one of my previous questions: the material properties are, in Kratos, uniform (spatially) and constant (in time). That's not necessarily the case in other solvers (Cast3M, Code_Aster) that may use non constant and non uniform material properties to take into account the influence of (what we call in MFront) external state variables such as the temperature.

[loumalouomega]

What if I store the generator creates a shared_ptr of an object containing the material properties and the this shared pointer is shared in each CL ? That shoud somehow mitigate the memory loss, shouldn't it ?

Yes, that's basically what in theory can be achieved with this Parameters variable that will allow you to maintain the flexibility. Right now the CL does not store the Properties but the element, and the elements passes the properties to the CL.

Our discussion seems to implictly answer one of my previous questions: the material properties are, in Kratos, uniform (spatially) and constant (in time). That's not necessarily the case in other solvers (Cast3M, Code_Aster) that may use non constant and non uniform material properties to take into account the influence of (what we call in MFront) external state variables such as the temperature.

In Kratos we have different ways to tell that the material is not uniform across the space and time. This is done with the Tables, the tables define the dependency between two variables. (right now I do not remember if can be extended to multiple variable dependency, @pooyan-dadvand ?). The thing is that this is not automatic and the CL must implement the proper method in order to retrieve the current value depending of specific configuration that GP is dealing with.

[loumalouomega]

@philbucher do we have any example how to use the Table, I cannot find any right now

[philbucher]

@philbucher do we have any example how to use the Table, I cannot find any right now

I don't know, I am not using it

[loumalouomega]

@philbucher do we have any example how to use the Table, I cannot find any right now

I don't know, I am not using it

OK, I thought you have use it as you started the property accessor that at the end we discarded

[philbucher]

no, I ended up creating one prop/element, was easier for me

[loumalouomega]

Here there is an example: https://github.com/KratosMultiphysics/Kratos/blob/master/applications/DamApplication/custom_processes/apply_component_table_process.hpp

[pooyan-dadvand]

The tables are for two variables as you said. Here the main restriction is the IO rather than the table to be extended to more than two variables.

[thelfer]

If I may, I would make the following proposal. Let us say that I have a data structure called MGISBehaviourSharedData which is created by the factory and shared by all instances of the generated CL.

This data structure a vector of Kratos's Variable build as follows:

• if the name of the expected material property (MGIS side) matches the name of a Kratos' variable, use the latter. See my proposal to build a mapping between the TFEL' glossary and the Kratos' variables.
• if the name does not match the name of a Kratos' variable, create a variable on the fly.

Then, the only thing that I have to do is to use this vector to extract the values of the material properties.

This proposal has several benefits:

• It allows full flexibility
• Material properties are declared just like they are for native CL
• It is compatible with Kratos as much as it can be, meaning that if the CL expects the YoungModulus (as defined in the TFEL glossary), it will retrieve the value associated with the YOUNG_MODULUS Kratos' variable du to the mapping.
• This does not seem to be worse than anything else in terms of performances

Just make a quick check. It seems to work as expected.

The only drawback is the following: TFEL' glossary names are written in camel-case, which leads to a somewhat hybrid input file. Here is an example:

        "model_part_name" : "Structure.Parts_Solid_Auto1",
        "properties_id"   : 1,
        "Material"        : {
            "constitutive_law" : {
	        "name": "MGISConstitutiveLawFactory",
                "library" : "src/libBehaviour.so",
                "behaviour" : "Elasticity"
            },
            "Variables"        : {
                "DENSITY"       : 7850.0,
                "YOUNG_MODULUS" : 206900000000.0,
                "POISSON_RATIO" : 0.29,
                "NortonCoefficient": 8.e-67,
                "NortonExponent": 8.2
            },
            "Tables"           : {}
        }

I can live with it.

@loumalouomega, @RiccardoRossi How do you feel about it ?

[loumalouomega]

If I may, I would make the following proposal. Let us say that I have a data structure called MGISBehaviourSharedData which is created by the factory and shared by all instances of the generated CL.

This data structure a vector of Kratos's Variable build as follows:

* if the name of the expected material property (MGIS side) matches the name of a `Kratos`' variable, use the latter. See my proposal to build a mapping between the `TFEL`' glossary and the Kratos' variables.

* if the name does not match the name of a `Kratos`' variable, create a variable on the fly.

Then, the only thing that I have to do is to use this vector to extract the values of the material properties.

This proposal has several benefits:

* It allows full flexibility

* Material properties are declared just like they are for native CL

* It is compatible with `Kratos` as much as it can be, meaning that if the CL expects the `YoungModulus` (as defined in the `TFEL` glossary), it will retrieve the value associated with the `YOUNG_MODULUS` `Kratos`' variable du to the mapping.

* This does not seem to be worse than anything else in terms of performances

Just make a quick check. It seems to work as expected.

The only drawback is the following: TFEL' glossary names are written in camel-case, which leads to a somewhat hybrid input file. Here is an example:

        "model_part_name" : "Structure.Parts_Solid_Auto1",
        "properties_id"   : 1,
        "Material"        : {
            "constitutive_law" : {
	        "name": "MGISConstitutiveLawFactory",
                "library" : "src/libBehaviour.so",
                "behaviour" : "Elasticity"
            },
            "Variables"        : {
                "DENSITY"       : 7850.0,
                "YOUNG_MODULUS" : 206900000000.0,
                "POISSON_RATIO" : 0.29,
                "NortonCoefficient": 8.e-67,
                "NortonExponent": 8.2
            },
            "Tables"           : {}
        }

I can live with it.

@loumalouomega, @RiccardoRossi How do you feel about it ?

Looks like a good alternative, we will need to modify the utilities/read_materials_utility.cpp in order to skip variables and pass this variables to the MGIS variable wrapper somehow.

[thelfer]

Indeed. I naïvely made my test with a variable named a and it worked.
But if I use NortonCoefficient, it fails with the message:

RuntimeError: Error: Value type for "NortonCoefficient" not defined

[loumalouomega]

Indeed. I naïvely made my test with a variable named a and it worked.
But if I use NortonCoefficient, it fails with the message:

RuntimeError: Error: Value type for "NortonCoefficient" not defined

We can make some methods of utilities/read_materials_utility.cpp virtual, and create a derived version i.e. custom_utilities/read_materials_with_mgis_utility.cpp

[loumalouomega]

We can make some methods of utilities/read_materials_utility.cpp virtual, and create a derived version i.e. custom_utilities/read_materials_with_mgis_utility.cpp

Any other suggestions @RiccardoRossi ?

[RiccardoRossi]

It looks pretty clean to me.

as i understand the parsing of

"constitutive_law" : {
	        "name": "MGISConstitutiveLawFactory",
                "library" : "src/libBehaviour.so",
                "behaviour" : "Elasticity"
            }

is completely contained within the MGISConstitutiveLawFactory right? if so it looks more than fine to me!

[loumalouomega]

It looks pretty clean to me.

as i understand the parsing of

"constitutive_law" : {
	        "name": "MGISConstitutiveLawFactory",
                "library" : "src/libBehaviour.so",
                "behaviour" : "Elasticity"
            }

is completely contained within the MGISConstitutiveLawFactory right? if so it looks more than fine to me!

The thing is with the variables reading ...

[RiccardoRossi]

i agree with deriving a specialized reading_utility...

[philbucher]

Makes sende to me

[loumalouomega]

i agree with deriving a specialized reading_utility...

See #5986

[thelfer]

@loumalouomega would you help using this new feature ?

[loumalouomega]

@loumalouomega would you help using this new feature ?

Yep :D

[RiccardoRossi]

hello everyone, this morning i had an alternative, probably less intrusive idea about this:

what about doing?

        "model_part_name" : "Structure.Parts_Solid_Auto1",
        "properties_id"   : 1,
        "Material"        : {
            "constitutive_law" : {
	        "name": "MGISConstitutiveLawFactory",
                "library" : "src/libBehaviour.so",
                "behaviour" : "Elasticity",
                "mgis_variables" : {
                      "NortonCoefficient": 8.0e-67,
                      "NortonExponent": 8.2
                }
            },
            "Variables"        : {
                "DENSITY"       : 7850.0,
                "YOUNG_MODULUS" : 206900000000.0,
                "POISSON_RATIO" : 0.29,
            },
            "Tables"           : {}
        }

my point here is that the function Create of the CL is in charge of reading the "constitutive_law" block so one could implement in the factory the reading of the "mgis_variables" without having to do any modification in the reading utility.
My problem is not reall modifying the reading utility (that is a clean solution) however if you change that you will also have to change the strategies to take that into account...and that is starting to be less clean...

[RiccardoRossi]

note also that the solution i propose would cleanly separate "KratosVariable" (read automatically, and contained in the "Variables" block) from mgis_variables (read and stored in the factory)

[loumalouomega]

@RiccardoRossi the utility is already modified, both in the core and the application... El jue., 28 nov. 2019 7:34, Riccardo Rossi <[email protected]> escribió:

…

note also that the solution i propose would cleanly separate "KratosVariable" (read automatically, and contained in the "Variables" block) from mgis_variables (read and stored in the factory) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5950?email_source=notifications&email_token=AEYQZACBFXALH4UMVIQUL4LQV5Q5ZA5CNFSM4JPEEB22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFLS2WY#issuecomment-559361371>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEYQZAAHVPDSV7DFIZI3OOTQV5Q5ZANCNFSM4JPEEB2Q> .

[philbucher]

My problem is not reall modifying the reading utility (that is a clean solution) however if you change that you will also have to change the strategies to take that into account...and that is starting to be less clean...

This is a very valid point ...
Also then would be consistent with the laws that consist of multiple laws (if I am not mistaken)

[loumalouomega]

For now the solver has been updated in the branch to detect if the MGIS reader is available. In any case this can be reverted. Maybe we should discuss more the workflow before any additional movement. El jue., 28 nov. 2019 8:01, Philipp Bucher <[email protected]> escribió:

…

My problem is not reall modifying the reading utility (that is a clean solution) however if you change that you will also have to change the strategies to take that into account...and that is starting to be less clean... This is a very valid point ... Also then would be consistent with the laws that consist of multiple laws (if I am not mistaken) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5950?email_source=notifications&email_token=AEYQZAHNIQKQ6FSIWJJW5GDQV5UC5A5CNFSM4JPEEB22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFLUMHY#issuecomment-559367711>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEYQZAB7VRC6QP3ULI3JQNDQV5UC5ANCNFSM4JPEEB2Q> .

[thelfer]

hello everyone, this morning i had an alternative, probably less intrusive idea about this:

what about doing?

        "model_part_name" : "Structure.Parts_Solid_Auto1",
        "properties_id"   : 1,
        "Material"        : {
            "constitutive_law" : {
	        "name": "MGISConstitutiveLawFactory",
                "library" : "src/libBehaviour.so",
                "behaviour" : "Elasticity",
                "mgis_variables" : {
                      "NortonCoefficient": 8.0e-67,
                      "NortonExponent": 8.2
                }
            },
            "Variables"        : {
                "DENSITY"       : 7850.0,
                "YOUNG_MODULUS" : 206900000000.0,
                "POISSON_RATIO" : 0.29,
            },
            "Tables"           : {}
        }

my point here is that the function Create of the CL is in charge of reading the "constitutive_law" block so one could implement in the factory the reading of the "mgis_variables" without having to do any modification in the reading utility.

This was among the first proposals that we made. It has many advantages, but the main drawback here is that we introduce a significant difference between MFront behaviours and native ones, from the end user point of view. The other drawback is that we may not be able to use some Kratos features, like handling material properties dependencies with temperature (Though I still don't know how this words, sorry @loumalouomega, did not have the time to look this point so far)

Note that this is only my point of view, In the end, you, I mean Kratos' core developpers, will choose the best option.

My problem is not reall modifying the reading utility (that is a clean solution) however if you change that you will also have to change the strategies to take that into account...and that is starting to be less clean...

I am sorry, I got lost here and did not understand this point...

Note For what it's worth, this whole discussion gives me the feeling that many things could be simpler if the materia properties were passed to the Create method of the CL

[philbucher]

@thelfer no worries, we like to discuss abt implementational details ;)

just some clarifications:

My problem is not reall modifying the reading utility (that is a clean solution) however if you change that you will also have to change the strategies to take that into account...and that is starting to be less clean...

I am sorry, I got lost here and did not understand this point...

the changes in the workflow that are necessary to "nicely" integrate the reading for the migs utils is this one. This is a change quite deep in the code and should be considered carefully.

---

This was among the first proposals that we made. It has many advantages, but the main drawback here is that we introduce a significant difference between MFront behaviours and native ones, from the end user point of view.

this is a good point from the usability side, can you show an example of the current input (using the custom materials reading)?

Note For what it's worth, this whole discussion gives me the feeling that many things could be simpler if the materia properties were passed to the Create method of the CL

In principle I agree :) However this might come at a high price in terms of usability, hence I think it is worth considering both ways

---

The other drawback is that we may not be able to use some Kratos features, like handling material properties dependencies with temperature (Though I still don't know how this words, sorry @loumalouomega, did not have the time to look this point so far)

we don't have a "standard" solution for handling temperature dependent properties. However the most native way would be to define a table in the materials input (reading this is already there) and then use it in the CLaw. E.g. in the input you could define a table youngs modulus <=> temperature. In the CLaw when you need the youngs modulus, you would ask the table (input for it would be e.g. the nodal temperature which you can access from the CLaw)

[thelfer]

the changes in the workflow that are necessary to "nicely" integrate the reading for the migs utils is this one. This is a change quite deep in the code and should be considered carefully.

I admit that this is not really satisfactory (sorry @loumalouomega)

[RiccardoRossi]

Yes, i did not realize that that would be needed otherwise i would have made the comment before spending effort...sorry about this.

The problem with passing variables in the create is that there are cases in which elements do not have a CL. Think for example to a purely thermal element.

Regarding the Create, we need to verify if the Variables are read before or after the Create is called. If they are called before (or if we agree on calling them before) than in the create method we could loop over the properties and simply do in there the same thing we would be doing in the ReadUtility

[loumalouomega]

Well, I certainly don't know the best option, which probably means a compromise solution

[thelfer]

we don't have a "standard" solution for handling temperature dependent properties. However the most native way would be to define a table in the materials input (reading this is already there) and then use it in the CLaw. E.g. in the input you could define a table youngs modulus <=> temperature. In the CLaw when you need the youngs modulus, you would ask the table (input for it would be e.g. the nodal temperature which you can access from the CLaw)

To be sure. Does that mean that if the young_modulus is temperature dependent, then it would not be defined in the Variables part of the input file.

Saying it in another way, does the Variables part of the input file allows to define only constant (in time) and uniform (spatially) material properties ?

[RiccardoRossi]

yes, Variables are constant in time and space (they are unique within a property and the property is shared within lots of elements).

You can compose materials by using subproperties (a cool recent contribution by @loumalouomega ), but i don't think this is what you are asking.

if you want something to be spatially variable you need to recover it from the nodes (which is one of the reasons for which we gave access to the geometry from within the CL)

for accessing a table you need to do something on the line of (writing out of my mind i need to check the exact syntax)

auto& table = pprop->GetTable(YOUNG_MODULUS)

double current_temperature = ... here for example get temperature from the nodes
double value = table[ current_temperature ];

[thelfer]

@RiccardoRossi Ok, this could change a lot of things in my implementation.

This are the kind of things which distinguishes solvers: in Abaqus, material properties are constant and uniform, whereas Cast3M and Code_Aster allows non uniform and time varying material properties.

In the MGISApplication, not knowing what Kratos supports, I have choosen tostore the material properties in two continuous array of values which is passed to the MFront implementation (one for the beginning of the time step, one for the end of the time step) per integration points. This is potentially a huge memory loss for values which are constant and uniform... It can also be a performance issue, since I fill thoses arrays from Kratos' variables at each mechanical iterations (at each integration points...).

If I had access to the material properties in the Create function, I could create one single continuous array of material properties for the beginning and the end of the time step for all the integration points.

Note I don't think that the support of non uniform and varying material properties through Kratos' tables is required for MGISApplication: we currently have all the tools on the MFront side to make it cleanly without relying on the solver abilities. However, to do this, I need to retrieve so called "external state variables" which are defined in MFront as state variables which evolves independently of the mechanics. Typically the temperature, but also the moisture concentration, the chemical composition. This will be the topic of a dedicated issue, once this one is closed !

[loumalouomega]

yes, Variables are constant in time and space (they are unique within a property and the property is shared within lots of elements).

You can compose materials by using subproperties (a cool recent contribution by @loumalouomega ), but i don't think this is what you are asking.

if you want something to be spatially variable you need to recover it from the nodes (which is one of the reasons for which we gave access to the geometry from within the CL)

for accessing a table you need to do something on the line of (writing out of my mind i need to check the exact syntax)

auto& table = pprop->GetTable(YOUNG_MODULUS)

double current_temperature = ... here for example get temperature from the nodes
double value = table[ current_temperature ];

#5962

[pooyan-dadvand]

A very interesting discussion also for @KratosMultiphysics/altair side.

Note For what it's worth, this whole discussion gives me the feeling that many things could be simpler if the material properties were passed to the Create method of the CL

I agree with @thelfer about this. IMO, passing the data to CL by properties variables is arriving to its limits.