Add 3D case for partitioned heat conduction

[NiklasVin]

• compared to existing heat conduction examples, it is in 3D and helps to validate vector valued and 3D coupling
• what is necessary to run this new case: FEniCSx v0.10, preCICE v.3.3.1, preCICE python bindings v.3.3.1 and FEniCSx-preCICE adapter (currently the most recent state on the develop branch)
• Output at t=1:

Checklist:

• I added a summary of any user-facing changes (compared to the last release) in the changelog-entries/<PRnumber>.md.
• I will remember to squash-and-merge, providing a useful summary of the changes of this PR.

[IshaanDesai]

The case setup and folder structure look good. I think the tutorial is valuable as we currently do not have any other way of testing the FEniCSx adapter in 3D.

I remember there were some issues with data-mapping accuracy. Can you please briefly describe the issues, which mapping settings you tried, and what effect each had?

[NiklasVin]

I dont remember every mapping I used but I ran a few setups similar to them I tried in the past. I figured out that the mapping defined for the Dirichlet participant (i.e. read from Neumann Mesh) primarily influenced the accuracy of the result (I suppose the reason is that the Dirichlet participant requires BC function of degree 2, and the Neumann only degree 1):

• nearest-neigbor: Does not really work (error after first time step 3.8e-1)
• rbf-pum with compact-polynomial-c2: Better but the error is also rather large after the first time step (magnitude of about e-3)
• rbf-pum with compact-polynomial-c8: The best I could find (the c4, c6 are also better than the c2 option)
• For the rbf-pum, I noticed that you need to tremendously increase relative-overlap, vertices-per-cluster and support-radius from the default values to get somewhat accurate results.

Generally I am not very happy with the results because setting the dofs directly from the preCICE data yields better results (I think the error was within the magnitude of e-7). As far as I can assess this situation the solver code is correct but the mapping & interpolation steps break the accuracy...

[NiklasVin]

I ran more tests to further investigate how the mapping configuration changes the accuracy (only to t=0.1):

Mapping Neumann → Dirichlet	Mapping Dirichlet → Neumann	L2-error (Dirichlet)
analytical BCs	nearest-neighbor	9.92E-15 / Neumann: 1.16E-14
nearest-neighbor	"	0.0423
nearest-projection	"	not supported by adapter
thin-plate-splines*	"	0.000464
compact-tps-c2*	"	>1e-4
multiquadratics (sup.-rad. 1)*	"	1.8E-06
multiquadratics (sup.-rad. 1.25)*	"	4.16E-07
inv. multiquadratics (sup.-rad. 1)*	"	6.13E-06
inv. multiquadratics (sup.-rad. 1.2)*	"	1.68E-06
compact-polynomial-c2 (sup.-rad. 2.5)*	"	0.000305
compact-polynomial-c4 (sup.-rad. 2.5)*	"	9.7E-05
compact-polynomial-c6 (sup.-rad. 2.5)*	"	4.69E-05
compact-polynomial-c8 (sup.-rad. 2.5)*	"	2.81E-05
compact-polynomial-c8 (sup.-rad. 1)*	"	0.000475
compact-polynomial-c8 (sup.-rad. 10)*	"	2.93E-07

All results are computed with consistent constraint. Entries marked with a * are computed with the rbf-global-direct mapping.

The current mapping configuration committed on GitHub uses rbf-pum-direct, with incredibly large relative-overlap, vertices-per-cluster and support-radius, which is I guess a sign for bad configuration.

@davidscn Since I’m not very familiar with finding the most sensible mapping, could you maybe take a look at what could be changed in the mapping configuration to reduce the error?

[davidscn]

I am not sure I understand the entire discussion. A few points that come to my mind

You replace the Neumann participant by an analytical function with matching meshes and a nearest neighbor mapping, you get something in the order of 1e-14, i.e., the first row, correct? Or do you replace both participants? What does analytical mean and how does the coupling look like? Which participants do you replace? Is it unidirectional? To isolate the mapping error, it would be useful to have an analytical function at nonmatching points.
In all other rows: do you replace the analytical function by nonmatching participants and use a mapping in preCICE. How do you make the setup nonmatching then?

• which accuracy do you expect from the RBF mapping and why?
• if you want to tune the accuracy of the mapping, I would pay more attention to the support-radius configuration of a given RBF, not so much the RBF itself. Direct RBF vs PUM does not matter all that much at the moment. I would plot the error over the support radius config, and this yields generally an optimum curve.
• I have a very similar 2D experiment, which you may want to look at to get a feeling for what to expect.