[Dune] [Dune-Commit] dune-common r5532 - trunk/common

[Markus Blatt]

On Fri, May 29, 2009 at 01:00:12PM +0200, Andreas Dedner wrote:
> The problem of fmatrix being a part of dune-common and heavily
> used in dune-grid and at the same time being an interface class of
> dune-istl is an unfortunate difficulty;

Sure. this is due to the modularisation.

> but asking people forced to use fmatrix
> (due to the dune-grid interface) to port a small addition to
> fmatrix to the dune-istl matricies
> (which we hardly use and do not know anything about),
> is asking a bit much in my opinion. 

Sure. I did not want to ask this. Maybe a volunteer would do the job
if he had a chance. But for this to happen these changes must raise
more awareness then they do by just commiting them. A short discussion
on the mailinglist (e.g. about feasibility in other matrix
implementations) and a bug report if the change should appear in the
interface. 

> FMatrix is used in dune-grid not as
> an interface class but as the fixed matrix implementation!
> And by the way the documentation does not state that this is an
> interface class 

It does but only in the ISTL documentation. That is not enough,
though.

> - and an interface class should not contain the
> implementation...

Mmh, with templates that is a question to argue about. But let us not
do that.

>
> If fmatrix has a method mv and umv
> and a method umtv then anybody would expect it to have a method
> mtv, would you not agree? That is the only thing we added.

Cool. The discusion on the list is on. Sure it should.

>
> If you think that using a work around like Roberts
> FMatrixHelp::multAssignTransposed (which does exactly the mtv operation
> is the better approach then we can discuss this...
>

Probably not. It would be nice if it was usable for all matrices and
would be more maintainable. But whether to put it in dune-common or
dune-istl is IMHO an undecidable question.

Markus