[dune-pdelab] Howto updat backend?

[Christian Engwer]

Hi Steffen,

I thought I could recycle the stl-vector backend. Is it gone? I think
we could add some support for "simple" backends, like flat containers
and CRS matrices with three vectors. These are formats which are
supported by many third party libs and thus such helper classes would
significantly reduce the work to add an other backend. If the
stl-vector backend isn't there anymore I'll try to rewrite my matlba
backend and then we can factor out the respective parts.

Christian

On Sun, May 19, 2013 at 04:43:19PM +0200, Steffen Müthing wrote:
> Hi Christian,
> 
> Am 18.05.2013 um 22:03 schrieb Christian Engwer:
> 
> > Hi Steffen,
> > 
> > could you give some hints on how to update en existing backend
> > (vector) or is it best to just strt from scratch again?
> 
> I don't think updating is a very viable strategy, I'm afraid. Your best bet right
> now is probably to just take the ISTLBlockVectorContainer as a template and replace
> the few bits that are actually ISTL-specific (and throw out all of the helper code around the
> actual class that makes up more than half of that header file). Make sure to keep the nested
> View classes, those are required by the interface. The default DOF infrastructure will always
> give you MultiIndices for your ContainerIndices, so even if you use flat indexing, you will need to
> index into position 0 when extracting the index value to pass on to the underlying LA library.
> 
> After that, you need to write a working set of Backend descriptors (the types / objects you stuff
> into the GridFunctionSpaces, like ISTLVectorBackend). What these things look like really depends
> on your backend, but they have to export a typedef 'size_type' and need a public method blocked()
> - that method will be called by the ordering constructor to figure out whether your vector/matrix is
> blocked at the current level in the GFS hierarchy (so for simple cases, returning false is always a
> good bet ;-) ). The descriptors also need to be either default-constructible, or you have to pass an
> explicitly instantiated object to the GFS constructor. I can't remember off of my head whether they
> need to be copy-constructible as well, but I think they don't. Finally, you need to provide a nested 
> Traits struct with a static const member max_blocking_depth. As long as you don't need nested
> indexing, set that constant to 0. Again, the ISTL descriptor in backend/istl/tags.hh is a good template.
> The max_blocking_depth constant is used by the ordering transformation to figure out the compile-time
> maximum size of the ContainerIndex.
> 
> Finally, adjust the specialization of the BackendVectorSelector if you changed the signature of
> the backend descriptors. As long as you don't want to calculate the correct vector blocking structure
> from the GFS tree (the way the new ISTL backend does), you shouldn't have to do anything else there.
> 
> 
> I hope that helps a little,
> Steffen
> 
> > 
> > Ciao
> > Christian
> > 
> > _______________________________________________
> > 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
> 



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