[Dune] Element transformation/renumbering in GridFactory

Tue Apr 14 09:14:51 CEST 2020

Thanks a lot for all the feedback. 

I could figured out a way to get the renumbering and thus a local geometry transformation after this grid is created. This is based on the mentioned strategy to compare insertion indices of vertices of grid elements. It needs to be tested a bit more, but with ALUGrid is workes fine already. The elementParametrization argument in inserteElement() needs to be tested separately.

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

________________________________________
Von: Dune <dune-bounces at lists.dune-project.org> im Auftrag von Carsten Gräser <graeser at mi.fu-berlin.de>
Gesendet: Montag, 13. April 2020 17:20
An: dune at lists.dune-project.org
Betreff: Re: [Dune] Element transformation/renumbering in GridFactory

Hi Simon,

Am 13.04.20 um 12:22 schrieb Simon Praetorius:
> 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)
when inserting an element or boundary segment, the only local
coordinate system that you know, is the one associated to
the local insertion ordering. If the grid does a local transformation
in terms of a local renumbering, then it is also responsible for
transforming the element and boundary segment parameterizations.
If it does not do this correctly I would consider this a bug.

Consequently passing the manually transformed parameterization
in the factory (by knowing the renumbering from some oracle)
would be a bug in user code.

> 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.
As described above knowing the permutation should not be necessary
for passing parameterizations to the factory. However, this may be
need for other purposes. For this case your proposal looks reasonable,
but I'd rather return a range (e.g. to make the identity cheap).

But it should also be possible to derive this from the global insertion
index permutation in an external utility by doing some element-local
index comparisons.

Best,
Carsten

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

--
Prof. Dr. Carsten Gräser
Freie Universität Berlin
Institut für Mathematik
Arnimallee 6
14195 Berlin, Germany
phone: +49 30 838 72637
fax  : +49 30 838 472637
email: graeser at mi.fu-berlin.de
URL  : http://page.mi.fu-berlin.de/graeser