[dune-pdelab] Interface changes for containers in LocalOperator

[Felix Heimann]

Hi Everybody,

I like this proposal. However, some methods (like etadd in the local
assembler base class) do not use the localIndex() method, because - so
far - they are always called for the root lfs. Does anyone have ideas
about why this might change in future? Otherwise it might be a good idea
to provide the local vectors and matrices with an additional method
(using a cautioning name) that allows the former [i], i.e., (i,j) access
without the local function spaces. 

Anyway, I dont expect it to make much of a run-time difference. So, from
my side @Steffen, feel free to commit...

Best,
Felix

Am Mittwoch, den 09.03.2011, 10:54 +0100 schrieb Steffen Müthing:
> Dear PDELab developers,
> 
> in order to simplify the implementation of the new GridOperator assemblers and to
> clarify the purpose of the residual / jacobian containers, we already changed the interface
> of the residual and jacobian containers in the trunk of PDELab. As these changes will
> require some minor changes to all local operators anyway (to silence the torrent of
> deprecation warnings), Christian and I yesterday thought about taking the change a
> little further.
> 
> Right now, you always have to remember to call localIndex() on the correct LFS and
> to only use the translated index to access the container. In our opinion, there are
> three problems with that:
> 
> 1) A user can easily forget the call, causing his local operator to assemble nonsense.
> 2) It is possible (and not exactly rare) to use the localIndex() method from the wrong
>    function space to access a container. As most of our schemes are of Galerkin type,
>    this usually doesn't matter, but if the two function spaces really differ, it is another
>    source of subtle bugs.
> 3) All those localIndex() calls really clutter up the code - I especially noticed that when
>    porting the numerical differentiation classes to the new, weighted residual and jacobian
>    containers.
> 
> Christian and I now came up with the idea that what you actually want to do when accessing
> a container in a LocalOperator is to retrieve or write a value associated with DOF i of some
> local function space lfs. By adjusting the interface of the containers to reflect that notion,
> we get rid of all three problems noted above. The new interface would look like this:
> 
> access to vector: x(lfsu,i)
> access to matrix: jac(lfsv,i,lfsu,j)
> accumulate residual: x.accumulate(lfsu,i,value)
> accumulate jacobian: jac.accumulate(lfsv,i,lfsu,j,value)
> 
> The new containers would also still allow access to the underlying raw containers using
> a common interface method like base().
> 
> Moreover, we would initially keep the existing access methods (operator[] for the vector and two-argument
> operator() for the matrix), but deprecate them.
> 
> I implemented that change and encountered no real problems (apart from the flood of deprecation
> warnings), but haven't committed anything yet. Are there any objections or ideas for improvement?
> 
> Steffen
> 
> 
> 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

-- 
Felix Heimann
Universität Heidelberg
Interdisziplinäres Zentrum für Wissenschaftliches Rechnen
Arbeitsgruppe Paralleles Rechnen
IWR 368, Raum 422
Tel: 06221 / 54 8881