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...