[Fwd: Re: [Dune] ISI final suggestion]

[Andreas Dedner]

Hi
1) I would suggest to keep all the semantics of the ISI as before
   only the ++ operator does something new
2) Everywhere in our code we use the GridPart class
   grid/common/gridpart.hh
   This class allow different views on the grid. The two major
   impl. of the interface are LeafGridPart and LevelGridPart.
   THey defined IndexSetType (Level/Leaf) and
   IteratorTtype (Level/Leaf) and one begin() and end()
   method which call leafbegin/levelbegin and leafend/levelend
   on the grid. We would now add two new Methods
   ibegin(Entity&) and iend(Entity&) which return the
   appropriate ISI. The IndexSets (in the newer versions) have
   simular functinality but the GridParts are more versatile
   since I could use a different IndexSet with a LeafIterator
   (for example). Prehaps we could agree on this - or some similar
   interface. Writting a code which works for both Level/Leaf is
   simple with this approach.

Peter Bastian wrote:
> Dear all,
> 
> I have two questions concerning the separation of the intersection
> iterator:
> 
> 1) In the parallel case, it would still be such that the iterator stops
> at the processor boundary with neighbor==boundary==false ?
> 
> 2) The separation into levelwise/leafwise iterators gives rise to the
> problem how to write code that works for level and leafwise. This
> problem has to be dealt with by the user, I suppose.
> 
> Besides that, I vote for doing the change now. The solution with all
> iterators available I consider worse than leaving the iterator as it is
> because we want to present a nice interface in 1.0 and not a clumsy one.
> 
> Best,
> 
> -- Peter
> 
> 
> Christian Engwer wrote:
> 
>> Dear fellow developers,
>>
>>>   after a further discussion of the IntersectionIterator issue in our
>>> local DUNE-meeting, we decided to propose the following solution for
>>> DUNE 1.0:
>>>
>>> There should be all three intersectionIterators, i.e.
>>> IntersectionIterator, LevelIntersectionIterator,
>>> LeafIntersectionIterator, all satisfying the same interface.
>>> Thus the Entity interface provides the methods ibegin, iend,
>>> leafbegin, leafend, and levelbegin, levelend.
>>> ibegin and iend do the same as before and are not deprecated!
>>
>>
>> We also discussed this issue further and thought, that, if the
>> developers of the more complex grid consider the leaf/level version
>> easier, we should switch to this semantic in order to safe unnecessary
>> work.
>>
>> I don't consider it a reasonable solution to introduce both
>> interfaces. We should definitely agree on one option and remove the
>> other. For 1.0 We need clear interfaces. We can tell the people this
>> interface is mature, this interface might change, but we should still
>> try to present dune with a consistent and clear interface -- people
>> will judge dune by the interface they see and by the time it takes
>> them to start playing with dune.
>>
>> my 5 cents :-)
>> Christian
>>
>> _______________________________________________
>> Dune mailing list
>> Dune at dune-project.org
>> http://www.dune-project.org/cgi-bin/mailman/listinfo/dune
>>
>>
>