[dune-functions] ISTL-Backend

[Oliver Sander]

Hi,

> in my attempt to verify if out global basis interface is rich
> enough I implemented an ISTL-backend whose sole functionality
> is currently to provide
> 
>   operator()(const MultiIndex& row, const MultiIndex& col)
> 
> Sound's easy, but is in fact a little tricky to get right
> for multitype-matrices and especially if the multi-indices
> have non-uniform length (but it works for these cases).
> Next thing to add would be resize/allocate functionality.
> But I'm undecided if the backend should be in dune-functions
> at all:

I think this depends on whether dune-pdelab would use that.  If the pdelab
folks say that they cannot use your implementation (at least partially)
because it lacks ${something}, then that would be an argument
against inclusion in dune-functions.


> 
> + Stokes-example gets more elegant
> + Stokes-example gets almost agnostic on index scheme
> + Can serve as an example of how to implement a backend
> - Far beyond the scope of dune-functions.

That depends.  We define what the scope of dune-functions is. :-)

> - Stokes-example gets less basic because we'd not like
>   to explain the magic in the backend to Joe Average

No problem: we could have two separate stokes-th examples.
One with and one without the vector backends.

Best,
Oliver


> 
> Please give you're opinion. A 'no' would be no problem
> and just mean that I put this in dune-fufem where we'll
> need this once we switch to dune-functions bases.
> 
> Best,
> Carsten
> 
> 
> 
> _______________________________________________
> dune-functions mailing list
> dune-functions at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-functions
>