Generic Model Generator from GiD

[philbucher]

When creating models for development I need to create SubModelParts most of the times, containing various entities (Nodes, Conditions, Elements) of different types (e.g. SurfaceCondition)

Doing that with GiD is quite cumbersome since one has to got through one of the available Problemtype-Applications (Fluid, Structural,...) and the available Conditions (such as Loads, Inlet, Outlet, Displacement)
I.e. if I want a group defined in GiD to appear in the mdpa file I have to assign a random Condition to do it.

I am proposing a generic model generator to write mdpa files with which I can crate SubModelParts beyond the standard stuff where I can define the entities I want it to have.

This could be either integrated in the existing Problemtype-Applications or exist as a separate one

What is your opinion on this?
@KratosMultiphysics/technical-committee @KratosMultiphysics/kratos-core-team
@KratosMultiphysics/gidproblemtype
@KratosMultiphysics/fluid-dynamics @KratosMultiphysics/structural-mechanics

[dbaumgaertner]

I am very much supporting this idea since e.g. in all the optimization applications we are dealing with in Kratos, we constantly need to generate sub-model parts for various different geometrical operations.

[adityaghantasala]

+1 from my side too.

[maceligueta]

I also support the idea, as long as it remains bounded to the 'developer' version of the GUI. I think the tree could allow you to print a group as a SubModelPart (maybe nested levels also?? @jginternational) and it should allow to select if you want to print the nodes, elements or conditions somehow.

[philbucher]

@maceligueta That is exactly what would be needed
Restricting it to the developer version makes perfect sense for this

[RiccardoRossi]

+1. I also think it will be very useful for developers

[jginternational]

So, as far as I understood, you want to create GiD groups of entities, and make them appear in the MDPA as submodelparts writing its entities (nodes and/or elements and/or conditions) but without having to assign these groups to any known condition (Load, Inlets...).

As @maceligueta said, this could be done adding to the tree some kind of branch (only for developers use) to select/create those groups, and choice what do you want to print (nodes|nodes+conditions|nodes+elements)

[philbucher]

@jginternational Yes exactly the way you describe

[RiccardoRossi]

@jginternational one comment:

i believe that for this to be useful you will need to generate the conditions on the same face always with the same Id. I am telling this because at CIMNE we had a very long internal discussion about this, and we are clear of the difficulties, however this is not the case for @philbucher and @dbaumgaertner.

My point is that I believe (but please correct if i am wrong) that the expected behaviour is that the outer face of a given element is always assigned the same Id, so that the corresponding Condition is not generated multiple times.

[jginternational]

In fact, @RiccardoRossi , at this point, any entity assigned to a group has it's own id. It doesn't matter if it's a face or not.
The problemtype is not longer working with the concept of 'face'.

About the issue of keeping the same id for the same entity, the best way to achieve it is by using the GiD id.
Any other solution, such as making tcl to remember if a condition has been written an which id was assigned are, by far, a big performance trouble. Remember the troubles we found writing the mdpa for the barcelona model.

But this should be another issue

[RiccardoRossi]

@jginternational , i really don't understand what you are saying :-(

let's consider you have a "condition" (using Kratos nomenclature) on the face that goes between node 1 and node 2. Say that we need that condition will be written multiple times to the mdpa, as part of multiple submodelparts. I am not clear if the Id of that condition will be always the same in all the submodelparts?
if so perfect, forget about the current post. otherwise we have a problem...

[RiccardoRossi]

to ease the discussion let's consider the following mesh

 1 - 2 - 3
 |   |   |
 4 - 5 - 6

let's assume that we have the following conditions :

 CondId   Connectivities
 1 1 2
 2 2 3
 3 3 6
 4 6 5
 5 5 4
 6 4 1

the behaviour i would expect and that i believe that @philbucher @dbaumgaertner are epxecting (guys please correct me if i am wrong on this) is something like (name of the modelparts describe the portion of the domain)

SubModelPart AllSkin
      Begin Conditions
          1
          2
          3
          4
          5
          6
      End Conditions

SubModelPart TopPart
      Begin Conditions
          1
          2
      End Conditions

SubModelPart TopAndLeftPart
      Begin Conditions
          1
          2
          6
      End Conditions 

[philbucher]

@RiccardoRossi This is what I would expect

But doesn't that already work with the current GiD conditions?
E.g. if one assigns a node to "Inlet" and "Wall", it is only created once and then referred to in both SubModelParts as far as I know

[RiccardoRossi]

Hi @philbucher,

it works fine with nodes, the problem is if you want a submodelpart to contain "Conditions" or "Elements".
imagine you want all the "faces" on the skin or all the ones on the body because you want to apply a slip condition there...

similarly you may have PointLoadConditions in order to be able to apply point loads while assembling the system. These are conditions and may belong to multiple modelparts.

[dbaumgaertner]

@RiccardoRossi but the above SubModelPart "AllSkin" contains all the conditions on the boundary. And each condition id is assigned to a special condition type, say slip condition, that I may use for some analysis. I don't see the conflict, yet. What am I missing here?

[RiccardoRossi]

Hi Daniel,
imagine the following scenario:

you want:
1 - to compute the normal on the whole skin
2 - to apply a wall law on the surface of the solid body
3 - to apply a pressure BC on the outlet boundary.
4 - make an average of a variable on outlet and wall

all of such conditions are to be applied by a process, which operates on submodelparts, namely on the "conditions" contained in each of such model parts. You need that the instance of condition contained in the "wall part" is the same as the one contained in the whole skin (two pointers to the same instance).
Same for pressure and BC. Moreover you also need to point to the same objects between wall and outlet.

The practical issue is that guaranteeing that such objects are correctly assigned an unique Id (which must remain the same when writing the different submodelparts) is far from trivial within GiD.
The most important blocker appears to be that there is no way to do it efficiently.
@jginternational maybe you can better explain why this is difficult, as myself do not completely understand the issue

[maceligueta]

I think there's no problem if the Id is the same across the modelparts. The problem appears when Kratos needs different Ids for different conditions that are the same triangle actually. We'll wait for Javi's opinion...

[jginternational]

Let me please open a new issue for this.

The current issue is claiming for a way to assign a group somewhere in the tree, to be able to write as MDPA with elements and/or conditions.

In the new issue we can argue about How the problemtype should write, you can find it here