[Input] Read in block-id

[maxfirmbach]

Hello together,

in Cubit it is possible to create blocks with e.g. Block <block_id> ..., nothing surprising for the avid Cubit user 😄.
In Gmsh there's a similar functionality. As I'm informed these user-given blocks are usually used to define a region with dedicated physics or unique behavior.

Now to my question though, I was wondering if it is possible to read in this <block-id> in 4C and store it somewhere.
E.g. every node in the discretization has a unique id, but is also related to a block-id. For elements this might be even be more natural.

Is something like this already existing in 4C? How could one implement such a thing?

@sebproell @isteinbrecher @mayrmt

[maxfirmbach]

I assume with the native exodus file reader such a thing would be available by construction.

[sebproell]

The Exodus::Mesh object has this information. Currently, we discard this object after reading is finished, but we could copy the data over into the discretization classes such that it is available.

E.g. every node in the discretization has a unique id, but is also related to a block-id.

Note that this does not make a lot of sense for a continuous discretization where you can have nodes shared by elements in different blocks.

For elements this might be even be more natural.

Yes, this makes sense, IMO.

[mayrmt]

Note that this does not make a lot of sense for a continuous discretization where you can have nodes shared by elements in different blocks.

We want to use this for AMG preconditoiners in contact problems to distinguish between the different bodies. In this case, it is guaranteed by the problem setup, that nodes belong to only one block. Yes, it's a special case.

[sebproell]

Ah, I see; this is kind of a DG discretization ;) I am currently trying to untangle our notion of conditions, node sets, (and future side sets), element blocks in the discretization (see e.g. #795). My goal is that you can cluster entities however you want/with minimal effort because this should not be a property of the Node, Element etc directly (i.e., it should not be stored in some member variables). Instead, a set of such entities can conveniently refer to these entities and live next to the Discretization internals. This way makes the types of entities extensible without hacking inside the internals of the Discretization. I think it wouldn't be too difficult to start creating these "entity sets" and your use case could be a first prototype to get a better understanding of the requirements.

[isteinbrecher]

Couldn't we use something like element sets for this?

[maxfirmbach]

I can't really comment on the implementation details, for me it felt like the block-id is already there by reading exodus files, we just need to store them somewhere.