Adding Subproperties to a given property

[RiccardoRossi]

Hello everyone, discussing with @frastellini we were thinking that it would be good to have a concept of "SubProperties" hanging to a given property.

this would allow an easier implementation for "rule-of-mixture" constitutive laws.

my idea would be to allow something like

  prop = model_part.Properties[1]

  #properties for plastic constitutive law - group 1
  prop.GetSubProperties[1][YOUNG_MODULUS]

  #properties for elastic constitutive law - group 2
  prop.GetSubProperties[2][YOUNG_MODULUS]

so that one could apply two different young modulus (say a plastic one and an elastic one) when combining two differen constitutive laws in defining a "composite" ConstitutiveLaw which combines them say in parallel

that is

    "constitutive_law": {
        "name": "GeneralParallelConstitutiveLaw"
                           "ConstitutiveLaw1" : {
                                 "name": "PlasticConstitutiveLaw",
                                 "SubProperttyIndex" : 1
                            }
                            "ConstitutiveLaw2" : {
                                "name": "DamageConstitutiveLaw"
                                "SubProperttyIndex" : 2
                            }
                            "combination_factor_1" : 0.3,
                            "combination_factor_2" : 0.7
        },

[loumalouomega]

We can discuss in which way we store this subproperties, the idea should be to follow the same structure of the submodelparts?, or taking into account that the properties are identified using ids in order to create a "cheaper" way to store the subs?

[maceligueta]

I have also been thinking about the "rule-of-mixture", and talked about it with @AlejandroCornejo . @RiccardoRossi : with this design, are the subproperties really contained in the parent properties? Or are they just pointed? I am thinking of mixtures of: concrete/steel1, concrete/steel2, concrete/steel3,... do we need copies of 'concrete' inside each Properties? Isn't it better to have a flat structure of actual Properties where materials can be pointed?

[RiccardoRossi]

I think that they should be really contained and not just pointers to somewhere else. otherwise we get a big ownership mess...

[RiccardoRossi]

i think it is imporant to revive this. @loumalouomega @frastellini @AlejandroCornejo @ipouplana @philbucher @KratosMultiphysics/technical-committee

[philbucher]

I guess with the ownership we should follow the same approach as with the ModelParts...

[frastellini]

Yes to @philbucher. We are having that idea in mind.

[frastellini]

I attach three files with alternatives for json structure design. I prefer option 01. Pay a look to the subproperties definition groups. I labeled with indexes 11,12,13 as an example. Pay also a look to composite constitutive law using those subproperties...

StructuralMaterials_COMPOSITE_CLS_Options.zip

[frastellini]

Note also that "model_part_name" was not included inside the subproperties definitions, since this may be inherited from the property object.

[philbucher]

I need some more time to process this, I hope you don't mind :) Overall I don't see major conflicts some questions:

• can you explain a bit more the combination_factor?
• Does accessing the ConstLaw from the elements change?
• It seems like the change is backward-compatible, is this so?

In general, I think this is in some way similar to #2349 (which I really have to do asap, reminder to myself)

[frastellini]

Of course, take the time you need. The main objetive of this discussion thread is to propose and justify the need of creation of subproperties objects, to be employed in new composite constitutive laws that requires the mixing of materials in a certain proportion (or volume fraction).

• a better name for combination_factor would be volume_fraction, that indicates the propotion of a certain material inside a composite (let's say volume fraction of glass fibres). It may be informed in terms of percentage of volume content.
• the way that element access to the composite CL do not change. The new composite CL should be called in same way it is done now with homogenous CLs.
• the addition of subproperties must be fully backward-compatible. The new subproperty objects would allow the definition of many components materials (e.g. matrix, glass and carbon fibres).
• there are many constitutive laws for composites that we plan to implement.

The non-linear behaviour of a composite is derived from the appropriate composition of the non-linear behaviour of the component materials laws. The simpler law is called "rule of mixtures" (all materials in parallel) where the same strain is applied to all materials. On the other hand we have the "inverse rule of mixtures" (all materials in serie) where same stress is obtained for each material. There are more complex CLs for composites that combines the serial-parallel behaviour that complies with both restrictions: e.g. same strain in fibre direction, and same stress in transverse directions, such as in Rastellini et al (2008)*.

• F Rastellini, S Oller, O Salomón, E Oñate, (2008) "Composite materials non-linear modelling for long fibre-reinforced laminates: Continuum basis, computational aspects and validations". Computers & Structures 86 (9), 879-896.

[philbucher]

thanks @frastellini ! I just want to think abt it for some days, not too long

In fact I am quite interested in the composite laws, since I am using the existing one already (the orthotropic law in StructuralMechanics)

What you propose seems reasonable Have you thought abt how you would define a layered composite? From what I understand you describe how you would set up one layer (e.g. matrix-fiber)

The multi-layer settings turned out to be rather difficult to handle in my cases

[frastellini]

The idea is that the subproperties could allow not only single layer composite but also multi-layered settings. Of course, the layered scheme should be managed by the section at element level, in case of shell elements. Aditionally, a 3D solid element may prefer to work with multi-layer at CL level ( all layers homogenized at each integration point). I will think in a proposal considering the multi-layer capability.

After being talking with @RiccardoRossi and @pooyan-dadvand, I will work on a proposal for the subproperty object, under their supervision.

[RiccardoRossi]

to give my two cents, i would go for option1.

As a minor detail i think that the tag should be "properties_id" even for the subproperties so that the reading is identical

[philbucher]

Option 1 is also what I would choose

The only thing I think should be improved is that the Variables have assigned null for the values that are computed by the subprops. This is redundant and can be confusing Hence I would remove it and compute it (i.e. compute e.g. THICKNESS from the subproperties and not defining it at all in the parent-properties) Here is what I mean:

"properties" : [{
    "model_part_name" : "Parts_Shell",
    "properties_id"   : 1,
    "Material"        : {
        "constitutive_law" : {
            "name" : "GeneralParallelConstitutiveLaw",
            "sub_properties_indexes"   : [ 11,  12,  13 ],
            "combination_factors"      : [0.4, 0.3, 0.3 ],
            "material_rotation_angles" : [ 0,   45,  90 ],
            "other_features..."        : [null,null,null]
        },
        "Variables"        : {
            "SOME_OTHER_VAR" : 555.1 # this does NOT come from the SubProps
        },
        "Tables"           : {}
    },
    "sub_properties" : [{
        "sub_properties_id"   : 11,
        "Material"        : {
            "constitutive_law" : {
                "name" : "HyperElastic3DLaw"
            },
            "Variables"        : {
                "THICKNESS"     : 0.000889,
                "DENSITY"       : 7850.0,
                "YOUNG_MODULUS" : 206900000000.0,
                "POISSON_RATIO" : 0.29
            },
            "Tables"           : {}
        }
    },{
        "sub_properties_id"   : 12,
        "Material"        : {
            "constitutive_law" : {
                "name" : "LinearElastic3DLaw"
            },
            "Variables"        : {
                "THICKNESS"     : 0.000889,
                "DENSITY"       : 7850.0,
                "YOUNG_MODULUS" : 206900000000000.0,
                "POISSON_RATIO" : 0.0
            },
            "Tables"           : {}
        }
    }

In a preprocessing step then THICKNESS and the others coming from the SubProperties should be computed according to how the laws are combined and then added to the Properties

@RiccardoRossi @pooyan-dadvand another thought: If this is done already, will subsubproperties also be possible, same as subsubModelParts? I guess it would make sense ... => From what I can see the SubPropserites are a regular Properties object anyway right?

[frastellini]

I agree with @RiccardoRossi and @philbucher Just one comment about the variables stated as null in the composite material definition: I though that may be is a good idea to explicitly define them even-though they must be autocalculated by the composite model in terms of the subproperties variables. I proposed this explicit definition of "null" variables that should be calculated by the composite, because not all the component variables (from subproperties) will have an equivalent at the composite level. For example, a damage variable cannot be mixed with a plastic variable.

[loumalouomega]

Ok for me with @philbucher proposal

[ipouplana]

Ok for me too

[josep-m-carbonell]

I think that in the definition of the Materials.json and in the sub-properties proposal, you are mixing two different things that internally in kratos have different owners and are used in different places. One thing is the "constittutive law object" and another the "properties object". Even more, where do you want to store and pass this information?

            "combination_factors"      : [0.4, 0.3, 0.3 ],
            "material_rotation_angles" : [ 0,   45,  90 ],
            "other_features..."        : [null,null,null]

I agree with @maceligueta that a plain structure is better and then create a definition of how to combine this plain structure.

[RiccardoRossi]

this combination information will be stored in the constitutive law. This way the $Create$ of the constitutive law will parse this information and store it as needed.

Regarding the use of subproperties vs a flat structure, we have been discussing this at length also with @pooyan-dadvand and we are strongly against the flat structure since it introduces an ownership mess, which is nicely avoided by the subproperties structure

[josep-m-carbonell]

Then if I have understood correctly, your plan is to change or add a new "non-standard" create method for passing these extra parameters. I don't know if is so "nicely" avoided, if you have to repeat the same material several times in the json file. As far as I know the properties ownership is currently a mess, they belong to modelparts and submodelparts independently. Maybe, if some order is put on this, this "strongly against" condition turns to a milder one.

[frastellini]

@loumalouomega and me are working on a proposal for subproperties. We will let you know soon, for your kind consideration.

[maceligueta]

Just for my understanding, @RiccardoRossi , what do you mean as 'ownership mess'?

[RiccardoRossi]

@maceligueta let's consider that we go for a flat design and let's just have a look to a simple example, in which we add properties 1 2 3 to a given modelpart.

now we store in property 1 a combined constitutive law (CL), which internally needs properties 2 and 3.

A CL has no access (nor should have due to layering consideration) to a modelpart or to its property list, hence the only way properties could be combined is to pass Pointers to the properties 2 and 3 through the constructor of the CL in 1. This implies that since Prop1 has a pointer to CL and CL holds pointers to 2 and 3, then in a way property 1 "owns" (read keeps alive) property 2 and 3, without you having any way to know about it... this is what i would define as an "owneship mess".

Aside of this, going the flat way also has some other disadvantages, for example 1 - the CL create function needs to know of the modelpart, and hence deal composite CLs as a special case. This is not needed if the Create(Kratos::Parameters settings) function is used, since a given new constitutive law can implement its specific behaviour as needed (and without needing access to the Properties array!) 2 - if you go with the flat approach, you'll have to store pointers to "sub" properties on each CL instance. Hence once per every gauss point! 3 - things will get WAY more complicated with the flat approach if you try to nest more than one level , say something like ParallelLaw( Elastic, ParallelLaw( Damage , Plastic ) )

on a side note, if there currently are inconsistencies in the Property behaviour than it is a bug. @josep-m-carbonell please write a test for it and we'll fix it ...

[maceligueta]

Probably I dedicated much less time to this than you guys, sorry... but I now I see where the complexity is: the CL and the Properties are starting to blend already. I mean: a certain composition of materials can be seen just as a 'description', which can be used by CLs to deduct the constitutive tensor or by other objects to deduct the permeability or the thermal conductivity. Let's be cautious with this. The CL should be able to use information from the composite Properties, including there all those characteristics that can be also used by other multyphisics problems. Actually, I was really surprised that the CL came into play when talking about how to identify and save materials (properties) in memory.

[loumalouomega]

You can look at @frastellini and I proposal at #2919

[loumalouomega]

We are doing the classic MixtureRule to show as example that it works

[pooyan-dadvand]

@maceligueta I see your point on this problem. Actually the current design is a incremental build over legacy conditions and I'm not sure if I would arrive to the same design again from the scratch.

In Kratos we used to have Properties as a plain data structure and give the formulation to the element. Then after some years comes CL in structural application which should be given to element from user. Nevertheless on that time the input reader was a complicated object and passing a new object to element was difficult, so we choose to pass it by properties and use it in element by cloning. Nevertheless on that time we have mixed up two different concepts which are Material models and Gauss point data containers in one object making the situation more complicated. We have tried to improve the situation several times since then but the result is not as optimum as it should be. I should add that there two facts that make this design more difficult: The CL is optional in element and there are very interdependent.

Designing it again I would have derived the MaterialLaw from Properties with all data and functions (like properties accessors) in it. (Considering that they are already blending as @maceligueta mentioned) Then I would add only one CLData which holds all gauss point related data in it (This gives the freedom to store some variables once instead of per each gauss point). Of course @RiccardoRossi and the rest of the @KratosMultiphysics/structural-mechanics team would have better sight of this problem and would come with several comments or criticism about my point of view but IMO the current design is not the best one.

[josep-m-carbonell]

@pooyan-dadvand. The @KratosMultiphysics/solid-mechanics and @KratosMultiphysics/constitutive-models teams just want to point here that properties is not an exclusive object of the Constitutive Law.

[pooyan-dadvand]

I see, and for this reason we are bounded to legacy.

Just to add that in current situation, I am in favor of sub properties as they are a clean way of extending to new capability without breaking the backward compatibility.

[loumalouomega]

2919 is 100% retrocompatible

[josep-m-carbonell]

I am sorry but I can not see in any of your explanations a clear answer to @maceligueta that asked why a plain structure is not better? It can be also retro-compatible and clean.

[pooyan-dadvand]

The answer of @RiccardoRossi is correct. In short, it creates cross pointers between CL and Properties which make the memory management more tedious.

And I personally see the hierarchical one a cleaner solution than a soap of properties and CLs....

[loumalouomega]

We can move the discussion to #2919, that way we can close this issue

[loumalouomega]

Can we move the discussion to #2919 and continue the discussion there.