Accepting Geometries as input - Operate internally to assign Entities to geometries

[RiccardoRossi]

This is kind of a follow-up of #278 and of the corresponding disussion in https://github.com/KratosMultiphysics/GiDInterface/issues/80

i think we should start looking into reading "geometry groups" and define assignement processes acting on such geometry groups.

let's assume that nodes are defined as now (Id,x,y,z) and that NodalIds are automatic

I think that we could conceptually define groups of geometries, identified without Id simply by their connectivity (i mean list of node Ids) and by the type of the geometry. It would be rather easy to provide the GeometryClass with a hash function so that maps containing pointers to the geometries can be easily constructed.

The point is that one could have a "globalmap" holding all of the geometries being created and then submaps holding the pointers to groups of geometries.

One may then define a "ConditionAssignProcess" assigning a given ConditionType to a group of geometries. This should be assigned a target modelpart as well as instructions whether to reuse elements holding a given geometry OR if creating new one.

The key point is that if we do this, the complete numeration business and assignement of properties would be on the Kratos side, so that the preprocessor would only need to dump the pure geometrical information.

well i'll post more when i refine the details of a possible design in my own mind. Suggestions/criticism would be more than welcome...

[jginternational]

Old glory days...

[roigcarlo]

Honestly I don't remember what this was about :S

Let me take a look tomorrow

El jue., 25 ene. 2018 17:56, JaviG notifications@github.com escribió:

Old glory days...

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/KratosMultiphysics/Kratos/issues/289#issuecomment-360529532, or mute the thread https://github.com/notifications/unsubscribe-auth/AB2Jr5_8kEU4B7hjS1auMav8gY1b6ydsks5tOLJagaJpZM4M9vm_ .

[loumalouomega]

I have been supporting always this idea

[pooyan-dadvand]

In general I agree with reading the topolgy instead of elements but I don't see the complete point of view of @RiccardoRossi yet.... Actually I see a mixture of two different designs in one. Meanwhile I would put my idea about this on the table.

From Kratos Database point of view I would go for adding a geometries container to the Mesh and hold them with the rest of the mesh entities. This would allow us to correctly dispatch them in different sub model parts and passing it to the processes and strategies without additional effort. Nevertheless I'm not sure the best search mechanism in this container is by pointer our proximity. (Open to discuss)

About the reading them I see two options:

• Reading Mesh geometries: Means that Nodes have to had Ids and geometries are read as connectivity (I like this one)
• Reading STL like format where each geometry is given by its vertices coordinates. This one for me is an option for reading the original geometry of model but is an overkill for reading a real mesh. (In comments of @RiccardoRossi I saw a mixture of these two which I could not deduced his preference)

Finally the main problem to have this working in the past was the elemental and conditional data management which always forced us to use the element and condition base classes for such purposes.

[pooyan-dadvand]

Technical Committee: just close it and stick to the use of Element3D4N, Condition3D3N, etc....

reopen in case the solution is not acceptable