[dune-pdelab] [dune-pdelab-commit] dune-pdelab r1521 - trunk/dune/pdelab/gridfunctionspace

[Steffen Müthing]

As there don't seem to be any strong objections to this change, I will commit it. If a problem
does turn up later on, reverting it should be no problem -  the change is pretty localized.

Steffen


Am 16.06.2011 um 17:14 schrieb Steffen Müthing:

> 
> Am 16.06.2011 um 16:01 schrieb Jö Fahlke:
> 
>> Am Thu, 16. Jun 2011, 11:18:50 +0200 schrieb Steffen Müthing:
>>> Am 15.06.2011 um 18:34 schrieb Jö Fahlke:
>>> 
>>>> Am Wed, 15. Jun 2011, 17:11:31 +0200 schrieb muething at conan.iwr.uni-heidelberg.de:
>>>>> Log:
>>>>> [Ordering] Make the orderingPtr() method const for consistency with the ordering() method
>>>> 
>>>> Not a good idea.  This change means you now can modify internal data of a
>>>> const CompositeGridFunctionSpace.  To illustrate: to make the change really
>>>> consistent you would need to write (note the const in the template argument to
>>>> shared_ptr)
>>>> 
>>>>    const shared_ptr<const Ordering> &orderingPtr() const { return orderingp; }
>>>> 
>>>> But that would probably introduce a lot of compilation errors.
>>>> 
>>> 
>>> You are right, it's not really pretty... but the problem is that during the transformation, I only
>>> get a const reference to the GFS that I want to extract the ordering from, so this slight
>>> inconsistency seemed like the easiest way around that issue.
>> 
>> Well, you can simply have both the const and the non-const version:
>> 
>> const shared_ptr<Ordering> &orderingPtr() { return orderingp; }
>> const shared_ptr<const Ordering> &orderingPtr() const { return orderingp; }
>> 
>> Or do you really need to modify internal data of a const GridFunctionSpace?
> 
> As I said, it is more of a hack - I have a writable pointer to the GridFunctionSpaces available in the
> constructor of the CompositeGridFunctionSpace, from which I invoke the transformation; but since
> the transformation algorithm treats the source tree as const, I can only access them as const. One
> way around that would of course be a variant of TransformTree that takes the source tree as a
> non-const reference, but that would almost double the size of the algorithm, and I like the functional
> nature of the current, const-only version.
> 
>> 
>>> 
>>> Thinking about it: Perhaps an Ordering only needs read-only access to its children when
>>> used in conjunction with a GFS? I mean, it probably shouldn't tinker with that data anyway...
>>> Making the children const  doesn't break anything in PDELab itself as far as I can see, but
>>> perhaps I overlooked something obvious or someone sees a problem in a possible future
>>> use case?
>> 
>> There is the issue of how the update() call after a grid adaption propagates
>> down the tree, and in particular which tree it uses to propagate.
>> 
> 
> Right now, that is done on the GFS tree, and since the leaf GFS implementations have internal
> data that changes when calling update(), it is currently not possible to move the propagation to
> the Ordering tree.
> That said, I'm starting to wonder whether a GFS should expose its Ordering object in a writable
> way at all - it forms part of its internal implementation, and messing around with it could cause
> inconsistent state, irrespective of whether the GFS is writable or not.
> 
> So I would propose to:
> 
> 1) Only allow read-only access to the Ordering contained in a GFS
> 2) Following the above reasoning, store const references to the child Orderings in non-leaf
>   GridFunctionSpaces. That way, any updates will have to pass through the child GFS objects,
>   so that no inconsistencies can arise.
> 
> Note that this does not limit the usability of standalone Ordering trees. Those are built by the
> user, who can easily decide to make the children of a Composite-/PowerOrdering accessible
> in a writable fashion.
> 
> Steffen
> 
>> Bye,
>> Jö.
>> 
>> -- 
>> In the shower, time can be measured only by the fluctuations of the
>> temperature.
> 
> Steffen Müthing
> Universität Stuttgart
> Institut für Parallele und Verteilte Systeme
> Universitätsstr. 38
> 70569 Stuttgart
> Tel: +49 711 685 88429
> Fax: +49 711 685 88340
> Email: steffen.muething at ipvs.uni-stuttgart.de
> 
> 
> 
> 
> 
> 
> _______________________________________________
> dune-pdelab mailing list
> dune-pdelab at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-pdelab

Steffen Müthing
Universität Stuttgart
Institut für Parallele und Verteilte Systeme
Universitätsstr. 38
70569 Stuttgart
Tel: +49 711 685 88429
Fax: +49 711 685 88340
Email: steffen.muething at ipvs.uni-stuttgart.de