[MappingApplication] Extending the MappingApplication to Support Mapping Beyond Nodes

[juancamarotti]

Background

Currently, the MappingApplication and the implemented mappers are designed to perform mapping only between nodes.
After the mapping process, the update of the nodes in the model part is carried out through the InterfaceVectorContainer class, which essentially writes the mapped results to the corresponding nodes.

Motivation

In some cases, it is necessary to map between other entities, such as elements, conditions, or geometries, or even between nodes and these entities.
A concrete example arises in the context of Isogeometric Analysis (IGA):
In IGA, displacements cannot always be mapped to control points (nodes), since these do not necessarily belong to the geometry. Instead, the mapping must be done to the conditions (i.e., integration points on the trimmed surface) that weakly impose the boundary conditions.

To address these kinds of cases, we propose extending the MappingApplication’s interface to support mapping between a broader set of entity types.

Proposal

After discussions with @matekelemen and @sunethwarna, we agreed it would be beneficial to generalize the MappingApplication interface to allow the creation of future mappers that can handle mappings not only between nodes, but also between:

• Elements
• Conditions
• Geometries
  Importantly, existing mappers will remain fully functional, continuing to operate only between nodes. No breaking changes are expected in their behavior.

Technical Details

The proposal is to:

• Make InterfaceVectorContainer a virtual base class.
• Introduce two new derived classes from this base class:

1. InterfaceNodeVectorContainer: Responsible for mappings between nodes (preserving current functionality).
2. InterfaceEntityVectorContainer<EntityType>: A templated class responsible for mappings between elements, conditions, and geometries.

Future mappers that handle mappings involving elements, conditions, or geometries will use InterfaceEntityVectorContainer<EntityType> as a member variable, while existing node-based mappers will continue using InterfaceNodeVectorContainer.

Expected Impact

• Backward compatibility: Existing node mappers remain unaffected.
• Forward extensibility: Enables development of new mappers supporting more general mapping scenarios.
• Improved flexibility: Facilitates use cases such as IGA and other multiphysics or geometry-based mappings.

I would really like to hear some more opinions on this point before starting to work.

FYI @KratosMultiphysics/technical-committee @KratosMultiphysics/cosimulation @philbucher @matekelemen @sunethwarna

[philbucher]

Overall I think this is a good approach.

Also check the InterfaceObject, which goes in the same direction. In particular for the search it is crucial to generalize the entity that is being searched.