[dune-pdelab] Howto updat backend?

[Steffen Müthing]

Hi Christian,

Am 21.05.2013 um 17:19 schrieb 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.

Yes, I'm afraid that poor thing didn't survive the rewrite… I'll see if I can cook up a new
one on the train ride home. Really shouldn't take more than an hour.

And I agree, having some simple backends as templates and / or helpers would really
simplify interfacing with external libs.

Steffen

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

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/20130521/1ba42294/attachment.sig>