using nurbs meshes in parallel

[NorbertHofbauer]

Hi everyone,

i am currently trying to get my serial version run in parallel. I have an coefficient in my system that works as interface between two meshes. This works very well in serial. But in parallel i can't get it to work. I haven´t found a way to access the elementtransformations from the other parmeshes. When i try my luck with GetFaceNbrElementTransformation i get the error "ParFiniteElementSpace::GetFaceNbrFE does not support NURBS!"

Is there a way to access the data in other nurbs parmeshes? I need to be able to evaluate the Gridfunctions of two different meshes on an specific physical point.

Is it possible to do the assembly in serial, solve in parallel and continue working with the gridfunctions in serial?

thanks in advance

[v-dobrev]

If you have two different parallel meshes, then the same physical point may belong to two elements (in the two meshes) that are assigned to different MPI ranks. In such cases, the evaluations of the ParGridFunctions at the given physical point will have to be done on different MPI ranks and then communicated. One can also communicate the ParGridFunction data for a specific element but that may be a bit harder to do.

In this setting a lot depends on what information is available on what MPI ranks. For example, do all ranks know the physical coordinates of all points where you want to evaluate the two ParGridFunctions? If a point is found on rank1 in mesh 1 and on rank2 in mesh 2, does rank1 know the id of rank2 and vice versa, does rank2 know the id of rank1? If they do, then they can do the ParGridFunction evaluation locally and then exchange the two values for this particular point.

Regarding the approach where you switch between serial GridFunctions and parallel ParGridFunctions: going from serial to parallel is relatively simple, see #2416 (comment). The reverse, recovering a serial GridFunction on the original serial mesh from a ParGridFunction is also possible (as long as the parallel mesh is not modified, e.g. refined), see #1155 (comment).

[v-dobrev]

Note: I just noticed this -- the code in #1155 (comment) has some memory leaks, as pointed out further down in that issue, see #1155 (comment) for a better implementation.