[Dune] Changes in the grid paper

[Andreas Dedner]

was du doch zum einen brauchst ist ein Indexset, der zu jeder LeafEntity
(codim=0) mit l<Lmax noch Indizies generiert f\"ur die
Levels l+1,..,lmax?
Der Leveliterator fuer ein Level q
muss dann auch auf den Entitaeten halten mit level()<q, den
Index hast du dann im Indexset...

Ich denke der Iterator ist verhaeltnissmaessig leicht zu basteln
(etwa level0 + hierarchicIter oder sowas). Der Indexset muss halt
generiert werden. Ich weiss nicht was du genau brauchst -
Kontenindizes? LevelIntersectionIterator?
Sicherlich ist ein Problem der LevelIntersectionIterator auf
den gefakten Kopien - da ist im Dune Interface nichts zu machen, glaub
ich...

EntityPointer sind nach Doku nicht Default-Konstr., oder hab ich da
was falsch im Kopf. Deine Impl. muss doch irgentwie auch anders
gehen etwa mit vector.push_back() oder so was?

So viel faellt mir erstmal ein...
Gruss Andreas



Oliver Sander wrote:
> Guten Morgen!
> I'm happy to hear you guys seem to agree with me on that issue.
> 
> Instead of SGrid I may as well use YaspGrid, I guess.  I need
> one feature I did not mention so far:  default constructibility
> of the EntityPointer.  I added that to SGrid without any problems
> and will commit that later today.
> 
> What I would really like to use, though, is ALUGrid, because
> that would show that we're really able to force two different
> legacy codes under one hood.  Enhancing one legacy grid manager
> with code for a uniform grid isn't quite as exciting.  Besides,
> I find those nonconforming grids pretty sexy.
> 
> I mentioned the problems.  Can you guys from Freiburg see ways
> around?  I need the default-constructible EntityPointer, and
> I need the LeafLevel to be identical to the highest horizontal
> level.  Is it possible to simply copy elements in ALUGrid onto
> the next higher level?  I may also be able to change my code
> such that it only assembles on the leaf level and then solve
> with a black-box inner-point solver instead of my multigrid.
> The IP solver gets pretty slow, though, on non-small problems,
> so I cannot really guarantee this is going to work well.
> 
> Greetings,
> 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 Thu, 27 Jul 2006, Peter Bastian wrote:
> 
>> Oliver Sander wrote:
>>
>>> Dear Grid Paper Writers!
>>> As you all know I was working on a particular example to be included
>>> in our upcoming paper.  It was to consist of a linear elasticity
>>> problem on a crankshaft geometry, to be computed with UGGrid,
>>> AlbertaGrid,
>>> and ALUGrid.  However, I have grown more and more unhappy with this
>>> example, because it doesn't demonstrate anything that hasn't been
>>> shown already in the paper.  Thus, after some debate with HD, I have
>>> now decided to submit a different example for the paper.  It will be
>>> a linear elastic two-body contact problem, with two different grid
>>> implementations for the two bodies.  This will show that it is
>>> possible to have different grid implementations at the same time.
>>> As, unfortunately, my code needs grids that can assure that the
>>> grid leaf level is identical to the highest horizontal level I
>>> will most likely use a combination of UGGrid and SGrid.
>>>
>> I think that this is a good point to illustrate. Why not YaspGrid?
>>
>> -- 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 dune-project.org
> http://www.dune-project.org/cgi-bin/mailman/listinfo/dune