[MedApplication] Preserve node and geometry IDs in MED I/O with SubModelParts by Marco1410 · Pull Request #14201 · KratosMultiphysics/Kratos

Marco1410 · 2026-02-12T12:15:48Z

📝 Description
This PR updates the MED I/O so that Kratos can write and read MED files preserving node and geometry IDs, including SubModelParts.

Main points:

Node IDs are preserved during write/read.
Geometry IDs are preserved.
SubModelParts in Kratos are saved as family groups in Salome and correctly reconstructed when reading.
Proper handling of SALOME points vs Kratos nodes to avoid creating unwanted point geometries.

I tested this with Python and C++ tests, and also with HROM potential flow models. So far everything works as expected.

🆕 Changelog

Updated 'med_model_part_io.cpp' (WriteModelPart and ReadModelPart)
Added/updated Python and C++ tests

…and geometry ids

philbucher

cool!

I have some concerns, but overall looks good

I leave approval to current users

philbucher · 2026-02-12T13:09:16Z

applications/MedApplication/custom_io/med_model_part_io.cpp

        for (int i = 0; i < num_groups; i++) {
-            group_names[i] = StringUtilities::Trim(c_group_names.substr(i * MED_LNAME_SIZE, MED_LNAME_SIZE), /*RemoveNullChar=*/true);
+            std::string raw_name( c_group_names.data() + i * MED_LNAME_SIZE, MED_LNAME_SIZE);
+            raw_name = StringUtilities::Trim(raw_name, true);


can you explain this change a bit? I thought the nullchars are already handled?

Thanks for your comments Philipp.

With the original version, the group names contain garbage characters at the end. To fix this, I trim the strings at the "\0" null terminator.

At least on Ubuntu, this works.

philbucher · 2026-02-12T13:10:10Z

applications/MedApplication/custom_io/med_model_part_io.cpp

            reorder_fct(geom_node_ids);

+            // Avoid using nodes or points as geometries
+            if (geo_type == MED_POINT1) {


why are those skipped? Structural cases need them! (e.g. pointloads)

I'm skipping the creation of point geometries, as they don't represent real geometries in Kratos.

Here, node families are used to construct SubModelParts that contain only nodes.

But they should represent real geometries. If you dont want them then you shouldnt create them in Salome.

See an example for a simple cantilever how they are used:
https://github.com/KratosMultiphysics/KratosSalomePlugin/blob/dce31197e15887b40174d27783ac2839b0134a2e/tui_examples/cantilever/salome_cantilever_hexa.py#L60

philbucher · 2026-02-12T13:13:14Z

applications/MedApplication/custom_io/med_model_part_io.cpp

        num_nodes,
        dimension);

+    // get global numbering for nodes, if the file contains them


ah man, despite my best efforts the IDs are always finding their way back :D

Main reason I am against using ids is that they are often (ab) used to get nodes from ModelParts. This is a search, which is expensive for large models
=> one should use position in the ModelPart instead with is O(1)
Also non-consecutive IDs can create problems for MPI-partitioning

personal rant aside, this should be optional, as some meshers dont even write the IDs
I would vote to not read the IDs by default, but that decision I leave to current users or the tech-committee

That’s true, but in any case, if we do nothing, the MED library enumerates them in its own way. This option is available in both Kratos and Salome, so for now, I think it is better to keep them synchronised. We can remove this later if needed.

well until now the Ids were just enuerated from the node position

In any case, I dont have a strong opinion

It's optional now, but locally just so we don't forget we're doing it until someone says something about it.

applications/MedApplication/custom_utilities/med_testing_utilities.cpp

philbucher · 2026-02-13T17:00:36Z

applications/MedApplication/custom_io/med_model_part_io.cpp

+            << "Using MED implicit numbering." << std::endl;
+
+        for (med_int i = 0; i < num_nodes; ++i) {
+            node_ids[i] = i + 1;


I think you can use std::iota or sth similar

philbucher

I remembered some more potential conceptual issues with the export of SubModelParts

philbucher · 2026-02-20T10:20:54Z

applications/MedApplication/custom_io/med_model_part_io.cpp

+    med_int dimension = 0;
+    for (const auto& r_geom : rThisModelPart.Geometries()) {
+
+        dimension = std::max( dimension, static_cast<med_int>(r_geom.WorkingSpaceDimension()));
+    }
+    if (dimension == 0 || dimension == 1){
+        dimension = 3;
+    }


Suggested change

med_int dimension = 0;

for (const auto& r_geom : rThisModelPart.Geometries()) {

dimension = std::max( dimension, static_cast<med_int>(r_geom.WorkingSpaceDimension()));

}

if (dimension == 0 || dimension == 1){

dimension = 3;

}

med_int dimension = 2;

for (const auto& r_geom : rThisModelPart.Geometries()) {

dimension = std::max( dimension, static_cast<med_int>(r_geom.WorkingSpaceDimension()));

}

philbucher · 2026-02-20T10:28:36Z

applications/MedApplication/custom_io/med_model_part_io.cpp

+    CheckMEDErrorCode(err, "MEDmeshGlobalNumberWr (nodes)");
+
+    med_int next_family = 1;
+    std::unordered_map<std::string, med_int> smp_to_family;


I remembered part of why I didnt implement the writing of SubModelParts: A family in med is NOT the same as a SubModelPart in Kratos. A family contains only one type of geometry (e.g. only Triangle3 or Tetra4).
The med equivalent of a SubModelPart is a group, which consists of multiple families. (actually the relation is the other way round, each family has groups)

Also what I think is not considered is if a geometry belongs to multiple SubModelParts.

Back then I thought the solution would be to tag each entity like is done for the MMG-stuff, but not sure

philbucher · 2026-02-20T10:29:03Z

applications/MedApplication/custom_io/med_model_part_io.cpp

+
+    CheckMEDErrorCode(err, "MEDmeshGlobalNumberWr (nodes)");
+
+    med_int next_family = 1;


FYI by definition node-families are positive, whereas geometry families are negative

philbucher · 2026-02-20T10:29:27Z

applications/MedApplication/custom_io/med_model_part_io.cpp

+        CheckMEDErrorCode(err, "MEDmeshGlobalNumberWr (cells)");
+
+        const std::size_t nb_elem = conn.size();
+        std::vector<med_int> elem_family_numbers(nb_elem, 0);


Suggested change

std::vector<med_int> elem_family_numbers(nb_elem, 0);

std::vector<med_int> geom_family_numbers(nb_elem, 0);

philbucher · 2026-02-20T10:30:24Z

applications/MedApplication/custom_io/med_model_part_io.cpp

+
+    std::function<void(const ModelPart&)> collect_subparts =
+        [&](const ModelPart& mp) {
+            for (const auto& r_child : mp.SubModelParts()) {


med doesnt know SubSubModelParts, I am curious how you handle it. Have you tested it?

Marco1410 added 4 commits February 12, 2026 12:35

main changes write-read modelpart with submodelparts preserving node …

ed19972

…and geometry ids

adding some changes for tests

cb0e374

fix cpp test

485779e

fix python tests

23c7bfa

Marco1410 requested review from matekelemen and philbucher February 12, 2026 12:15

Marco1410 assigned rubenzorrilla, riccardotosi and Rbravo555 Feb 12, 2026

Marco1410 added Enhancement IO MedApplication Salome labels Feb 12, 2026

philbucher reviewed Feb 12, 2026

View reviewed changes

Marco1410 assigned RiccardoRossi and unassigned riccardotosi Feb 12, 2026

philbucher reviewed Feb 13, 2026

View reviewed changes

Marco1410 added 5 commits February 19, 2026 11:47

Removed commented code

bf2e4ca

Replaced loop with std::iota

375f894

preserve global numbering for nodes ids optional

bb9d217

allow create submodelparts with point geometries

d4a5f25

fixed python tests

089a928

philbucher reviewed Feb 20, 2026

View reviewed changes

Merge branch 'master' into marco/med_application

e3d18aa


		CheckMEDErrorCode(err, "MEDmeshGlobalNumberWr (nodes)");

		med_int next_family = 1;

	std::vector<med_int> elem_family_numbers(nb_elem, 0);
	std::vector<med_int> geom_family_numbers(nb_elem, 0);

Conversation

Marco1410 commented Feb 12, 2026

Uh oh!

philbucher left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

philbucher Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

philbucher left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

philbucher Feb 12, 2026 •

edited

Loading