Add SubModelPart feature

[adityaghantasala]

Currently when we select that a group is to be written as an additional SubModelPart and select Write Elements option the following happens :

All the elements are written normally and the elements in the "SubModelPart" chosen to be written are written out again in a separate Begin Elements - End Elements.

This means the ImportModelPart in Kratos tries to add the elements twice and crashes with error.

Shouldn't the behaviour be like : when a group is selected to be written as SubModelPart it should only write

Begin SubModelPart

End SubModelPart

block with corresponding nodes and elements/conditions in that given group ?

Here I am attaching an example.
test_gid_submp.gid.zip

[adityaghantasala]

Ping !

[jginternational]

@rubenzorrilla abd @roigcarlo I'll ask you tomorrow about this one, because I don't know if this is possible

[rubenzorrilla]

Hi @adityaghantasala !

I guess you need this functionality to define the patches for your Chimera stuff. After briefly discussing about it with @jginternational , we feel that to fix the generic submodelpart's issue it's a bit tricky as it would imply to reimplement the writing just for the generic submodelpart's.

Considering that this was conceived as an auxiliary functionality to be (let's say) rarely used, why don't we put the effort to finish the Chimera APP GUI #609.

[adityaghantasala]

Well this is not only for Chimera.
In general if i want to define a sub modelpart out of a bunch of elements, it should not write the element definition ( connectivity) again right? Thats like if i write a sub mp of certain nodes then its like writing the nodes (coordinates and number) again.

The result of that the IO errors out and stops executing.

[philbucher]

From what I understand the problem comes bcs some types of problems (e.g. structural) require the elements in the mdpa => e.g SolidElement2D3N. In those cases it is not a problem to have an additional generic submodelpart that has generic elements/conditions (e.g. Element2D3N), even on the same geometry

For others like Fluid, there we only write the generic elements/conditions, they are later replaced inside of Kratos. Now defining a generic submodelpart on those geometries will lead to a duplication of the same entity but with a different ID. This makes it fail in the input.

Looking into the future this will become a problem for everyone once we switch from reading elements/conditions to reading connectivities. Hence I would say this is an issue that should be solved, otherwise we kinda lose the (very very very useful) feature of defining "custom" submodelpart

[jginternational]

There is no problem with conditions, since the tcl scripts generate the ids. With the elements, we use the GiD element id, so if the same mesh element is used 2 or 3 times, it will appear always with the same ID.

In fact, I think that this is the best way, since the element is a physical entity, and should have only one element type. (A beam is always a beam, and water is always water...)

I don't know which is the way to solve this but I must akways write the element definition, because I cannot use them in submodelparts if they are undefined, and checking for every element if it's been written is extremely unefficient

[philbucher]

Thats what I thought, no worries
Maybe when moving to writing connectivities a better solution will be found

[adityaghantasala]

Ya hope there is a better solution with this issue.