[Dune] grid.geometry is a bit restrictive

Christian Engwer christian.engwer at uni-muenster.de
Fri Feb 27 15:44:27 CET 2015


On Fri, Feb 27, 2015 at 03:41:52PM +0100, Aleksejs Fomins wrote:
> Dear Christian,
> 
> So do I understand correctly that you suggest to use getRealImplementation on user side to get the extra methods of the underlying grid.geometry() implementation? I think this would work too
> 
> Anyway, I think it would be a good idea to open a feature request. I will explain what methods I provide and why I believe they are useful to the user, and then you people can decide on whether you want to add some of them to the main interface or keep them to the auxiliary interface.
> 
> Could you please briefly explain how to open a feature request?

Add a flyspray issue and mark it as "feature request".

Christian

> 
> Thanks,
> Aleksejs
> 
> 
> On 27/02/15 15:34, Christian Engwer wrote:
> > Dear Aleksejs,
> > 
> > On Fri, Feb 27, 2015 at 12:06:16PM +0100, Aleksejs Fomins wrote:
> >> Dear Dune,
> >>
> >> I just realised that CurvilinearGeometry has quite a few new user methods compared to linear geometries, for example, access to interpolation vertices, interpolation polynomials and functions thereof. The wrapper interface of grid.geometry class does not allow for adding these additional methods, so they will need to be accessed some other way.
> >>
> >> I have decided to provide a grid method grid.basegeometry(entity),
> >> which would directly return the Dune::CurvilinearGeometry class, and
> >> not its grid wrapper. I realise that this goes against the paradigm of
> >> "protecting the users from themselves", but I do not see a good
> >> alternative at the moment.
> > 
> > There is the method grid.getRealImplementation(...) which returns the
> > implementation hidden in the facades class. My advice is not to add your
> > new method on the grid, as it is just a more specific version of the
> > getRealImplementation method.
> > 
> > Besides this... why do you need these additional methods? If you
> > consider them necessary, please open a feature-request and let
> > everybody discuss this topic. I havent worked a lot with higher order
> > transformations, but I never had the need to access these additional
> > information from user code.
> > 
> > Christian
> > 
> >>
> >> Regards,
> >> Aleksejs
> >>
> >> _______________________________________________
> >> Dune mailing list
> >> Dune at dune-project.org
> >> http://lists.dune-project.org/mailman/listinfo/dune
> >>
> > 
> 

-- 
Prof. Dr. Christian Engwer 
Institut für Numerische und Angewandte Mathematik
Fachbereich Mathematik und Informatik der Universität Münster
Einsteinstrasse 62
48149 Münster

E-Mail	christian.engwer at uni-muenster.de
Telefon	+49 251 83-35067
FAX		+49 251 83-32729



More information about the Dune mailing list