Use different properties in multi-stage simulations #9128

ddiezrod · 2021-09-15T10:55:01Z

We have to deal currently in @KratosMultiphysics/altair side with a design problem in our casting solver. We do multi-stage computations so we can for example do filling + thermomechanical simulation. The problem is that the constitutive law is defined in the material.json and it is unique, although of course, it should be different in each stage.

I know that on the public side nobody is doing multi-stage simulations so you could think this is not a problem yet, However, I understand that this will become a problem in the near future for more and more people so I'd like to open the debate as its always better to think about these things in advance.

I don't have a strong opinion now, but my first thought is that maybe constitutive law has more in common with element formulation than with material properties, so perhaps the most evident solution would be to specify it in the solver settings as we do for "element_name" and "condition_name" instead of defining it in the material.json.

All comments are welcomed, please, share your thoughts.

ddiezrod · 2021-09-15T10:55:24Z

@KratosMultiphysics/all As i think this involves pretty much everyone

AlejandroCornejo · 2021-09-15T11:42:16Z

Hi @ddiezrod ! It is indeed a good question. I do not fully understand the problematic or the current limitation of the Kratos approach, could you elaborate? :D

Generally, the element is the one in charge of computing the kinematics of the problem and, once you have a measure of the strain/F, you integrate the stress via a CL (which can evolve along time). What is the additional feature that you need?
Regards

loumalouomega · 2021-09-15T11:45:39Z

@ddiezrod maybe we can update the reading process so it can read multistage materials, because the alternative would be to make CL multistage, and I think it is easier to tackle this from the point of view of the properties (with maybe some communication process between stages, to transfer information from a previous stage to the next one)

Vahid-Galavi · 2021-09-15T11:50:39Z

Hi @ddiezrod, we also do multistage calculation in Geomechanics application. In geomechacical problems, we switch between constitutive laws from one stage to another. In order to overcome the issue that you mentioned, we are storing stresses and state variables in the element. In the beginning of each stage, we initialize constitutive laws with these values using set functions. However, this is not the best solution. I think there must be an external mechanism which allows for multistage calculation and bringing stresses and state variables from one stage to another because then we can also change elements, if needed.

loumalouomega · 2021-09-15T11:52:11Z

Hi @ddiezrod, we also do multistage calculation in Geomechanics application. In geomechacical problems, we switch between constitutive laws from one stage to another. In order to overcome the issue that you mentioned, we are storing stresses and state variables in the element. In the beginning of each stage, we initialize constitutive laws with these values using set functions.

A priori if we agree in an interface we can do those transfer in a standard and unified manner

rubenzorrilla · 2021-09-15T12:15:04Z

Note that associating the constitutive law to the properties makes possible to define more than one constitutive model at the same time. The current solver design makes this impossible so we would require to modify the material_import_settings.

Having said this, I think that the question is, do we want one materials file for each stage simulation (I'd say no) or no? If this is the case we should probably change the material import settings to map one property to one constitutive law.

loumalouomega · 2021-09-15T12:16:26Z

Note that associating the constitutive law to the properties makes possible to define more than one constitutive model at the same time. The current solver design makes this impossible so we would require to modify the material_import_settings.

Having said this, I think that the question is, do we want one materials file for each stage simulation (I'd say no) or no? If this is the case we should probably change the material import settings to map one property to one constitutive law.

Basically what I said + a post stage transfer process

ddiezrod · 2021-09-15T12:35:15Z

Hi @ddiezrod ! It is indeed a good question. I do not fully understand the problematic or the current limitation of the Kratos approach, could you elaborate? :D

Generally, the element is the one in charge of computing the kinematics of the problem and, once you have a measure of the strain/F, you integrate the stress via a CL (which can evolve along time). What is the additional feature that you need?
Regards

Hi @AlejandroCornejo, the problem is that you have two stages that require different constitutive law but right now it is only defined in one place: material.json which is common for all stages (right now)

ddiezrod · 2021-09-15T12:43:13Z

Having said this, I think that the question is, do we want one materials file for each stage simulation (I'd say no) or no?

@rubenzorrilla So you mean that you want to have one unique material file for all stages? How would you solve the problem then? Maybe what you meant was the other way around.

I agree with your points @loumalouomega, probably that's the correct way to proceed. We had some opposition to go in this direction inside Altair as some people argued that material properties are unique and should not change from one stage to the other. That's why I suggested this other approach, but I think what @rubenzorrilla mentions is a real blocker, we must be able to use different CLs in our computing model part.

ddiezrod · 2021-09-15T12:44:52Z

Hi @ddiezrod, we also do multistage calculation in Geomechanics application. In geomechacical problems, we switch between constitutive laws from one stage to another. In order to overcome the issue that you mentioned, we are storing stresses and state variables in the element. In the beginning of each stage, we initialize constitutive laws with these values using set functions. However, this is not the best solution. I think there must be an external mechanism which allows for multistage calculation and bringing stresses and state variables from one stage to another because then we can also change elements, if needed.

thanks @Vahid-Galavi for your comment. Just out of curiosity, how do you define right now which CL is used in each stage?

RiccardoRossi · 2021-09-15T12:46:52Z

my comment about this is that material properties and constitutive laws are intimally related one to the other. having said this i am perfectly positive in having different material properties per each stage...

…

On Wed, Sep 15, 2021 at 2:45 PM Daniel Diez ***@***.***> wrote: Hi @ddiezrod <https://github.com/ddiezrod>, we also do multistage calculation in Geomechanics application. In geomechacical problems, we switch between constitutive laws from one stage to another. In order to overcome the issue that you mentioned, we are storing stresses and state variables in the element. In the beginning of each stage, we initialize constitutive laws with these values using set functions. However, this is not the best solution. I think there must be an external mechanism which allows for multistage calculation and bringing stresses and state variables from one stage to another because then we can also change elements, if needed. thanks @Vahid-Galavi <https://github.com/Vahid-Galavi> for your comment. Just out of curiosity, how do you define right now which CL is used in each stage? — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#9128 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5PWELMKCVNF73PZZQSLHDUCCINBANCNFSM5ECFE2PQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

rubenzorrilla · 2021-09-15T12:47:18Z

Having said this, I think that the question is, do we want one materials file for each stage simulation (I'd say no) or no?

@rubenzorrilla So you mean that you want to have one unique material file for all stages? How would you solve the problem then? Maybe what you meant was the other way around.

I agree with your points @loumalouomega, probably that's the correct way to proceed. We had some opposition to go in this direction inside Altair as some people argued that material properties are unique and should not change from one stage to the other. That's why I suggested this other approach, but I think what @rubenzorrilla mentions is a real blocker, we must be able to use different CLs in our computing model part.

That's precisely my point. I think that the best solution, also from user perspective, is to have a unique materials file for al the stages. This contains all the material properties, although some of them might not be used in some of the simulation stages. Then we edit the material_import_settings (as @loumalouomega also suggested) to map each property to its corresponding constitutive law. Note that this makes possible to have more than one constitutive model at the same time while also makes possible to change it depending on the simulation stage as it is at the solver_settings level.

rubenzorrilla · 2021-09-15T12:51:31Z

In any case, I think we should first decide if

A: We want one materials.json per stage (this would completely avoid the problem)
B: We want a single materials.json per all the stages. Note that for this we would be assuming that the model parts structure is always the same, which is something that we might want to avoid...

loumalouomega · 2021-09-15T12:54:49Z

* A: We want one materials.json per stage (this would completely avoid the problem)

KISS

* B: We want a single materials.json per all the stages. Note that for this we would be assuming that the model parts structure is always the same, which is something that we might want to avoid...

I don't think that, if we define an interface to identify stages that would be unnecessary

RiccardoRossi · 2021-09-15T12:56:48Z

I am much in favor that (optionally) one per stage rather than a single one with multiple stages.

and i would be in favour of defaulting to having a single one for all of the stages as happens now

ddiezrod · 2021-09-15T12:59:52Z

@rubenzorrilla Could you please write very schematically how the material.json file would look like if we keep using only file for all stages?

In principle, it seems to be that having multiple material files should solve the problem quite efficiently. Maybe we should have something like "main_material.json" (bad name) that contains the properties that will not change throughout the whole process and then each file stage_materia.json will "override" the properties of the main one.

loumalouomega · 2021-09-15T13:01:21Z

@rubenzorrilla Could you please write very schematically how the material.json file would look like if we keep using only file for all stages?

In principle, it seems to be that having multiple material files should solve the problem quite efficiently. Maybe we should have something like "main_material.json" (bad name) that contains the properties that will not change throughout the whole process and then each file stage_materia.json will "override" the properties of the main one.

I have a question, how do you identify stages?

rubenzorrilla · 2021-09-15T13:03:44Z

@rubenzorrilla Could you please write very schematically how the material.json file would look like if we keep using only file for all stages?
In principle, it seems to be that having multiple material files should solve the problem quite efficiently. Maybe we should have something like "main_material.json" (bad name) that contains the properties that will not change throughout the whole process and then each file stage_materia.json will "override" the properties of the main one.

I have a question, how do you identify stages?

I think that we will need to name MaterialsStage1.json, MaterialsStage2.json and so on. Then each one is called in the corresponding solver_settings. So the pre should take care of this.

rubenzorrilla · 2021-09-15T13:08:06Z

@rubenzorrilla Could you please write very schematically how the material.json file would look like if we keep using only file for all stages?

Would look as it is right now but without constitutive laws. In the properties you'll need to add all the material parameters that you'll require during the simulation (e.g. for a first thermal stage followed by a mechanical one you'll have CONDUCTIVITY and YOUNG_MODULUS in the same materials.json).

In principle, it seems to be that having multiple material files should solve the problem quite efficiently. Maybe we should have something like "main_material.json" (bad name) that contains the properties that will not change throughout the whole process and then each file stage_materia.json will "override" the properties of the main one.

I think that using multiple materials files would imply no changes in what we have so far. Only the preprocess writing needs to be changed. If we decide to go in this direction, I don't see the point on having the global materials file you suggest.

loumalouomega · 2021-09-15T13:18:03Z

@rubenzorrilla Could you please write very schematically how the material.json file would look like if we keep using only file for all stages?
In principle, it seems to be that having multiple material files should solve the problem quite efficiently. Maybe we should have something like "main_material.json" (bad name) that contains the properties that will not change throughout the whole process and then each file stage_materia.json will "override" the properties of the main one.

I have a question, how do you identify stages?

I think that we will need to name MaterialsStage1.json, MaterialsStage2.json and so on. Then each one is called in the corresponding solver_settings. So the pre should take care of this.

I was wondering if there was some procedure, and some identification or ID

ddiezrod · 2021-09-15T13:18:48Z

I think that using multiple materials files would imply no changes in what we have so far. Only the preprocess writing needs to be changed. If we decide to go in this direction, I don't see the point on having the global materials file you suggest.

The point is that then many of your material properties will be repeated in all the files, for example, the density. Having the same thing defined multiple times seems like a problem to me, especially if you want to modify its value in the file later.

rubenzorrilla · 2021-09-15T13:34:44Z

I think that using multiple materials files would imply no changes in what we have so far. Only the preprocess writing needs to be changed. If we decide to go in this direction, I don't see the point on having the global materials file you suggest.

The point is that then many of your material properties will be repeated in all the files, for example, the density. Having the same thing defined multiple times seems like a problem to me, especially if you want to modify its value in the file later.

And chances are that you forget to modify one of the files so you end up repeating the simulation because of this. This would definitively be an advantage of having a unique materials file.

RiccardoRossi · 2021-09-15T13:37:58Z

I really think that the CL belongs in the material properties...

ddiezrod · 2021-09-15T13:44:18Z

And chances are that you forget to modify one of the files so you end up repeating the simulation because of this. This would definitively be an advantage of having a unique materials file.

or a common "base" material.json that is overridden with each stage material file :P

Vahid-Galavi · 2021-09-15T14:56:03Z

Hi @ddiezrod, in Kratos we can define ProjectParameters.json per stage. In each ProjectParameters.json file, we can define a different material parameters JSON file. So, we can perfectly use and define different CLs and material parameters per stage. This is simply possible in Kratos. There are already some examples in the app, if you are interested.

Vahid-Galavi · 2021-09-15T15:01:14Z

In my opinion the current implementation is fine. There is only a mechanism is missing to transfer data of CLs from one stage to another. Element is not the right place. I fully agree with Riccardo that the CL should be a part of material properties.

pooyan-dadvand · 2021-09-15T15:22:16Z

I also think like @RiccardoRossi that the material and CL are very related. And even the same material needs different data for different CL in different stages (like aluminum in filling and cooling stages of Casting) but I think we can modularize it in a different way:
Materials.json : holds material name and its data/tables (like density, Young modulus, etc.)
MaterialLaws.json: Which defines the CL to use and each CL can use one (or more) material from material.json
Interfaces.json Which holds the models in the interfaces (like radiation, friction, surface tension, etc.) That uses two materials to define the interface relation (This is from another discussion I had with @maceligueta)

Obviously we can have all of them in one Properties.json which has the materials, material_laws and interfaces sections

sunethwarna · 2021-09-16T09:46:25Z

about the "include" mechanism, i would love to have the capability, however i am not clear on how it would work at the level of the KratosParameters object

So, first we read it usual ay without any problems (at the ctor). Then we recursively check for string parameters starting with "#include", if found, then the file is read, and replaced with the KratosParameters object from the file. Will there be any problems with this approach?

RiccardoRossi · 2021-09-16T09:50:36Z

@sunethwarna how would the syntax be?

note that if you add a special keyword to the RHS (to the ones of type string) than you will need to parse any string RHS in search of this special keyword and this would add a lot of overhead on the top of current implementation.

if it is done on the user side the overhead would be much smaller

sunethwarna · 2021-09-16T10:00:50Z

Ok I see two possibilities,

doing the replacement as a preprocessor to KratosParameters (can be easily done in python with just replacements)
Then its user's decision to use this or not, we can create a small python utilitiy to do this. So overhead is only if required.
Doing it at the Ctor of KratosParameters.
This will always check for strings, it is an overhead. In order to keep the overhead minimum, then we can do this recursive string search in the std::string ctor only. (not doing this on copy, move ctors, because if they are used, then we can assume the passed KratosParameters are already created at one point with std::string ctor.

We also can put the same non-recursive seach with KratosParameters::SetString method as well.

sunethwarna · 2021-09-16T10:02:27Z

@sunethwarna how would the syntax be?

{
     "some_string": "#include file_name.json"
}

This is the syntax i was thinking of.

RiccardoRossi · 2021-09-16T10:03:48Z

just for the reference...this is the definition of json pointers in the standard

https://datatracker.ietf.org/doc/html/rfc6901

AlejandroCornejo · 2021-09-16T10:18:51Z

IDK if this could be useful for your case but when we treat composite materials we define a CL which has inside different CL like:

{
    "properties" : [{
        "model_part_name" : "Structure.Parts_Solid_Auto1",
        "properties_id"   : 1,
        "Material"        : {
            "constitutive_law" : {
                "name" : "SerialParallelRuleOfMixturesLaw",
                "combination_factors"          : [0.7, 0.3],
                "parallel_behaviour_directions" : [1,1,1,1,1,1]
            },
            "Variables"        : {
            },
            "Tables"           : {}
        },
        "sub_properties" : [{
            "properties_id"   : 11,
            "Material"        : {
                "constitutive_law" : {
                    "name" : "LinearElastic3DLaw"
                },
                "Variables"        : {
                    "DENSITY"       : 7850.0,
                    "YOUNG_MODULUS" : 3e9,
                    "POISSON_RATIO" : 0.0
                },
                "Tables"           : {}
            }
        },{
            "properties_id"   : 12,
            "Material"        : {
                "constitutive_law" : {
                    "name" : "LinearElastic3DLaw"
                },
                "Variables"        : {
                    "DENSITY"       : 2000.0,
                    "YOUNG_MODULUS" : 2.1e11,
                    "POISSON_RATIO" : 0.0
                },
                "Tables"           : {}
            }
        }]
    }]
    }

ddiezrod · 2021-09-16T12:02:56Z

IDK if this could be useful for your case but when we treat composite materials we define a CL which has inside different CL

We actually thought about this option. We could have a law that has a Fluid and a Thermomechanical law defined inside as subproperties and then decide which one to call using ProcessInfo for example. This looks very ad hoc in my opinion and not very clear...

RiccardoRossi · 2021-09-16T14:02:49Z

Ok I see two possibilities,

doing the replacement as a preprocessor to KratosParameters (can be easily done in python with just replacements)
Then its user's decision to use this or not, we can create a small python utilitiy to do this. So overhead is only if required.

Doing it at the Ctor of KratosParameters.
This will always check for strings, it is an overhead. In order to keep the overhead minimum, then we can do this recursive string search in the std::string ctor only. (not doing this on copy, move ctors, because if they are used, then we can assume the passed KratosParameters are already created at one point with std::string ctor.

We also can put the same non-recursive seach with KratosParameters::SetString method as well.

another issue i see with this is that as of now the ProjectParameters is not in charge of opening files. I honestly think this is good and i would be quite reluctant to changing this

loumalouomega · 2021-09-16T14:04:39Z

another issue i see with this is that as of now the ProjectParameters is not in charge of opening files. I honestly think this is good and i would be quite reluctant to changing this

But in refers to several files, like materials.json and the mdpa file

RiccardoRossi · 2021-09-16T14:39:04Z

yes, but so far we open the file and read it in and then pass it as a string to the ProjectParameter

ddiezrod · 2021-09-24T11:48:58Z

I was thinking that maybe we do not need any include. ReadMaterialsUtility does not completely overwrite the properties, so this would work:
we assign material properties in stage 1

materials_stage_1:
{
  "properties": [
    {
      "model_part_name": "main_model_part",
      "properties_id": 1,
      "Material": {
        "name": "A7075",
        "constitutive_law":{
              "name": "Newtonian3DLaw"
        },
        "Variables": {
          "LATENT_HEAT": 339611.0,
          "DENSITY": 339611.0
.... many other properties
        }
        
      }
    }
  ]
}

we run stage 1
we assign material properties in stage 2

material_stage_2;
{
  "properties": [
    {
      "model_part_name": "main_model_part",
      "properties_id": 1,
      "Material": {
        "name": "A7075",
        "constitutive_law":{
              "name": "ThermoElastic3DLaw"
        }
 }
}

when we run the stage 2 the rest of the properties from stage 1 will still be there (DENSITY, LATENT_HEAT etc) , so you do not have any duplication. ReadMaterials will throw a warning, that is all...

pooyan-dadvand · 2021-10-08T09:15:02Z

After some time thinking about your comments I arrived at the following reflections:

The include is a very good idea and IMO it can be done via preprocessing the stream and replacing (on the fly) the included part as @sunethwarna also suggested. I don't think it will imply a large overhead but we should check it. Meanwhile, it adds a lot of flexibility
I am not sure if the inclusion should be a keyword or the content (Open to discussion)
About the relation between CL and material and concern of @RiccardoRossi, I still see the relationship as each CL should have 1 (or more) material to work with. It is like now but we are separating the material in a separate (and shareable) section of json
About the problem that we need different data from material (like young modulus for isotropic and non-isotropic CLs) I don't see a real difference in the knowledge of the users. Now you should know what they need and put it in their JSON section while in my proposal you should know it and if it's not already in the material you should add it.
Separating the material helps to have CLs and Interfaces reuse them without a lot of duplication of data. Please note that in many cases interfaces will reuse the materials by the CLs
About having different properties per stage I am not sure (neither against) if we should include everything in the stage itself in the JSON file proposed by @ddiezrod. The advantage would be a better encapsulation of data but I am not sure from the user perspective and duplications of data that it may cause will counterbalance it. Also, I don't think that stage should know about the material
IMO, for assigning the CLs and mapping the previous values from the previous stages (concern of @Vahid-Galavi) we should use modelers (maybe with includes). So from one side, we are keeping the encapsulation of the stages and on the other side, we are translating the responsibility from the stage to the modelers. I would also add some mapping modelers to do the data transfer from previous stages. (I like to hear from @philbucher about this)

RiccardoRossi · 2021-10-08T10:05:51Z

about point 3,
at this point you can use a "json pointer" and the syntax will nto change at all (i mean, what works today would still work, and you could have the capability you propose)

pooyan-dadvand · 2021-10-08T13:12:49Z

It is not a bad idea but then we should put them in the same json. Isn't it?

RiccardoRossi · 2021-10-08T13:21:03Z

yes, but this is completely inline with your proposal:

essentially what i am proposing is that you can either set the parameters as you are doing normally

"Parameters" : { "YOUNG" : 30e6, "POISSON" : 0.3}

or to say that "Parameters" points to another section in the json

"Parameters" : "/material_library/mat1/Parameters"

where i am assuming that there is a portion "material_library" somewhere within the samefile (from the root of the file in this case)

RiccardoRossi · 2021-10-08T13:22:00Z

just to tell this is documented here:

https://github.com/nlohmann/json#json-pointer-and-json-patch

and that at the same link you also get links to the standardization of the feature (also the patch feature is supported, which may also be interesting)

philbucher · 2021-10-08T13:30:38Z

7. IMO, for assigning the CLs and mapping the previous values from the previous stages (concern of @Vahid-Galavi) we should use modelers (maybe with includes). So from one side, we are keeping the encapsulation of the stages and on the other side, we are translating the responsibility from the stage to the modelers. I would also add some mapping modelers to do the data transfer from previous stages. (I like to hear from @philbucher about this)

sure that can be done. Note that this requires to interpolate/extrapolate to the nodes before and after mapping, but apart from that it should work

Vahid-Galavi · 2021-10-08T13:36:43Z

IMO, for assigning the CLs and mapping the previous values from the previous stages (concern of @Vahid-Galavi) we should use modelers (maybe with includes). So from one side, we are keeping the encapsulation of the stages and on the other side, we are translating the responsibility from the stage to the modelers. I would also add some mapping modelers to do the data transfer from previous stages. (I like to hear from @philbucher about this)

sure that can be done. Note that this requires to interpolate/extrapolate to the nodes before and after mapping, but apart from that it should work

Extrapolation/interpolation to the nodes might smoothen the stresses and state variables. This is not a desired behaviour when the same mesh and number of integration points are used in the calculation stages.

philbucher · 2021-10-08T13:43:36Z

Extrapolation/interpolation to the nodes might smoothen the stresses and state variables. This is not a desired behaviour when the same mesh and number of integration points are used in the calculation stages.

I was thinking of non-matching meshes. Ofc for matching meshes you could just copy the variables, no need for mapping

Sure the inter/extrapolation might alter the values, but so does the mapping itself. IMO this is the price one would have to pay for non-matching meshes

pooyan-dadvand · 2021-10-08T13:48:10Z

And we should think about the mapping of elemental integration point data

pooyan-dadvand · 2021-10-08T13:49:00Z

@RiccardoRossi I like the idea of the pointer

RiccardoRossi · 2021-10-08T13:49:45Z

well, i agree about all of those comments about 7, nevertheless i think it is a bit of a different issue:

one thing is how to write the material parameters file... a different (very relevant, but different) thing is to do the interpolation of data when the mesh is changed

ddiezrod added the Discussion label Sep 15, 2021

ddiezrod self-assigned this Sep 15, 2021

ddiezrod mentioned this issue Sep 22, 2021

Constitutive Laws are being replaced in multi-stage simulation in StructuralMechanics #9147

Open

ddiezrod changed the title ~~Are constitutive laws really material properties?~~ Use different properties in multi-stage simulations Sep 24, 2021

roigcarlo added this to Technical Commiittee Oct 30, 2023

roigcarlo moved this to 📋 Backlog in Technical Commiittee Oct 30, 2023

roigcarlo moved this from 📋 Backlog to 👀 In review in Technical Commiittee Oct 30, 2023

roigcarlo moved this from 👀 Next meeting TODO to 🆕 New in Technical Commiittee Dec 19, 2023

Use different properties in multi-stage simulations #9128

Use different properties in multi-stage simulations #9128

Comments

ddiezrod commented Sep 15, 2021

ddiezrod commented Sep 15, 2021

AlejandroCornejo commented Sep 15, 2021

loumalouomega commented Sep 15, 2021

Vahid-Galavi commented Sep 15, 2021 • edited Loading

loumalouomega commented Sep 15, 2021

rubenzorrilla commented Sep 15, 2021

loumalouomega commented Sep 15, 2021

ddiezrod commented Sep 15, 2021

ddiezrod commented Sep 15, 2021 • edited Loading

ddiezrod commented Sep 15, 2021

RiccardoRossi commented Sep 15, 2021 via email

rubenzorrilla commented Sep 15, 2021

rubenzorrilla commented Sep 15, 2021

loumalouomega commented Sep 15, 2021

RiccardoRossi commented Sep 15, 2021

ddiezrod commented Sep 15, 2021 • edited Loading

loumalouomega commented Sep 15, 2021

rubenzorrilla commented Sep 15, 2021

rubenzorrilla commented Sep 15, 2021

loumalouomega commented Sep 15, 2021

ddiezrod commented Sep 15, 2021

rubenzorrilla commented Sep 15, 2021

RiccardoRossi commented Sep 15, 2021

ddiezrod commented Sep 15, 2021

Vahid-Galavi commented Sep 15, 2021 • edited Loading

Vahid-Galavi commented Sep 15, 2021

pooyan-dadvand commented Sep 15, 2021

sunethwarna commented Sep 16, 2021

RiccardoRossi commented Sep 16, 2021

sunethwarna commented Sep 16, 2021

sunethwarna commented Sep 16, 2021

RiccardoRossi commented Sep 16, 2021

AlejandroCornejo commented Sep 16, 2021

ddiezrod commented Sep 16, 2021

RiccardoRossi commented Sep 16, 2021

loumalouomega commented Sep 16, 2021

RiccardoRossi commented Sep 16, 2021

ddiezrod commented Sep 24, 2021

pooyan-dadvand commented Oct 8, 2021

RiccardoRossi commented Oct 8, 2021

pooyan-dadvand commented Oct 8, 2021

RiccardoRossi commented Oct 8, 2021

RiccardoRossi commented Oct 8, 2021

philbucher commented Oct 8, 2021

Vahid-Galavi commented Oct 8, 2021

philbucher commented Oct 8, 2021

pooyan-dadvand commented Oct 8, 2021

pooyan-dadvand commented Oct 8, 2021

RiccardoRossi commented Oct 8, 2021

Vahid-Galavi commented Sep 15, 2021 •

edited

Loading

ddiezrod commented Sep 15, 2021 •

edited

Loading

ddiezrod commented Sep 15, 2021 •

edited

Loading

Vahid-Galavi commented Sep 15, 2021 •

edited

Loading