[dune-pdelab] VectorBackend, OnTheFlyOperator and storage

[Peter Bastian]

Am 05.05.2013 um 00:33 schrieb Christian Engwer <christian.engwer at uni-muenster.de>:

> Hi all,
> 
> a) I missed some of the recent changes due to git trouble on my
>   machine :-(
> 
>   So the nice thing is that my suggestion of using shared_ptr to
>   decouple the wrapper from the storage is already implemented :-)
> 
> b) the OnTheFlyOperator (and istl) using the wrapper instead of the
>   underlying container (i.e. ISTL vector) is still a design flaw
>   imo. It only works because me mimic all ISTL interfaces on the
>   wrapper, but what if I want to use an on the fly operator for an
>   other LA library?
Christian, I don't get it. The OnTheFlyOperator implements an ISTL
concept (LinearOperator) and is used together with ISTL Solvers.
That is why it is in the seqistlsolverbackend.hh. The only flaw is the
name of the class which should better be ISTLOnTheFlyOperator.
If you want on the fly solution with, say, PetSc then you have to wrap
the grid operator evaluation into some class that is usable by the 
PetSc solvers. It was never meant to be reused with another LA
implementation.

The real flaw imo currently is that it is not clear which functionality on
the VectorContainer is really the interface to PDELab (besides
the access, e.g. we use +=, this is the functionality that is to be
implemented for other LA libraries) and which functionality is only
used by the istl solver backends (that is ok, because the solver
backends know that it is a container wrapping an ISTL object. And this
need not be implemented in case of other LA libraries).

> 
>   When we want to do this, we habe to be able to create wrappers from
>   containers. This is partially possible using the attach and detach
>   methods of the wrapper. Things become difficult if we only want
>   read-only access and the container is also const... how can we
>   create a wrapper from a const reference? Currently this is not
>   possible. What worked for me, but is also not too nice, is
>   splitting the wrapper into a mutable and const part (two distinct
>   classes) and having two shared_ptr objects, one in each class. Does
>   anybody have a better idea?
> 
> Regarding the matrix class, I suggest to use the same approach as for
> the vector and move the container into a shared_ptr which gives more
> flexibility.
agreed.

Best,

Peter


> 
> Ciao
> Christian
> 
> On Sat, May 04, 2013 at 09:09:24PM +0200, Peter Bastian wrote:
>> 
>> Am 04.05.2013 um 17:56 schrieb Christian Engwer <christian.engwer at uni-muenster.de>:
>> 
>>> 
>>> 
>>> 
>>> -------- Ursprüngliche Nachricht --------
>>> Von: Christian Engwer <christian.engwer at uni-muenster.de>
>>> Gesendet: Sat May 04 17:43:59 MESZ 2013
>>> An: Peter Bastian <peter.bastian at iwr.uni-heidelberg.de>
>>> Betreff: Re: [dune-pdelab] VectorBackend, OnTheFlyOperator and storage
>>> 
>>> Hi Peter,
>>> 
>>>>> c) Oliver asked we, why it is not possible to create an ISTL Matrix
>>>>> and then later use PDELab to fill this matrix. While we completely
>>>>> stay in the PDELab context one might argue that this is not
>>>>> necessary and even the wrong approach, I think in situations where
>>>>> we mix different codes Oli has a point. If we implement (b) and
>>>>> then don't store the matgrix obect directly in the backend, but use
>>>>> a shared_ptr, we could easily allow the user to allocate the matrix
>>>>> before hand and then warp this matrix in a backend container.
>>>> Such a possibility is clearly something one should have. I just
>>>> committed
>>>> a constructor on the matrix backend yesterday that allows you to
>>>> initialize a MatrixContainer with a given ISTL Matrix (instead of
>>>> a grid operator). In my case this 
>>>> is the triple product A_C = R A_DG A^T which is constructed using ISTL
>>>> but is then later to be used within PDELab (e.g. to insert essential
>>>> boundary
>>>> conditions).
>>> 
>>> I saw your commit and one thing that striked me, is that the matrix is actually copied... One thing I'd like to avoid…
>> 
>> Thats true, I just copy an empty matrix and then fill this matrix, when it is
>> in the container. I will change it such that just a MatrixContainer with an
>> empty ISTL matrix is constructed. That will work for me, but it is clear that
>> it is only a partial solution.
>> 
>> -- Peter
>> 
>> ------------------------------------------------------------
>> Peter Bastian
>> Interdisziplinäres Zentrum für Wissenschaftliches Rechnen
>> Universität Heidelberg
>> Im Neuenheimer Feld 368
>> D-69120 Heidelberg
>> Tel: 0049 (0) 6221 548261
>> Fax: 0049 (0) 6221 548884
>> email: peter.bastian at iwr.uni-heidelberg.de
>> web: http://conan.iwr.uni-heidelberg.de/people/peter/
> 
> -- 
> 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