Incorrect transfer of data from displaced source

[lindsayad]

Bug Description

Executing the inputs contained on my branch debugging-22119, which stems from discussion #22119 leads to the following undesirable behavior:

• libMesh node ID 89365 (exodus node ID 89366) is an example of a to-node getting a 0 value when it shouldn't
• This corresponds to the 4833 point that we want to query the from-mesh for (e.g. index 4832 in the incoming/outgoing points vector)
• When asking the mesh function to find the from-element containing that to-node we are getting back a null result, indicating that it thinks the point is out of the mesh
• When we get to the active nodes in TreeNode, we do get bounds_point but we do not get any elements that contains_point

I don't really know why this would be a hard case ... these are linear elements so I would expect inverse mapping from the physical space to the reference space to essentially be exact.

@roystgnr do you have any thoughts on what might be the issue here? Pasted below is a figure. The bottom is the sub-application field that we are transferring to the main application on top. You can see that we are getting these "teeth" in the transfer with the blue gaps in the teeth essentially indicating a failed transfer

Steps to Reproduce

Run the parent.i input in my branch

Impact

Incorrect data transfers from displaced meshes. Erodes trust in the transfer system

[lindsayad]

We can definitely verify that we have an elem->contains_point within the displaced mesh, so what gives ...

[lindsayad]

libMesh Elem ID is 5323 (Exodus ID 5324)

[lindsayad]

@maxnezdyur I think this looks better, eh?

[maxnezdyur]

A lot better!