[dune-pdelab] VectorBackend, OnTheFlyOperator and storage

[Christian Engwer]

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?

   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.

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