[dune-fem] spmatrix change proposal

[Andreas Dedner]

Hi Marco.
Again sorry for being slow a lot of things to do at the moment.
First my overall view of the matter (for others to disagree):
- I don't think we need to add to many special linear solver classes to
dune-fem if we can use dune-istl
   instead (as far as I remember UMFPACK was added to dune-fem before it
was added to ustl)
- but it's also good to have some solvers directly in dune-fem as
templates for people to see how to
  to implement new ones
- if something (e.g. UMFPCK) becomes avaialable in dune-istl we could
consider removing it from dune-fem
  to reduce maintanace

The main question is:
- what do we need to add to dune-fem to make it work easily with dune-istl
- is there any performance loss when switching to istl solvers e.g. for
UMFPACK

I don't really know that much about istl to be able to answer these
questions perhaps you can help.
Perhaps we could give you access to the dune-fem repo so you can setup a
branch (that has to be done
in Freiburg I guess and we should think about a easier way of doing this
in the future.
I'll go ahead and add field_type as you suggested that's easy enough 
but I guess that's not all that needed?
Thanks for your help btw
Andreas

On 28/10/14 11:37, Agnese, Marco wrote:
> Hi Andreas,
> I have closed the flyspray because there was a bug in one of the header an it wasn't possible to delete it and upload the new version. 
> Therefore I have closed the flyspray and I have opened a new one (FS#1519).
> I have created a repository with several files which should be added in dune/dune-fem. Here is the link https://github.com/magnese/dune-wrappers-solvers .
>
> In the repository you can find for DUNE ISTL :
> ldl.hh: wrapper for SuiteSparse LDL. It satisfies the Dune::InverseOperator interface but it is not derived from it. In this way it can be used not only within Dune ISTL but also with DUNE FEM. Like Dune::UMFPack the factorization and the solution is done in two different steps in order to reuse the decomposition if the RHS change. 
> spqr.hh: as ldl.hh but for SuiteSparse QR.
>
> For what concern DUNE FEM:
> colcompspmatrix.hh: classes to convert SparseRowMatrix to column-compressed matrix. It is simply a specialization  of Dune::ColCompMatrix but for sparse matrix of DUNE FEM. In this way it is possible to use the new Dune::LDL and Dune::SPQR with DUNE::FEM::ISTLLinearOperator out of the box. The namespace is Dune because it is a specialization of a Dune class but it is for Dune Fem structures.
> ldlsolver.hh: like Dune::Fem::UMFPACKOp but for the new Dune::LDL solver.
> spqrsolver.hh: like Dune::Fem::UMFPACKOp but for the new Dune::SPQR solver.
>
> All these files works and have been tested with valgrind. It would be nice to add them to DUNE and DUNE FEM respectively.
>
> It would be nicer to have LDL and SPQR derived from Dune::InverseOperator to be more consistent. We didn't do that since field_type is not defined in Dune Fem discrete function. Therefore I propose to add a typedef for filed_type in DUNE FEM structures. In this way we can derive both LDL both SPQR from Dune::InverseOperator and still use them within DUNE FEM. 
>
> Moreover it would be possible to generalize Dune::UMFPack as we have done with LDL and SPQR in order to be used also in DUNE FEM. In this way it would be possible to get rid of the redundant UMFPACK implementation inside Dune::Fem::SparseRowMatrixObject< DomainSpace, RangeSpace >::solveUMF.
>
> To summarize I ask to add ldl.hh, spqr.hh in dune-istl and colcompspmatrix.hh, ldlsolver.hh, spqrsolver.hh in dune-fem.
> Then, if you add the possibility to extract field_type form dune fem structures I will write the patches to derive these operators from Dune::InverseOperator and to generalize  Dune::UMFPack to be used directly with DUNE FEM structures.
>
> I hope to have been enough clear. I wait for your feedback/questions/suggestions.
>
> Regards,
> Marco.
>
>
> ________________________________________
> From: Andreas Dedner [a.s.dedner at warwick.ac.uk]
> Sent: Monday, October 27, 2014 9:53 PM
> To: dune-fem at dune-project.org; Agnese, Marco
> Subject: Re: [dune-fem] spmatrix change proposal
>
> Hi Marco
> Why did you close the flyspray task again, Marco?
> I wanted to look at this sometime and your suggestion to add that into
> istl seems a good idea.
> We might consider removing the dune-fem Umfpack binding and use the
> binding in dune-istl but
> I never looked how easy that would be and what we would loose.
> Greetings

> Andreas
>
> On 14/10/14 16:37, Agnese, Marco wrote:
>> Hi everybody,
>> we are writing some wrappers for LDL and SPQR.
>> Since the sparse matrix format is the same of UMFPack it would be nice to use the method SparseRowMatrix<T>::setupUMF() to extract the matrix in CCS format.
>> This method is now private therefore I ask if it is possible to make it public (and maybe rename extractCCSMatrix or something like that).
>> Thank you very much,
>> cheers,
>> Marco.
>>
>> PS: I know that an alternative solution is to copy the code in my own wrapper but it leads to useless code duplication and furthermore the class variable clearedRows_ is private.
>> _______________________________________________
>> dune-fem mailing list
>> dune-fem at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune-fem