Definition of Interface to Mappers

[aditya]

Hello everyone

Following the suggestion of Riccardo I am moving the discussion of creating the interface to mapper in to this forum.

Few important points from the previous discussion on "producteev"

• As simple as possible
• Should be for both vector and scalar variables
• Methods for mapping fields back and forth
• Constructors takes "Modelpart" as arguments.
• Different mapper now existing :
  • projection.h
  • binbased projection.h
  • AdvancedNMPointsMapper
  • Another mapper for mapping between particles
•    Naming :
  • Map_1_to_2(ORIGIN_VARIABLE, DESTINATION_VARIABLE)   ---- Map_2_to_1(ORIGIN_VARIABLE, DESTINATION_VARIABLE)
  • Map_Domain1_to_Domain2(ORIGIN_VARIABLE, DESTINATION_VARIABLE) ---- Map_Domain2_to_Domain1(ORIGIN_VARIABLE, DESTINATION_VARIABLE)
  • MapForward ---- MapBackward
  • Map_Master_to_Slave(ORIGIN_VARIABLE, DESTINATION_VARIABLE)  ----- Map_Slave_to_Master(ORIGIN_VARIABLE, DESTINATION_VARIABLE)

[aditya]

Regarding my contribution to the discussion :

I am also thinking that passing model parts to the constructors of mappers. But am thinking how to get the relevant information from that model part. Also about the naming .... I am thinking about just a Map function ... and the direction of mapping is determined by the order of arguments passed ... here I am also thinking like

Map(MP1,dataField1, MP2, dataField2) for forward mapping ..
Map(MP2, dataField2, MP1, dataField1) for backward mapping

... Also ... I will suggest an initialize function mapper apart from the constructor, to separate computation inside the mapper ....

[riccardo]

so you are proposing something like the following signature:

template<class TDataType >
Map(
ModelPart& model_part_1,
Variable< TDataType >& rVariable1,
ModelPart& model_part_2,
Variable< TDataType >& rVariable2
)

i am personally more in favour of two mapping functions
Map1to2
and
Map2to1

the rationale behind the vote is that internally it may be convenient to construct first the 1_to_2 mapping and then
to express the mapping 2_to_1 as a function of the data structures constructed for the first mapping.
Using the syntax you propose it is not too easy to achieve this. (admittedly, neither too difficult)

in favour of your proposal there is however that it may be more readable, so i don't really have a strong view on this

regarding the
Initialize()
 i agree completely.
also there shall be a function
Clear()

i would add that the class shall be ideally configured using the new "Parameters" mechanism (take a look to the Processes i recently wrote)

and i wonder if functions
InitializeSolutionStep
FinalizeSolutionStep

would also not be welcome (although empty 99% of the time)

cheers
Riccardo

[pooyan]

I think that we should pass the model parts in the constructor if we want to take advantage of the search data structure several times. In this case we will need to different methods to do the bi directional projection accepting the variable they are projecting.

[riccardo]

+1 fro Pooyan's point

then there shall also be a sort of method "Update" to tell if the mesh relative connectivity is changing

Riccardo

[philippb]

To continue the discussion here is the email to keep in mind:

Hi everyone,
I have designed the python interface of the MappingApplication and I would like to hear your opinion / suggestions for improvement about it.

Usage in MainKratos.py:
Importing:   
    from KratosMultiphysics.MappingApplication import *
    import Mapper

Initialization of Mapper:
    some_mapper = Mapper.NonMatchingGridMapper(model_part_origin, model_part_destination, project_parameters)

Functions of the mapper:
    Map (Origin -> Destination):
        some_mapper.Map(variable_origin, variable_destination)
    InverseMap (Destination -> Origin):
        some_mapper.InverseMap(variable_origin, variable_destination)

    There are also some flags that can be defined:
    add_value: add the mapped values to the current values instead of overwriting them
    sign_positive: Flag for sign of mapped values
        e.g. : some_mapper.Map(variable_origin, variable_destination, True, False)
       
    UpdateInterface (In case of sliding interfaces, re-meshing, ...) -> Recomputes the pairing and everything that is related to that (such as Mapping Matrices, ...)
        some_mapper.UpdateInterface()
   

Usage in *.json:
General Settings that are always needed:
type of mapper : ["mapper_type"] : i.e. NearestNeighbor, Mortar, ...
name of origin interface submodelpart: ["interface_submodel_part_origin"] : e.g."FluidNoSlipInterface3D_interface_orig_fluid"
name of destination interface submodelpart: ["interface_submodel_part_origin"] : e.g."StructureInterface3D_interface_dest_struct"

it looks like this then:
{
    "mapper_settings": {
        "mapper_type": "NearestNeighbor",
        "interface_submodel_part_origin" : "FluidNoSlipInterface3D_interface_orig_fluid",
        "interface_submodel_part_destination" : "StructureInterface3D_interface_dest_struct"
    }
}

=> If those parameters are not present in the *.json file, it will throw an error that also states the missing parameters

There are of course more parameters that can are needed depending on the type of mapper, but there are defaults for those.


If you want to check out the code, the MappingApplication is in the repository now, including some tests.
The Nearest Neighbor Mapper can be used already, for 2D and 3D cases


Please let me know if you have suggestions for improvement.
Best regards,
Philipp

[aditya]

A few things that came to me :
Regarding importing
    from KratosMultiphysics.MappingApplication import *
    import Mapper

I am not sure if "import Mapper" is required, unless if there are other utilities that are imported from the MappingApplication.
If this is not required one can directly instantiate the mapper like

some_mapper = NonMatchingGridMapper(model_part_origin, model_part_destination, project_parameters)

instead of doing

some_mapper = Mapper.NonMatchingGridMapper(model_part_origin, model_part_destination, project_parameters)

Regarding the flags

sign_positive: Flag for sign of mapped values

I personally feel that this is not so necessary, one can do this operation also on python level if necessary. On the other hand, the flag for add_value is very useful. as per the naming of this flag, add_value is fine with me, but I think something like "add_to_existing_variable" is more intuitive and more easy to understand.

Regarding the JSON file settings :

I have the feeling that there should be a provision to instantiate
a mapper with out using the project parameters, so for advanced users it is easy to create one with in the script without having to create the JSON structure.

For creating several mappers,  you can create something like this in JSON file

"mapper_list": [
    {
        "mapper_type": "NearestNeighbor",
        "interface_submodel_part_origin" : "FluidNoSlipInterface3D_interface_orig_fluid",
        "interface_submodel_part_destination" : "StructureInterface3D_interface_dest_struct"
    }

    {
        "mapper_type": "NearestNeighbor",
        "interface_submodel_part_origin" : "FluidNoSlipInterface3D_interface_orig_fluid",
        "interface_submodel_part_destination" : "StructureInterface3D_interface_dest_struct"
    }

],

this should give a list (atleast when parsing in python, I also think it works similarly in C++) which can be iterated over to setup multiple mappers which have their own independent properties. This is very useful for having multiple FSI interfaces directly from the problem type in GiD.


MPI Stuff :

I am not sure if you already are using it, but here it is
I remember a MPI call which might be useful for the work, its

MPI_Scatterv

helps in sending different lengths of data to different ranks at one go.

[MikeA]

I have the feeling that there should be a provision to instantiate
a mapper with out using the project parameters, so for advanced users it is easy to create one with in the script without having to create the JSON structure.

Advanced users could directly creating the json parameters object in the python script. I think the json format for the mapper should be similar to the processes. Expanding on Aditya's suggestion:

"mapper_list": [
    {
        "mapper_type": "NearestNeighbor",
        "origin_sub_model_part" : "FluidNoSlipInterface3D_interface_orig_fluid",
        "destination_sub_model_part" : "StructureInterface3D_interface_dest_struct",
       "Parameters" : { }
    },
   {
        "mapper_type": "NearestNeighbor",
        "origin_sub_model_part" : "FluidNoSlipInterface3D_interface_orig_fluid",
        "destination_sub_model_part" : "StructureInterface3D_interface_dest_struct",
        "Parameters" : {}
    }
],

The "mapper_type" tells the factory which mapper to construct by passing the "origin_sub_model_part", "destination_sub_model_part" and  "Parameters" to the constructor. The advanced user would create a Parameters object and construct the mapper themselves.
 

[philippb]

Hi everyone,
Here is an update regarding the interface of the MappingApplication:
Things that are open for discussion are marked with TODISCUSS

Importing:
I will change the factory from python to C++, therefore one line will be sufficient for importing the application:
from KratosMultiphysics.MappingApplication import *

Initializing the Mapper:
some_mapper = MapperFactory(model_part_origin, model_part_destination, project_parameters_mapper_1)

Functions of the Mapper:
Mapping from Origin to Destination:
some_mapper.Map(origin_variable, destination_variable, SWAP_SIGN | ADD_VALUES | POINT_WISE_VALUES | CONSERVATIVE)

Mapping from Destination to Origin:
some_mapper.InverseMap(origin_variable, destination_variable, SWAP_SIGN | ADD_VALUES | POINT_WISE_VALUES | CONSERVATIVE)

=> Here I decided NOT to change the variable order for the InverseMap, since this leads to more confusion than it would help. This way, the origin as ALWAYS the first argument and the destination is ALWAYS the second argument.

I hope the naming of the Flags is clearer now, still here is some explanation:
The order and the number of flags is arbitrary
SWAP_SIGN: Swaps the sign of the mapped values
ADD_VALUES: Instead of replacing the existing values with the mapped values, the mapped values are added to the existing values (needed e.g. if more than the mapped loads are assigned to the interface)
POINT_WISE_VALUES: If the load is not continuous but pointwise, it has to be converted before mapping and converted back after mapping (Sorry for the bad explanation, it is equivalent to the "distributed" flag of the ANM-Mapper)
CONSERVATIVE: Forces the mapping to be conservative

some_mapper.Update(REMESHED)
This function updates the interface (neighbor pairing and stuff) in case of a sliding interface (=> e.g. contact)
The REMESHED flag specifices that also the mesh has changed, so internally some more stuff is recomputed
TODISCUSS Naming: Update or UpdateInteface?

Usage in JSON:
I followed Mikes and Adityas suggestion. This is what a minimum json-file for the mapper looks like
{
   "mapper_settings": [
     {
          "mapper_type": "NearestNeighbor",
          "interface_submodel_part_origin": "FluidNoSlipInterface3D_interface_orig_fluid",
          "interface_submodel_part_destination": "StructureInterface3D_interface_dest_struct",
          "Parameters" : {}
    },
     {
          "mapper_type": "Mortar",
          "interface_submodel_part_origin": "FluidNoSlipInterface3D_interface_orig_fluid_2",
          "interface_submodel_part_destination": "StructureInterface3D_interface_dest_struct_2",
          "Parameters" : {}
   }
  ]
}

extracting the parameters works then like this:
project_parameters_mapper_1 = project_parameters["mapper_settings"][0]

TODISCUSS "Parameters": Here all the additional (i.e. optional) parameters are listed => should it be a sublist of one mapper or should each additional parameter be on the same level as the other three?
These additional parameters would be e.g. search_radius, linear solver settings (in case of Mortar),...

Regarding the creation of a Mapper without the MapperFactory:
I think it will be possible to create a mapper directly with just two submodelparts. In the end this will most probably just require another constructor of a mapper and exposing it to python. It could also be overloaded to take a parameters object, but then we are sort of back to the same solution as with the MapperFactory.
(e.g. nearest_neighbor_mapper = NearestNeighborMapper(interface_submodelpart_origin, interface_submodelpart_destination)
)

Personally I prefer the MapperFactory solution. This is a more generic approach in my opinion.

I hope I explained myself clear. Please let me know your suggestions / comments, on naming, usage,...

Philipp

[rzorrilla]

Hi everyone,

After a short discussion with Philipp, I cannot figure out at all which is the aim of having both CONSERVATIVE and POINT_WISE flags... In the old mapper the POINT_WISE flag launch an operation to preserve the interface equilibrium in case of mapping punctual loads (this is done computing the nodal Cauchy traction vector values and mapping them to the destination domain). So it comes to my mind that the flag CONSERVATIVE might be misunderstood...

Besides, AFAIK the conservative property is intrinsic of the mapper methodology. Thus how can we perfectly enforce it? (the technique that we used to use has some simplifications that drive to a mesh dependent error in the final equilibrium)...

Thanks in advance. Best regards,


Rubén.

[philippb]

Hi everyone,

We had a long discussion about this in Munich yesterday. I will try to explain it with words now, the mathematical proofs I will put in my Thesis.

First of all, to avoid further confusion, what Rubén means with:

In the old mapper the POINT_WISE flag

is called "distributed"

Now, regarding the conservation property of mappers:

Besides, AFAIK the conservative property is intrinsic of the mapper methodology. Thus how can we perfectly enforce it? (the technique that we used to use has some simplifications that drive to a mesh dependent error in the final equilibrium)...

By derivation, every mapper is CONSISTENT and not conservative. (Basis: Weak form on the interface)
A conservative mapper can be derived from the consistent one. The goal of a conservative mapper is to preserve the energy of the interface (aka interface equilibrium)
Here basically two different definitions exist:
- A simple redistribution of nodal values
- Based on the balance of virtual work (more sophisticated)
(The math will follow in the thesis)
Important here is that consistent mapping is independent of the physics, but conservative mapping is NOT! Therefore it only makes sense for some field quantities to be mapped conservative, such as the reaction forces in FSI.

Also it has to be said that for consistent mapping, we need distributed fields as input, for conservative mapping we need consistent nodal values.

Now what is happening in the existing mapper?

After a short discussion with Philipp, I cannot figure out at all which is the aim of having both CONSERVATIVE and POINT_WISE flags... In the old mapper the POINT_WISE flag launch an operation to preserve the interface equilibrium in case of mapping punctual loads (this is done computing the nodal Cauchy traction vector values and mapping them to the destination domain). So it comes to my mind that the flag CONSERVATIVE might be misunderstood...

Explanation:
This mapper does NOT have an implementation for conservative mapping! => only for consistent mapping
To map consistent nodal forces (consistent nodal values), we need to first convert them to tractions (distributed field), map them, and then convert them back.
This is exactly what happens if the "distributed" flag is set.

Now how to use the new mapper and what about the "POINT_WISE_VALUES" flag?
The new mapper has methods for conservative mapping (the "CONSERVATIVE" flag), so there is no need to first convert consistent nodal values to distributed fields for mapping, e.g. reaction can be directly mapped if the "CONSERVATIVE" flag is set. I.e. there is no need for the "POINT_WISE_VALUES" flag, I will remove it.

One last remark about the comparison of the old and the new mapper: While in the new mapper the conservative method is implemented explicitly, I am not sure if what was done in the old mapper is also conservative in the same sense. AFAIK it's somehow the same, but not sure if it is exactly the same. I will make another post if I know more about that.

Additional Remark:
Conversion from consistent nodal values to distributed fields might be implemented in some sort of utility, if one ever wants to do more fancy things (I think this is also what Riccardo suggested)

I hope I made myself clear.
Best regards,
Philipp

[jcotela]

Dear Philipp,

Thanks for your explaination, but we still have some questions regarding the CONSERVATIVE flag. Conservation is, as you noted, problem-dependent: in a FSI problem you want that the work (displacements*tractions) is the same (in weak form) on both sides, but on a different problem you might want to conserve a different quantity. To ensure conservation, we have to know which problem we are solving (which quantity we want to conserve), and so far the mapping application has been designed as problem-independent.

Furthermore, conservation (and consistency) are very much related to the mapping algorithm. What would you do, for example, to ensure that a Nearest Node algorithm is conservative *in general*?

Regarding moving the routine that converts between consistent and distributed fields to an utility, we (Ruben and I) agree that this is the best way forward. Maybe it could be moved completely out of the mapper, so that one would be free to call it before/after mapping if desired? This would allow us to remove the POINT_WISE flag. If this works, we might also want to think about doing something similar with the CONSERVATIVE flag, since now it is used to do a kind of post-process of the mapped solution?

Best regards,
Jordi