[dune-pdelab] VectorBackend, OnTheFlyOperator and storage

Fri May 10 10:50:47 CEST 2013

Hi everyone,

sorry for tuning into this discussion rather late, but after spending quite a bit of time on the Git
stuff, I wanted to put some work into my dissertation again.

As most of the changes to the backends were done by me, I wanted to add a couple of points:

> 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 :-)

This decoupling is definitely what I had in mind as well (including the ability to attach and detach
underlying ISTL objects to/from the wrappers), but I only really needed it for the vector somewhere
and forgot to also do it for the matrix. This is really a straightforward search and replace job...

>> 
>> 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.

I agree with Peter here. I took me quite a few iterations (and some input from Peter) to realize that
while we have those wrappers now, they are still wrappers in an ISTL context and we can (and have to)
make assumptions based on this fact, so we can code ISTL dependencies in there as well.

On the other hand, ISTL is templated, and the solvers really don't care what kind of data structures they
operate on, as long as they fulfill the necessary interfaces (which are pretty small at the solver level). So
I don't see the problem of having an ISTL solver operate on the container wrappers instead of the containers
themselver -  and as Peter has pointed out, as long as we rely on the grid for communication, we need the
wrapped objects in the scalar product and the preconditioner anyway.

But yes - the solver backends could really use a cleanup; I only did the absolute minimum for the port to the
new DOF infrastructure.

> 
> 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).

Again, that's true (and related to the cleanup mentioned above) - we need to settle on what we want / need to provide
as part of the public API for the wrapper objects (both on the matrix and the vector).

> 
>> 
>>  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.

Regarding shared_ptr in the matrix: Definitely, we just need a volunteer to do it… ;-)

I don't think the constness thing is much of an issue: Once the matrix is moved to shared_ptr,
the wrappers only contain pointers to the ISTL objects, and we can just keep those non-const
all the time (including being able to get a shared_ptr to the non-const underlying object from
const wrappers). Yes, I know it's ugly, but I think users will almost always interact with the wrappers
in their main driver routine, where the matrix / vector isn't const anyway.

That said, it should be possibly to simply switch off mutators based on the constness of the ISTL type
(by splitting them off into a mixin class that the wrapper only conditionally inherits from). You don't need
two shared_ptr, at least not for the full-fledged implementations from the standard library and ISTL, they
offer an automatic cast shared_ptr<T> -> shared_ptr<const T>. I don't know whether our own
implementation can do that though (would be another reason to bump the PDELab baseline to GCC 4.3…).

Steffen

> 
> 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
> 
> _______________________________________________
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dune-project.org/pipermail/dune-pdelab/attachments/20130510/9cae0ab6/attachment.sig>