[Dune] Status of 2.0 release

[Oliver Sander]

Hi Christian!
Actually, the problem you describe in the second paragraph is not the
reason why UGGrid throws the exception.  It is not, because when you
explicitly insert a parametrized boundary segment in UGGrid you
implicitly define the local coordinate system there.  The local coordinate
system induced by its embedding in the element doesn't matter.

The real reason for the exception is the following.  When setting up a
grid, UG needs to set up a list of all edges of the grid boundary.
This used to be done by a quadratic algorithm that I had to replace
because it was taking too much time.  The new algorithm works as follows:
Loop over all boundary segments, and for each boundary segment loop
over all its edges.  Then you get each boundary edge twice.  How do
you store each edge *once*?  Edges do not have indices, hence you cannot
simply look up in a bit field whether a given edge has been visited already.
You could use an associative array, but UG is a C code, hence there is
no standard library.  My solution was this: If you know that the boundary
segments are consistently oriented, then you will see each edge once
as (a,b) and once as (b,a).  Store it if the first vertex has a smaller 
number
than the second one.  Disregard it otherwise. 

All this takes place in the method BVP_Init in ug/dom/std/std_domain.c,
for those who want to see it. It is a fast, simple solution, and I thought
that assuming a consistent boundary orientation was reasonable.
I am not sure anymore.  I guess the best solution to the problem would
be to replace my algorithm in BVP_Init by something else that was still
linear but would not rely on a consistent boundary.  However so far all
ideas I had were fairly involved (i.e. associate maps etc).

best,
Oliver

Christian Engwer schrieb:
> Dear all,
>
>   
>> * What is the status of the gmsh-reader/UG problem? Is there a fix
>>   that could be backported?
>>     
>
> I have discussed this problem with Dan. It seems that working
> boundaryprojections are out of sight atm (at least for the gmsh
> reader). The problem is that the mapping between reference face and
> the boundarysemnet differs from the mapping between reference face and
> the face-in-the-cell-sub-entity. They have a different orientation.
>
> UG does complain that the orientation is wrong and throws an
> exception. The other two grid managers accept the file. My main
> concern is, if they handle the segments correctly. As I undestand the
> problem in UG, it is that you have to specify a point local
> coordinates of the boundary segment. If this point is wrong, the whole
> projection is wrong. Might this problem occure in ALU or Alberta
> aswell?
>
> In order to get at least the linear boundary segments working again,
> it would be necessary to add the insert-method with only the vertex
> parameter to alugrid and alberta. I think if we move the
> lineaboundaryegment-default Implementation to the boudanrysegemnt
> header this fix would be really easy.
>
> All reamining issues must be documented in the release_notes.
>
> Christian
>
>
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune
>   


-- 
************************************************************************
* Oliver Sander                ** email: sander at mi.fu-berlin.de        *
* Freie Universität Berlin     ** phone: + 49 (30) 838 75348           *
* Institut für Mathematik      ** URL  : page.mi.fu-berlin.de/~sander  *
* Arnimallee 6                 ** -------------------------------------*
* 14195 Berlin, Germany        ** Member of MATHEON (www.matheon.de)   *
************************************************************************