[Dune-devel] New GridView stuff fails test-geogrid
Dr. Olaf Ippisch
olaf.ippisch at iwr.uni-heidelberg.de
Mon Nov 18 10:13:01 CET 2013
Dear Martin,
we discussed this matter in Heidelberg some weaks ago, before the last
developer meeting. How about making the respective grid methods private
and keeping the default implementation. That would achieve what you want
(keeping the interface slim) at virtually no cost...
Best regards,
Olaf
Am 18.11.13 10:09, schrieb Martin Nolte:
> Hi Oli,
>
> well, then we must have misunderstood each other. Somehow I understood
> that the Dune interface is supposed to be slim. In other words: We do
> not duplicate interfaces. Therefore, it was clear to me (~5 years ago)
> that at some point, one of the two interfaces has to disappear.
> Moreover, it is my impression that most user codes have successfully
> migrated to the grid views. It is only consequent to take the grid
> implementations to this level, too, by removing the old interfaces. We
> already deprecated Entity::i*begin / i*end and decided to deprecate
> Grid::lbegin/lend/leafbegin/leafend. Reading the above again, I am a
> little surprised at you statement.
>
> As a side note: The first step to implementing the grid views is just
> copying the default grid views and renaming them. Once you have done
> this, you can start to clean up the grid code by migrating the native
> implementations to the grid views. If the grid is well-implemented, it
> should just be a matter of a few hours. But obviously I am the only one
> who did bother until now.
>
> Anyway, I did not suggest do remove the default implementation. I merely
> suggested to remove grid view construction methods leafGridView and
> levelGridView (not their deprecated counterparts - they belong on a
> default implementation) from the GridDefaultImplementation. It think the
> code duplication of these small methods is bearable and FS#1390 shows
> that they can do harm. The reason is that the default implementation
> might be plain wrong, if the grid does not use the default view
> implementations, in which case they may never be called. For me, this
> violates the principle of least surprise.
>
> I hope this lengthy letter clarifies my point of view a little. Of
> course, my personal views are not binding at all.
>
> Best,
>
> Martin
>
> PS: Any offense that could be taken is unintended and just expresses my
> surprise about the current situation.
>
> On 11/18/2013 09:36 AM, Oliver Sander wrote:
>> I agree. In fact I didn't even know until very recently that I am
>> supposed to
>> implement the views for the grids I maintain. Plus, that doesn't
>> appear to be
>> mentioned anywhere. Near the leaf/levelView methods in
>> GridDefaultImplementations
>> it certainly doesn't say "will disappear eventually" or something
>> along those
>> lines.
>> Which doesn't mean I necessarily object to removing the defaults.
>> Cheers,
>> Oliver
>>
>> Am 18.11.2013 08:12, schrieb Dr. Olaf Ippisch:
>>> Dear Martin,
>>>
>>> I do not completely agree with your view. In my opinion it does not make
>>> sense, that the same working code is duplicated for each grid. I thought
>>> the basic idea of default implementations is to just reimplement the
>>> code if the default implementation is to slow or not applicable.
>>>
>>> Best regards,
>>> Olaf
>>>
>>> Am 16.11.13 15:13, schrieb Martin Nolte:
>>>> Hi Christoph,
>>>>
>>>> this is really yet another unnerving bug that could have been
>>>> avoided by
>>>> proper testing.
>>>>
>>>> The root of the problem is that GeometryGrid and AlbertaGrid are (to my
>>>> knowledge) the only grid implementations in dune-grid that natively
>>>> implement their grid views. All other grids just use the "default"
>>>> implementation, which was introduced as a compatibility measure. Even
>>>> worse, the methods leafView and levelView on the
>>>> GridDefaultImplementation were introduced (~5 years ago) so that grid
>>>> implementors don't directly have to change their code. Seemingly,
>>>> developers are lazier than I thought ;-).
>>>>
>>>> In order to enforce migration to the "new" 5 year-old interface, I
>>>> think
>>>> we should deprecate the methods leafView, leafGridView, levelView,
>>>> levelGridView on the GridDefaultImplementation.
>>>>
>>>> Anyway, I'll have a look at the problem as soon as I find the time.
>>>> Could you please post a proper bug report?
>>>>
>>>> Best,
>>>>
>>>> Martin
>>>>
>>>>
>>>> On 11/16/2013 01:52 PM, Christoph Grüninger wrote:
>>>>> Hi guys,
>>>>> test-geogrid currently fails in the new LeafGridView code of
>>>>> the GridDefaultImplementation, see compiler output below.
>>>>>
>>>>> Bye
>>>>> Christoph
>>>>>
>>>>> In file included from test-geogrid.cc:4:
>>>>> In file included from ../../../config.h:354:
>>>>> In file included from ../../../dune/grid/yaspgrid.hh:18:
>>>>> ../../../dune/grid/common/grid.hh:1058:19: error: no matching
>>>>> conversion for
>>>>> functional-style cast from 'const GridImp' (aka 'const
>>>>> GeometryGrid<Dune::YaspGrid<2>,
>>>>> Dune::IdenticalCoordFunction<double, 2>,
>>>>> std::allocator<void>
>>>>>> ') to 'ViewImp' (aka 'GridView<HostGridView,
>>>>> Dune::IdenticalCoordFunction<double, 2>, std::allocator<void>,
>>>>> (Dune::PartitionIteratorType)4U>')
>>>>> return View(ViewImp(asImp()));
>>>>> ^~~~~~~~~~~~~~~
>>>>> ./gridcheck.cc:598:33: note: in instantiation of member function
>>>>> 'Dune::GridDefaultImplementation<2, 2, double,
>>>>> Dune::GeoGrid::GridFamily<Dune::YaspGrid<2>,
>>>>> Dune::IdenticalCoordFunction<double, 2>, std::allocator<void>
>>>>>>> ::leafView' requested here
>>>>> LeafGridView leafGridView = g.leafView();
>>>>> ^
>>>>> ./gridcheck.cc:886:3: note: in instantiation of function template
>>>>> specialization
>>>>> 'iteratorEquals<Dune::GeometryGrid<Dune::YaspGrid<2>,
>>>>> Dune::IdenticalCoordFunction<double, 2>,
>>>>> std::allocator<void> > >'
>>>>> requested here
>>>>> iteratorEquals(g);
>>>>> ^
>>>>> test-geogrid.cc:84:3: note: in instantiation of function template
>>>>> specialization
>>>>> 'gridcheck<Dune::GeometryGrid<Dune::YaspGrid<2>,
>>>>> Dune::IdenticalCoordFunction<double, 2>,
>>>>> std::allocator<void> > >'
>>>>> requested here
>>>>> gridcheck( geogrid );
>>>>> ^
>>>>> test-geogrid.cc:131:3: note: in instantiation of function template
>>>>> specialization 'test<Dune::GeometryGrid<Dune::YaspGrid<2>,
>>>>> Dune::IdenticalCoordFunction<double, 2>,
>>>>> std::allocator<void> > >'
>>>>> requested here
>>>>> test<GeometryGrid>(gridfile);
>>>>> ^
>>>>> ../../../dune/grid/geometrygrid/gridview.hh:27:11: note: candidate
>>>>> constructor
>>>>> (the implicit copy constructor) not viable: no known conversion from
>>>>> 'const GridImp' (aka 'const GeometryGrid<Dune::YaspGrid<2>,
>>>>> Dune::IdenticalCoordFunction<double, 2>, std::allocator<void>
>>>>>> ') to 'const
>>>>>
>>>>> Dune::GeoGrid::GridView<Dune::GridView<Dune::DefaultLeafGridViewTraits<const
>>>>>
>>>>>
>>>>> Dune::YaspGrid<2>, 4> >, Dune::IdenticalCoordFunction<double, 2>,
>>>>> std::allocator<void>, 4>' for 1st argument
>>>>> class GridView;
>>>>> ^
>>>>> ../../../dune/grid/geometrygrid/gridview.hh:115:7: note: candidate
>>>>> constructor
>>>>> not viable: requires 2 arguments, but 1 was provided
>>>>> GridView ( const Grid &grid, const HostGridView
>>>>> &hostGridView )
>>>>>
>>>>> _______________________________________________
>>>>> Dune-devel mailing list
>>>>> Dune-devel at dune-project.org
>>>>> http://lists.dune-project.org/mailman/listinfo/dune-devel
>>>>
>>>
>>
>>
>>
>>
>> _______________________________________________
>> Dune-devel mailing list
>> Dune-devel at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune-devel
>>
>
--
Dr. Olaf Ippisch
Universität Heidelberg
Interdisziplinäres Zentrum für Wissenschaftliches Rechnen
Im Neuenheimer Feld 368, Raum 4.24
Tel: 06221/548252 Fax: 06221/548884
Mail: Im Neuenheimer Feld 368, 69120 Heidelberg
e-mail: <olaf.ippisch at iwr.uni-heidelberg.de>
More information about the Dune-devel
mailing list