New features for MappingApplication

[philbucher]

I am currently planning the expansion of the MappingApplication towards more mappers and more functionalities. I would like to know which features would be wanted / needed in addition to the regular mapping operations in order to discuss it next week with @pooyan-dadvand and @RiccardoRossi . I.e. which information should be accessible, which interfaces etc. should be provided, @KratosMultiphysics/structural-mechanics, @jcotela, @rubenzorrilla, @dbaumgaertner, @adityaghantasala, @msandre

For your information, one big change will be the implementation of mapping matrices: So far the mapping is implemented to work without matrices (matrices that relate the destination to the origin). For the Mortar Mapper however, these matrices are needed. In order to have a consistent implementation I want to change the existing mappers to work with matrices as well.

(M are the mapping matrices and q are the vector of quantities on origin and destination respectively)

[RiccardoRossi]

Hi Philip, from my personal view, i welcome the implementation of the implicit version of the mapper.

i have two "wishes"

1. It would be nice if what you implements also works for "volume to volume" projections and not just surface to surface. This would ease interpolating between meshes in mpi, which will be a must to refine/derefine meshes in parallel.
2. eventually it would be nice to have the possibility to defining contact elements in mpi, the way @loumalouomega is doing it. I guess you guys should speak a bit about the issue

also i think that @loumalouomega implemented splitting of elements for correct integration of the mortar. It should definitely be possible that you guys take advantage of each others group

[msandre]

@philbucher thanks for opening this discussion. As you know, we are interested in using the mapper with Aditya's constraints to create periodic boundaries and sliding interfaces. After discussion with @jcotela we think it would be useful to reuse the search structures and communication pattern constructed in the mapper to send/receive data needed for constraints as well as to access the coefficients of the mapping matrices. It might be sufficient to have a pGetMapperCommunicator() function to get the communicator to use in other parts of the code.

[loumalouomega]

Hi @philbucher, in my current branch I have implemented a fully consistent Mortar Condition, both for contact and mesh tying. The idea is in the future for the mesh tying to use the dual lagrange multiplier (the implementation of dual lagrange multiplier is done already) to condensate the system and remove the lagrange multiplier from the system of equations as Popp does, this way can be used as an "strong mapper" without increasing the complexity of the system. My intention was to define the variable to map as template argument, but it was really hard and I dismissed

Any help is welcome

[philbucher]

@RiccardoRossi Volume to Volume should already work with the NearestNeighborMapper. I haven't tested it, but I will do so in the next days. Besides this I will think about how more advanced techniques could be realized

@loumalouomega I will look into your work in more detail soon, then we can discuss how to proceed.

@msandre I think this can be realized

[adityaghantasala]

@philbucher As @msandre mentioned we would like to use this functionality. As of now the exact detail is not that clear. So we should discuss more on how we can realize. My be we need additional functions to pGetMapperCommunicator() in order to realize this. We will get a clear idea once I finish the serial version of the constraint application.

[RiccardoRossi]

Hi Philip, from a practical point of view, nearest neighbour is not really useful for me (too inaccurate)... i think that the minimum that has a practical use (for the cases i am thinking of, of course) is interpolation mapping.

[philbucher]

@RiccardoRossi I tested with NearestNeighbor today, it works. The interpolation based mapping should also work with a bit of tweaking the code (mainly bcs it uses Conditions and not Elements, I think we can discuss the implementational details next week).

Do you know / have other volume mapping methods in mind, except nearest neighbor, interpolation (nearest element and barycentric) or maybe rbf? Is there an equivalent to mortar (aka weak form based) for volume mapping?

[philbucher]

@RiccardoRossi The Element based mappers work with Conditions. When I tried Volume Mapping I noticed that there are no 3D Conditions, therefore using conditions will not work. @jcotela told me that now elements and conditions inherit from the same class. I am not sure how one could unify the procedure, I think we should discuss it next week. I really want to avoid copy pasting of code, in the worst case I guess I could write a 3D Condition for VolumeMapping.

[jcotela]

@philbucher I don't see why mortar can't work in 3D. The only problem is that clipping and similar procedures will be an order of magnitude more painful to implement.

Just for the record, my suggestion to make the mapping code independent of Elements/Conditions is to extract the underlying geometries (which are all derived from a common class) from the objects passed as input, and defining your functions to work with geometries.

[msandre]

@loumalouomega I think there is similarity from the software point of view in what we would eventually like to do with what you are working on. The basic implementation goals we have identified so far are:

1. A low level software layer (say at the builder and solver level) that enforces linear multi-freedom constraints based on equation ids of master dofs and corresponding weighting factors stored at the slave dof/node. This assumes the Mdd matrix of @philbucher to be the identity (qd are slave dofs) and takes care of the condensation of Lagrange multipliers in the assembly. It would work in both serial and MPI and be independent of the multiphysics problem.

2. A second software layer that acts as an interface to the first level for certain classes of multi-freedom constraints: user-defined, periodic, sliding interfaces, chimera, etc. The idea here would be to reuse certain structures of the parallel mapper (e.g., communicator and search algorithm) to compute the weighting factors (dual mortar, surface/volume interpolation) and send them along with equation ids to the slave dofs (for condensation/assembly). Since each multi-freedom constraint is one row in the above equation system of @philbucher (for the special case that Mdd is the identity), it would be useful to store each row of the mapping matrix on the process of its corresponding slave dof. Additionally, we would need to have a second storage (with the same structure as the mapping matrix) of equation ids of the masters (in Philipp's notation the masters are the origin). These equation ids are used after the element level manipulations are performed on the slave side to assemble the modified terms to the corresponding master equation ids in the global system.

As @adityaghantasala is working on the constraints at the moment, we don't have a converged implementation yet. Some issues are:

• Should we do the general multi-freedom constraint in the builder and solver or in a special scheme encapsulating the regular scheme?
• Should we store the weights/ids in Epetra/ublas matrices similar to what @philbucher is planning with the mapper and expose this to the builder and solver or use/implement our own data structure?
• How should we extend/modify the mapping communicator to make it generally useful for mapping and coupling?