[Dune] Re: Bemerkung Gitter und Gitterhierarchie.

[Robert Kloefkorn]

Hi Oli,

> I guess I was being imprecise again.  Hierarchic structure is
> very useful when you implement multigrid or adaptive methods.
> However the people who do that are a minority.  A very large
> fraction of FE people are either analysts who use a single grid
> to define their fe space on or engineers who start ABAQUS and
> don't really care about how it is implemented.
> Much of the adaptivity
> literature always speaks about 'sequences of grids' and doesn't
> touch the question on how you relate them to each other.
> So in the mind of all these people a grid is a flat structure,
> and really the only ones how think in hierarchies are the multigrid
> people and implementors of adaptive algorithms.
So that's one point to add then. I would agree to the Hierarchy of Grids 
if one could extract a certain Grid that then would have a begin and end 
  iterator, and only that iterators, to iterate over it's elements. But 
that is not the case, because then one must have a level wise pointer 
list of elements or something similar. In the case a grid __only__ has a 
hierarchic pointer structure (Alberta, ALUGrid,...) then such grids 
would have to store the hole grid (grid hierarchy) and could not live 
separately. That is why I my world such objects are only views (what you 
call a grid) to make clear that they cannot exist without the hole Grid 
(grid hierarchy).

> In any case this is how text books on finite-element methods
> introduce grids.
The text books grids are introduced in a way that is best to describe 
the finite element method. It is not taken care of what a general grid 
definition could be and so on. I think like all those text books we 
should define a Grid what we want that a Grid should be.


> I don't understand.  Why don't you want to take the definition
> of a simplex from some other paper?  What's wrong with them?
No, I meant that if the definition is appropriate for us then
we should use it, but we should not try to fit our work in a
framework that was defined for other purposes. Also Dune is not
just another FE software package. It claims to be more general so
I guess we can come up with a slightly different definition of
what a grid is.


> I think my proposal _is_ implemented in the code.
> If you ask the the answer is that the Grid class is inappropriately
> named.  In my opinion it should be called GridHierarchy, because
> that is what it is (no I am NOT proposing to actually change the
> name).  You get access to the separate grids (which exist conceptually,
> even if not as c++ objects) through the LevelIterators.  That was the
> original design idea. 
Maybe it was the original idea of Peter. And it was the first thing to 
include LeafIterators. So I do not see the point. Either iterator would 
have been missing. That's why we have them both.

But like above. I think we don't see the things very different. What I 
just want to say is, that we should make the definitions such that one 
easily will find the corresponding class in the code. If we have to 
explain every time, that with GridHierarchy we actually mean Grid then 
everybody gets confused. Of course one then maybe has to adjust that 
definitions to a certain definition from a finite element book. But that 
is just not our problem. Because there are plenty of definitions, we 
cannot be everybody's darling. Therefore we should make sure that our 
definitions fit to our implementations.

Cheers

Robert