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

[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