Alternative computation of the volume mapping

[CsatiZoltan]

t8code can handle curved elements in a cmesh by computing the volume mapping between a reference volume and its position in the physical space. The mapping is determined with the help of the vertices of the volume and contributions from its edges and faces [1, 2]. The latter two are obtained from the CAD geometry on which the mesh was constructed.

I can see its advantage, namely, the exact geometry can be approximated arbitrarily well.
On the other hand, it requires

1. that the geometry be available in BRep format, which is not the case if you receive a mesh
2. a heavyweight CAD engine dependency

How about implementing the volume mapping by the standard finite element basis functions $\psi_i$? Assume that a mesh generator created a mesh of curved elements (e.g. a mesh of 27-node triquadratic hexahedra). An arbitrary point $\vec{\xi}$ in the reference element is then mapped to the point $\mathbf{x}$ in the physical space by
$$\mathbf{x}(\vec{\xi}) = \sum\limits_{i=1}^{N_\mathrm{node}} \psi_i(\vec{\xi}) \mathbf{x}_i$$
where $\mathbf{x}_i$ are the coordinates of the nodes of the element.

This description tackles the above-mentioned issues. Is there any reason that it is not implemented in t8code? Does t8code provide the means that I can implement it myself?

References

[1] Constructing a Volume Geometry Map for Hexahedra with Curved Boundary Geometries - article
[2] Constructing a Volume Geometry Map for Hexahedra with Curved Boundary Geometries - presentation

[Davknapp]

Dear @CsatiZoltan ,
thanks for your idea, I transfered it to the discussion part, where it fits better in my opinion. But please feel free to open further issues, if you find any.

Regarding your questions:
How geometry is handled was implemented by @sandro-elsweijer and found this approach most interesting. However, I see the advantages of your approach, the reason why it is not yet implemented is probably, that we currently don't have the time to do so.
In general, we are happy about contributions outside from the core-developer-team. Your idea sounds like others would profit from your implementation, too.
I think what you would need to do is to implement your idea as a new geometry in t8code. For more details, it is best to talk with @sandro-elsweijer , he is the expert for this matter.

[CsatiZoltan]

@Davknapp

I transfered it to the discussion part, where it fits better in my opinion.

Sure, Johannes Markert already wrote that he would convert my issues to discussions.

I think what you would need to do is to implement your idea as a new geometry in t8code.

I think so. I read all the tutorials on the Wiki page, so I know the ideas of t8code more or less, but I have never touched the code itself.

[Davknapp]

Feel free to play around with the code and to start to get more experience! If any questions arise on the road, just post them, hopefully we will be able to answer them all ;)

[CsatiZoltan]

@Davknapp

If any questions arise on the road, just post them, hopefully we will be able to answer them all ;)

What if these questions are really low level and general, e.g. related to the code design of t8code? Those questions could arise periodically and are too general to fit to a specific discussion thread. Moreover, they would just cause noise in the Discussion threads that deal with a certain issue (like this one). Where could those questions be asked? Is there a forum for t8code developers?

[sandro-elsweijer]

Hey @CsatiZoltan,
we have a team about t8code on our Mattermost server. Maybe you can send me a mail (sandro.elsweijer[at]dlr.de), then I will send you an invitation link.

[sandro-elsweijer]

Hey @CsatiZoltan,
thank you for that excellent question!
The classical approach via a curved input mesh was discussed before implementing our approach. But since the geometry evaluation is computed on the coarse mesh level, the geometrical accuracy of refined elements will not get any more accurate than the input mesh. Of course, this approach is easier and faster, but it conflicts with our forest-of-trees approach, where we want the input mesh as coarse as possible to benefit most from the tree structures in our refined mesh.

But it is still a great implementation, and it is also on our bucket-list. If you want to tackle this challenge, I am glad to help where I can!

[CsatiZoltan]

Yes, it generalizes well to other element types too.
The mesh format is indeed my concern currently. If it was the mesh only, it would be quite straightforward. However, I need to read the fields too. A vtkUnstructuredGridobject would be a natural solution to read into, given that

• fields can be associated with the mesh (both vertex-based and cell-based)
• it would allow me to use a wide range of algorithms from VTK
• it would not require a new dependency, since t8code is already (optionally) linked with VTK.

On the other hand, the representation of high-degree polynomial solutions is not unique, so we need to think about how to provide this information. We will discuss it in our lab.
Perhaps this Discussion thread should focus on the geometrical mapping only...

[sandro-elsweijer]

This seems like a good idea. Unfortunately, I am not very experienced with VTK, but when you are ready, you can talk to @Davknapp about the implementation of the high order VTK reader.

Would you like to create a draft pull request in advance? This way, we can review the code early and potentially save ourselves some work later on.

[CsatiZoltan]

PR #851 submitted.

[CsatiZoltan]

As another example, I created a hybrid coarse mesh. I don't think that the mesh conformity can be sustained between two neighbouring curved elements of different types. So this hybrid mesh example is a useful demonstration for linear elements only.

[CsatiZoltan]

PR #851 merged to main.