Mapping a small surface into a volume modifies all nodes of the destination part

[pablobecker]

Description This is probably asking too much from the mapper, so I will give some context: We are solving a problem which has two boundary conditions: "supports" and "rest" For reasons, the calculation mesh we read in them mdpa has a single model part for all the conditions ( triangles). But we get the "support_aux" BC, which is given as an approximate, non-conforming triangles mesh, with a different size. So we have to take the triangles from the "rest" bc and move them into a new one called "supports", where the non conforming mesh is approximately.

Originally we were using the DistanceToSkin process , which works correctly but is not MPI-ready. So we switched to the mapper to fix this. Basically, we set all the nodes of the destination part ("rest") as 0.0 and 1.0 to "support_aux" in an aux var. After mapping, what we'd like to get is the nodes in "rest" of the face that matches "support_aux" a value of 1.0 , and the other nodes in 0.0 since the do not match the surface. But we get 1.0 in all the nodes. So the mapper is mapping to 100% of the nodes in the destination part.

So, the question is, is there a setting to force the mapper to only project to nodes that are close to the surface? My concern is that searching by distance between nodes of the two model parts would not do, since the mesh sizes are different. It must be la limit distance between these conditions(surfaces) and the nodes of the destination part.

Scope

• MappingApplication

ping @philbucher

[philbucher]

Hi, could you post a pic of your setup for me to understand better? I think I get what you mean but just to be sure we are on the same page

[rubenzorrilla]

Just mentioning that the distance to skin process works in MPI provided that you have the complete intersecting skin in each processor (admittedly not the best solution but it works).

[pablobecker]

cube_few_elements_no_base.zip

I attached the mdpa

it's basically a cube of 1x1x1, meshed with 0.5 tetras+triangles Then at the base (Z=0.0) it has 8 triangles of edge =0.5

At Z=0.0, there are also 4 nodes (28,29,30,31) , which define 2 conditions (49,50) . This sets define the "skin" model part ("support_aux") . I set 1.0 to the nodes in this auxiliary model part, and i'd like ONLY the nodes at Z=0.0 of the cube mesh to have this 1.0 projected. but I end up with the 27 nodes set to 1.0 after calling the mapper

[pablobecker]

@rubenzorrilla yes, we thought about that but it's kinda ugly tbh.

[ddiezrod]

So this is more or less the problem. We try to map one model part (the red one with values = 1) into the other one (the black one with all values = 0). We "expected" that only nodes from the bottom will turn = 1, but actually all of them seem to adapt the new value from the origin model part.

I am not sure if this is an error actually as all nodes can find their projection I guess...

[philbucher]

hey, thx for the pic, I didn't see it until now

So this is the expected behavior, by default the mapper tries to find neighbors for all of the nodes in the destination. To solve this I recommend to split the interface of the quad, so that the mapper only takes the part of the interface into account on which you want to map. This is the general solution that I always recommend.

Does that work for you?

Other ways might be possible but will be more hacky

[pablobecker]

Hi Philip. no, that will not work. The result we are looking for is precisely which of those conditions should be labeled as "bottom", so we cannot provide that set. We want to see how the given surface of the input would look like in the new, destination, mesh, to set a different set of BC there.

[philbucher]

is the mesh matching? It looks like it in your picture

[philbucher]

is the mesh matching? It looks like it in your picture

nevermind I saw that you wrote in the initial post that it is not matching

I will try some stuff and get back to you

[RiccardoRossi]

hey, thx for the pic, I didn't see it until now

So this is the expected behavior, by default the mapper tries to find neighbors for all of the nodes in the destination. To solve this I recommend to split the interface of the quad, so that the mapper only takes the part of the interface into account on which you want to map. This is the general solution that I always recommend.

Does that work for you?

Other ways might be possible but will be more hacky

hi Philip,

i shall say that this behaviour is a little strange...i understand one may want to do it optionally, but i don t see normal that this is the default and only behaviour

[philbucher]

I understand that this might not be intuitive, but the requirement for using the mapper is that the geometries of the interfaces are matching Long time ago we took the decision to prioritize robustness, which means that all the nodes will try to find their partners (which is what we see in the pic above) Personally I think this was the right decision, even though in some cases it might not be intuitive. And usually (actually always until now) it was possible to partition the geometry and help the mapper

[philbucher]

I played around, but I didn't get it to work, but I think I don't have the setup correctly can you share your script please? (that in general decreases my answer time a lot if I can just run a script and debug it :smiley:)