Solution.type_cell

[SebGue]

Hello,

I guess this is a question for @helene-t or @RaphaelPile but anyone else is also invited to join the discussion :-)

Solution got the prop 'type_cell' with "Type of cell (Point, Segment2, Triangle3, etc.)". Now looking at the code, I think distinction between nodal and elemental data would be better. At least I haven't found any reason to specify the cell type explicitly.
Further with mixed element type meshes, logically there is no single cell type and we had to seperate the solution data per cell type.

So do you see any reason to keep 'type_cell' instead of e.g. 'is_nodal'?

Best regards, Sebastian

[RaphaelPile]

Hello Sebastian,

When I was at EOMYS, I have worked on algorithms which required such differentiation in elements types.
It is based on Finite Element definitions (flux is per cell, pressure is on a surface, potential can be nodal etc.). Because each operation in any postprocessing must be adapted for each type of element, in particular the field interpolation. To take that into account, we decided to define each Solution based on an element type (it requires several objects Solution in the solution list of MeshSolution if you have several types of element).

[SebGue]

Hello Raphaël,

thanks for your response.
I guessed there are algorithms that require the different elements types.
The point is that most basic post processing (e.g. plotting results) with one Solultion per element typ is inconvienient and I think it is even not avialable at the moment. Further with each new coupled solver, the contributor has to regard each possible element type when creating the code for "get_meshsolution".

So I think it could be better to care for element types only in the algorithms itself, i.e. when a differentiation is needed.

Best regrads, Sebastian

[RaphaelPile]

Hello Seb,

We should probably take a look at the different solvers, and how the results are stored.
Maybe, it could be more convenient to assemble the result for the plotting.

But if you find an efficient way to store everything in the same Solution object, I could work on the compatibility with existing Solution objects ;-)

[SebGue]

Hello Raphaël,

I was thinking of MeshVTK, i.e. VTK meshes and results, e.g. for Elmer coupling, that support multiple elements. Further with meshio it should be possible convert most other meshes/results to VTK.
But first, is it possible to also store multi element meshes in MeshMat too? If not, then we should make template or common function to do the element type based splitting of Solution to simplify solver coupling for contributors. Then we should do the assembly of results and fields.

Otherwise, Solution could store one value per cell index (as is) no matter what the actual cell type is?! Or is there any other culpit I don't see?

[RaphaelPile]

But first, is it possible to also store multi element meshes in MeshMat too?
Not really, because the stored ndarray of connectivity has fixed dimensions (nb_cell x nb_node_per_cell).

Solution could store one value per cell index (as is) no matter what the actual cell type is
Are you thinking about a list/dict containing the field per cell ? It could work.

[SebGue]

Not really, because the stored ndarray of connectivity has fixed dimensions (nb_cell x nb_node_per_cell).
Okay, I see.

Are you thinking about a list/dict containing the field per cell ? It could work.
No, I would use SolutionData as it is. I.e. data are stored in DataND with cell indices are the axes.

In general I hope you got my point. So do you think splitting results for storage and assembling for post processing is the better way. Or would you prefer a change in MeshMat to allow multipe element types in favor for easier solver coupling/meshsolution generation?

[RaphaelPile]

I think the modification on the MeshMat is not the optimal way to put our efforts:

1. Most of the visualization in Pyleecan relies on Pyvista, using MeshVTK, which can handle several cell types.
2. I am pretty sure there are way more efficient librairies for storing mesh and solution. MeshMat is more a "MeshFEMM" class. It is really convenient for small 2D meshes from FEMM, but it is not really generic and optimized.