On Mon, 5 Jun 2017, Rovi Gabriele wrote:
I would like to implement the Raviart Thomas elements. In order to obtain a
global basis function, if the global
dofs of the actual element are such that:
n1 < n2 < n3 (2D) or n1 < n2 < n3 < n4 (3D)
then we have the mapping between:
0 <——> n1
1 <——> n2
2 <——> n3
(3 <——> n4, 3D)
This kind of mapping can have a positive or negative determinant. So it can be
that a clockwise element is mapped in
the reference counterclockwise one.
In libMesh we require 3D elements (as well as 2D elements, if the
library is configured --2d-only and so we can rule out 2D manifolds
curving through R3) to have positive determinants.
Where is defined (header and source with the computation) the mapping between
the reference and actual elements?
Elem::node_id(i) (in elem.h) takes local node id i (0,1,2,3 above) and
returns the global node id (n1, n2, n3, n4 above). There is never a
guarantee about the ordering of node ids, however. To obtain globally
unique orderings of edges and faces for FE types which require that,
the current procedure is: compare the nodes physical locations, and
hope the user isn't using mesh motion on this problem. Search for
"edge-flipping" in fe_hierarchic_shape_2D.C for the simplest example.
Obviously "hope the user isn't using mesh motion on this problem"
is a bug to be fixed here; the "unique_id()" facility in libMesh is
probably our best bet to change that, but that's an optional feature
at the moment, and because it noticeably adds to memory usage it will
probably remain optional-only indefinitely.
Is it defined as “counterclockwise <—>counterclockwise? If so, would be a
drastic change to define another one like
the one that I have now described?
Trying to force any particular node numbering would be a very drastic
change; we do have a "don't renumber" option for users who expect
their original mesh numbering to remain unchanged through adaptivity,
but even in that case newly created nodes have to be given new
available numberings (i.e. probably higher numbers than have been
already assigned) which may conflict with your desired ordering.
---
Roy
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
