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?