[Dune] Element transformation/renumbering in GridFactory

[Dedner, Andreas]

Hi.
As Christian said this information is not retrievable. The only (possibly not so great) solution I could come up with was to rewrite the mapping on each element in a 'global' form. e.g. write it with respect to monomials relative to the center of the element and scaled with some length scale given by the element which is again independent of the local numbering. For not too high order mapping (perhaps less then 5?) I think this will be quite accurate; for higher order or elements with very bad aspect ratios you need to choose the axis orientation of your global coordinates quite carefully. You could use coordinates based o the 'minimum bounding box'
  https://en.wikipedia.org/wiki/Minimum_bounding_box
I use something similar to get numerically stable VEM basis function, but overall that approach is quite a lot of work and perhaps too numerically unstable to be useful.
Andreas
________________________________
From: Dune <dune-bounces at lists.dune-project.org> on behalf of Simon Praetorius <simon.praetorius at tu-dresden.de>
Sent: 13 April 2020 11:22
To: Christian Engwer <christian.engwer at uni-muenster.de>; dune at lists.dune-project.org <dune at lists.dune-project.org>
Subject: Re: [Dune] Element transformation/renumbering in GridFactory

Hi Christian,

The example is similar to what you already guessed:

Let's assume, I have a VTU or GMsh file that stores higher-order cells, i.e. additional vertices inside the elements (plus implicitly an interpretation of these vertices, like coefficients of a lagrange parametrization). So, in the mesh file only those vertices per element are visible. Now, when reading such a grid I want to

1. read the "flat" elements and construct a corresponding "flat" grid
2. read the additional vertices to provide either an element parametrization in the `insertElement()` method, or data for a discrete function that can be used later on to construct curved geometries.

Note, in the `insertElement()` call, the entities are not yet constructed and thus I do not have access to any insertion-index of (sub-)entities.

My procedure is as follows: in step 1 I extract the corner vertices from the list of element vertices, in step 2 I simply store all vertices (or indices in a global vertex list) per element. In combination with a lagrange local basis (that is conforming to the lagrange-vertex ordering in the mesh file) I can construct a simple elementParametrization function, by evaluating the local basis functions in the given local coordinate and linear-combining this with the stored vertices.

Note, that this only works, if the local coordinate passed to the elementParametrization is w.r.t. the coordinate system of the element in the file. This elementParametrization must be created before the actual grid element is constructed. Thus, I cannot  know any reorientation of the final element in the construction of the parametrization. This means, that the grid must be responsible for passing transformed local coordinates to the element-parametrization on evaluation. (I'm not sure whether this is guaranteed)

The second goal in step 2 is to create a discrete function for final grid parametrization. This discrete function should map a local coordinate in an element to the global coordinate of the element parametrization. Here, I have all the entities in a grid constructed and have the insertion-indices of all elements and vertices. But not the local renumbering/reorientation of the entities.

Maybe I could create a mapping of the element corners to the original corners, by inspecting the insertion-index of the vertex sub-entities of an element and then comparing indices to construct a permutation of the local corner coordinates and with this a MultilinearGeometry to map the local coordinates?? I'm not sure whether this works out. What is missing is something similar to the insertion-index, maybe an `insertion-permutation`:

```c++
/// Return the permutation vector that mapps corner indices in `entity` the vertices passed in \ref insertElement()
virtual std::vector<unsigned int>
insertionPermutation ( const typename Codim< dimension >::Entity &entity ) const
{
  // need to be implemented!
}
```

If the grid does not permute the inserted vertices, this function could return an identity permtutation. Then, maybe the return type should be something else that can be implemented more efficiently.

Best,
Simon

---
Dr. Simon Praetorius
Institut für Wissenschaftliches Rechnen
Fakultät Mathematik
Technische Universität Dresden
Tel.: TUD-34432
Mail: simon.praetorius at tu-dresden.de
Web: www.math.tu-dresden.de/~spraetor<http://www.math.tu-dresden.de/~spraetor>

________________________________________
Von: Christian Engwer <christian.engwer at uni-muenster.de>
Gesendet: Montag, 13. April 2020 11:50
An: Praetorius, Simon; dune at lists.dune-project.org
Betreff: Re: [Dune] Element transformation/renumbering in GridFactory

Hi Simon,

>Does this include the local numbering of ther vertices in an element?
>Yes, I can get the insertion index of an element or a vertex index, but
>how to extract from this the changed local numbering of an element. (Do
>I mix something up here?)

No, I don't think this is currently possible.

Could you give an example of what you are trying to achieve in the end? Perhaps there is an alternative approach?!

If you are storing a grid parameterization, you can store a P1/Q1 function. Surely this is not sufficient to store higher order mappings. You could work around this problem by storing an element local higher order representation. The second yields the parameterization up to a local transformation. The transformation should be deducible from the two representations, as the linear part of the full representation has to match the very based representation. Not nice, but a start.

Besides this I'm sure people would be glad about a good proposal for an improved factory interface :-)

Christian

_______________________________________________
Dune mailing list
Dune at lists.dune-project.org
https://lists.dune-project.org/mailman/listinfo/dune
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20200413/e397077e/attachment.htm>