[Fwd: Re: [Dune] inconsistency with intersection methods]

Oliver Sander sander at mi.fu-berlin.de
Tue Oct 10 10:01:32 CEST 2006


Hi Sreejith!

What your testcase shows is not a bug.  In fact, the methods seem to
be doing precisely what they are supposed to do.  Let me explain.

You start by

> You are on Element (ID): 0
> Assumed Local Coord on the edge: 0.1

When seen from Element 0 your intersection has a coordinate system (1d),
and you pick the point 0.1.

> face_self_local: 0.9 1
> face_neighbor_local: 0.9 0

These are the coordinates of your point, once in local coordinates on
element 0, and once in local coordinates of element 1.  Since these
two coordinate systems don't have to have any relation to each other,
you can't expect the coordinate values to agree.  It is, however, the
same point and you can use the coordinates, for example, to evaluate
shape functions on the two elements.

> global coordinate of the assumed local coord when evaluated from element 
0: 0.9 0.5

And this is in fact the world position of your point.

>
> You are on Element (ID): 1
> Assumed Local Coord on the edge: 0.1

Now here is the problem.  You're doing the same procedure on the same
intersection, but seen from element 1.  It well is the same intersection,
but the interface specification doesn't guarantee you that it has the
same coordinate system.  Therefore 0.1 is _not_ the same point as
above!  And hence you don't get the same global position.

> face_self_local: 0.1 0
> face_neighbor_local: 0.1 1
> global coordinate of the assumed local coord when evaluated from element
1: 0.1 0.5


The fact that it works for SGrid is a coincidence.

Cheers,
Oliver

P.S.: In return, may I point your attention to the FlySpray tasks 181 and
182?  As far as I know the shape functions are your home turf.

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

On Mon, 9 Oct 2006, Sreejith Pulloor Kuttanikkad wrote:

>
> Dear Oliver please find the attached code and grid file.
>
> and see the output of the program
>
> for a UG Grid
> --------------
>
> UGGrid<2,2> with grid file: gridfiles/quadgrid2elms.am
>
> AmiraMesh contains 6 nodes and 2 elements
> amiraloadmesh: 2 elements created
> You are on Element (ID): 0
> Assumed Local Coord on the edge: 0.1
> face_self_local: 0.9 1
> face_neighbor_local: 0.9 0
> global coordinate of the assumed local coord when evaluated from element 0: 0.9 0.5
>
> You are on Element (ID): 1
> Assumed Local Coord on the edge: 0.1
> face_self_local: 0.1 0
> face_neighbor_local: 0.1 1
> global coordinate of the assumed local coord when evaluated from element 1: 0.1 0.5
>
> you will see that the global coordinates are different above.
>
> now see the output
>
> for a S Grid
> ------------
> You are on Element (ID): 0
> Assumed Local Coord on the edge: 0.1
> face_self_local: 0.1 1
> face_neighbor_local: 0.1 0
> global coordinate of the assumed local coord when evaluated from element 0: 0.1 0.5
> You are on Element (ID): 1
> Assumed Local Coord on the edge: 0.1
> face_self_local: 0.1 0
> face_neighbor_local: 0.1 1
> global coordinate of the assumed local coord when evaluated from element 1: 0.1 0.5
>
> now u will see that the global coord are same
>
>
> i would like to know why this is happening?
>
> thanks a lot
> sreejith
>
>
>
>
>
> On Mon, Oct 09, 2006 at 05:28:18PM +0200, Oliver Sander wrote:
>> Can you provide some actual code so I can see what you mean exactly?
>>
>> ************************************************************************
>> * Oliver Sander                ** email: sander at mi.fu-berlin.de        *
>> * Freie Universit?t Berlin     ** phone: + 49 (30) 838 75217           *
>> * Institut f?r Mathematik II   ** URL  : page.mi.fu-berlin.de/~sander  *
>> * Arnimallee 6                 ** -------------------------------------*
>> * 14195 Berlin, Germany        ** Member of MATHEON (www.matheon.de)   *
>> ************************************************************************
>>
>> On Mon, 9 Oct 2006, Sreejith Pulloor Kuttanikkad wrote:
>>
>>> somehow i feel that the test is not complete in the sense
>>> i want to know if
>>> is.intersectionGlobal().global(localCoord)
>>> gives me same global coord when evaluated from the self element and
>>> neighbor element with same localcoord (assuming same local orientation on
>>> both elms).
>>>
>>> But it turn out that in UG/alberta/alu global coord produced is different.
>>> that shouldnt
>>> be possible. so the basic question is about the local orientation when
>>> using intersection methods.
>>>
>>> i dont know if i miss something somewhere?
>>>
>>> On Mon, Oct 09, 2006 at 05:09:31PM +0200, Oliver Sander wrote:
>>>> Hi Sreejith!
>>>> I fixed that quite a while ago.  UGGrid passes that part of the test.
>>>> What exactly do you need to get working which doesn't?
>>>>
>>>> --
>>>> Oliver
>>>>
>>>> ************************************************************************
>>>> * Oliver Sander                ** email: sander at mi.fu-berlin.de        *
>>>> * Freie Universit?t Berlin     ** phone: + 49 (30) 838 75217           *
>>>> * Institut f?r Mathematik II   ** URL  : page.mi.fu-berlin.de/~sander  *
>>>> * Arnimallee 6                 ** -------------------------------------*
>>>> * 14195 Berlin, Germany        ** Member of MATHEON (www.matheon.de)   *
>>>> ************************************************************************
>>>>
>>>> On Mon, 9 Oct 2006, Sreejith Pulloor Kuttanikkad wrote:
>>>>
>>>>>
>>>>> Dear Oliver,
>>>>> I just would like to know, if your today's commits (and soon follow
>>>>> commits) is meant to solve the below issue?
>>>>>
>>>>> Thanks,
>>>>> Sreejith
>>>>>
>>>>> On Wed, Jun 28, 2006 at 09:55:42AM +0200, Oliver Sander wrote:
>>>>>> UGGrid does not comply.  I admit that it seems to be a rather important
>>>>>> feature for FV simulations, though I'd be willing to implement it
>>>>>> quickly.  Right now I don't have a clear idea of how much of a hassle
>>>>>> that will be, but it can't be too bad.
>>>>>>
>>>>>> A good test would be highly appreciated.
>>>>>>
>>>>>> --
>>>>>> Oliver
>>>>>>
>>>>>> ************************************************************************
>>>>>> * Oliver Sander                ** email: sander at mi.fu-berlin.de        *
>>>>>> * Freie Universit?t Berlin     ** phone: + 49 (30) 838 75217           *
>>>>>> * Institut f?r Mathematik II   ** URL  : page.mi.fu-berlin.de/~sander  *
>>>>>> * Arnimallee 6                 ** -------------------------------------*
>>>>>> * 14195 Berlin, Germany        ** Member of MATHEON (www.matheon.de)   *
>>>>>> ************************************************************************
>>>>>>
>>>>>> On Wed, 28 Jun 2006, Andreas Dedner wrote:
>>>>>>
>>>>>>> If thats the case, then I think we can not wait for post 1.0 - at
>>>>>>> least we should make it clear in the doku and add some warning which
>>>>>>> grids are not compliant.
>>>>>>>
>>>>>>>
>>>>>>> Peter Bastian wrote:
>>>>>>>> Andreas Dedner wrote:
>>>>>>>>
>>>>>>>>> Die Bedingung scheint mir so allerdings etwas schwach und aus
>>>>>>>>> nach der Doku der einzelnen Methoden sollte das sowieso
>>>>>>>>> rauskommen - da der Punkt in Weltkoordinaten ja auf jeden Fall
>>>>>>>>> immer der gleiche sein sollte.
>>>>>>>>>
>>>>>>>> Denke, dass genau das das Problem ist. Es folgt eben nicht aus der
>>>>>>>> Doku.
>>>>>>>> Zumindest habe ich es nicht gesehen.
>>>>>>>>
>>>>>>>> Gr??e
>>>>>>>>
>>>>>>>> -- Peter
>>>>>>>> ------------------------------------------------------------------
>>>>>>>> Peter Bastian, IWR,Uni Heidelberg, INF 348,R 020, 69120 Heidelberg
>>>>>>>> email: Peter.Bastian at iwr.uni-heidelberg.de   Tel: +49 6221 54 4984
>>>>>>>> WWW: http://www.iwr.uni-heidelberg.de/~Peter.Bastian Fax: ... 8860
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Dune mailing list
>>>>>>>> Dune at hal.iwr.uni-heidelberg.de
>>>>>>>> http://hal.iwr.uni-heidelberg.de/cgi-bin/mailman/listinfo/dune
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Dune mailing list
>>>>>>> Dune at hal.iwr.uni-heidelberg.de
>>>>>>> http://hal.iwr.uni-heidelberg.de/cgi-bin/mailman/listinfo/dune
>>>>>>>
>>>>>
>>>>>> _______________________________________________
>>>>>> Dune mailing list
>>>>>> Dune at hal.iwr.uni-heidelberg.de
>>>>>> http://hal.iwr.uni-heidelberg.de/cgi-bin/mailman/listinfo/dune
>>>>>
>>>>>
>>>>> --
>>>>> Sreejith P. Kuttanikkad
>>>>> IWR, University of Heidelberg
>>>>> Room:009, Im Neuenheimer Feld-348
>>>>> 69120 Heidelberg,Germany.
>>>>> Ph :+49-6221-54-5689/4412(Office)
>>>>> :+49-(0)17624228904(Mob)
>>>>> http://hal.iwr.uni-heidelberg.de/~sreejith/
>>>>> -------------------------------------------
>>>>>
>>>
>>>
>>> --
>>> Sreejith P. Kuttanikkad
>>> IWR, University of Heidelberg
>>> Room:009, Im Neuenheimer Feld-348
>>> 69120 Heidelberg,Germany.
>>> Ph :+49-6221-54-5689/4412(Office)
>>>  :+49-(0)17624228904(Mob)
>>> http://hal.iwr.uni-heidelberg.de/~sreejith/
>>> -------------------------------------------
>>>
>
>
> -- 
> Sreejith P. Kuttanikkad
> IWR, University of Heidelberg
> Room:009, Im Neuenheimer Feld-348
> 69120 Heidelberg,Germany.
> Ph :+49-6221-54-5689/4412(Office)
>   :+49-(0)17624228904(Mob)
> http://hal.iwr.uni-heidelberg.de/~sreejith/
> -------------------------------------------
>


More information about the Dune mailing list