[Dune] Comment to task #120.

Andreas Dedner dedner at mathematik.uni-freiburg.de
Wed Oct 18 19:06:46 CEST 2006


Hi,
in 3d the problem is even greater and i'm sure
will find no reasonable way to fix the problem in n-d. -
and not for 1.0 is my opinion.
For alugrid we fixed the whole think with the following - using
static variables (vgl. grid/alugrid/3d/topology.cc line 80ff

  template <>
  const int ElementTopologyMapping<hexa>::
  dune2aluFaceVertex_[numFaces][numVerticesPerFace] = {{0, 3, 1, 2},
                                                       {0, 1, 3, 2},
                                                       {0, 1, 3, 2},
                                                       {1, 0, 2, 3},
                                                       {0, 3, 1, 2},
                                                       {0, 1, 3, 2}};

In 2d it would look simple and one would use:
  dune2OrientedFace[i][j]
to get exactly the numbering you need for the correct normal vectors...

This could be easily added to grid/utility for 2d and 3d (and 4d and 5d
and so one if somebody needs it)

Andreas

PS: the twistutility.hh would not help in this case...




Oliver Sander wrote:
> Hi Robert!
> 
>>
>>> Secondly it's not that all normals of the reference quad
>>> point outwards while they should point inwards.  The
>>> problem is that _some_ point outwards and _some_ inwards.
>>> Of course I know which do which, and I can write code
>>> like
>>> if (subface==1 || subface==3)
>>>   // reorient face
>>
>>
>> if that is the problem then I suggest to add a method to the reference
>> elementes to return 1.0 or -1.0 depending on the normal pointing outward
>> or inward. By multiplying with this factor, one always get a outward (or
>> maybe inward) pointing normal for each face. The we have to change
>> nothing of our exsiting code and we solve this problem too. Also this
>> factor tell you the orientation of this face and you can take care of it
>> in your code.
> 
> 
> That would not really help much.  If I needed the actual outward
> normals I would simply call the corresponding method of the
> IntersectionIterator.  However, I need the grid boundary as a
> consistently oriented subgrid, so an external library can do
> whatever with it.  So I'd still need an 'if'-clause like the
> one above, and since I already know, which faces are incorrectly
> oriented (faces 0 and 3), supplying that same information
> in form of a double doesn't really help.
> 
> 
>> Besides orientation of faces is, what a TwistUtility is good for.
>> Andreas will comment that piece of code.
>>
> 
> Great!  I'm very curious!
> 
> Oliver
> 
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://www.dune-project.org/cgi-bin/mailman/listinfo/dune




More information about the Dune mailing list