← Back to team overview

dolfin team mailing list archive

Re: dolfin <-> scipy <-> pyamg

 

In Dolfin you have very little control over the algorithms used to solve
the linear system except that you can set a few parameters like
the solver and preconditioner and send it away to the backend. You
can of course do backend specific things. 

Say you want a different norm on the residual than the one supported by
the backend, or want have a null space that you don't want to be present
in the residual, or want to compute the eigenvalues as a substep in the
CG algorithms.  Such things, that at least I care a lot about, is very
easy to do if you add a few lines to the Krylov algorithm. 
It also makes block preconditioning a lot easier.
Hence, having the algorithms present in Python is a big thing,
I think. 

Kent

On to., 2009-02-26 at 08:20 +0000, Garth N. Wells wrote:
> I'm missing a motivation in this discussion. What functionality does 
> scipy have on the linear algebra front that we want to have in DOLFIN 
> but don't already have?
> 
> Garth
> 
> Johan Hake wrote:
> > On Wednesday 25 February 2009 22:43:20 Anders Logg wrote:
> >> On Wed, Feb 25, 2009 at 08:48:37AM +0100, Johan Hake wrote:
> >>> On Wednesday 25 February 2009 03:27:54 Luke Olson wrote:
> >>>> Kent,
> >>>>
> >>>> Thanks for the shout-out.  PyAMG is nearing a stable release and we're
> >>>> looking for compatibility with related projects.  We'd love to hear any
> >>>> success stories.
> >>>>
> >>>> I'm also interested in hearing about any attempts at more closely
> >>>> integrating the scipy.sparse module with Dolfin.
> >>> There aren't any :( but, I have to admit, it would be cool :)
> >>>
> >>> I had a _brief_ look at the code in scipy/sparse/sparsetools and I see
> >>> that you have a minimal C++ interface, which is glued together by swig,
> >>> right?
> >>>
> >>> I am not very familiar to the SciPy family or more precise the
> >>> scipy.sparse module, so it would be nice with some thoughts of how deep
> >>> this integration should be. From the top of my head:
> >>>
> >>> SciPy integration in the c++ layer of DOLFIN:
> >>> As SciPy is a "pure" python library this can feel a bit (please correct
> >>> me) unnesessary. However I see that you have some sort of c++ interface,
> >>> which could be used. Then we need to be able to wrap it into the
> >>> GenericMatrix class, and we also need the SciPy version of the other
> >>> GenericFoo classes in dolfin/la. To be able to full integrate SciPy's
> >>> structures in DOLFIN we probably need to wrap it into the DOLFIN layer.
> >> This would be the best option as we could then send in a SciPy matrix
> >> directly to the assembler.
> > 
> > Agree, but I am not sure it will be easy, as there are no such thing as a csr 
> > matrix in c++. I think it is built using only python. It looks to me that 
> > there are no really c++ data structures that can be integrated in DOLFIN. The 
> > c++ code included in scipy.sparse is only the low level functionalities, 
> > implemented as functions, which are then attached to python classes.
> > 
> > We could maybe just add some _thin_ CrsFoo classes, where the matrices just 
> > keep three *double (rows,cols,data), intended just for assemble, and for 
> > passing data to other libraries, like scipy.
> > 
> >>> SciPy integration in the python layer of DOLFIN:
> >>> This should be more feasable but probably unsatisfactory, as DOLFIN and
> >>> PyDOLIN are more or less just two sides of the same coin.
> >> In this case, we could just have some simple conversion utilities,
> >> like we have now for vectors with
> >>
> >>   xx = x.array()
> >>   x.set(xx)
> > 
> > Yes or just add a standalone function:
> > 
> > def to_scipy_csr(A):
> >     backend = dolfin_get("linear algebra backend")
> >     assert(backend == "uBLAS" or backend == "MTL4" )
> >     rows, cols, data = A.data()
> >     return scipy.scparse.csr_matrix(rows.copy(),cols.copy(),data.copy())
> > 
> > But this is based on the data beeing copied. To be able to avoid this we need 
> > to take ownership of the underlaying data structures which is not feaseble 
> > today, right?
> > 
> > Johan
> > _______________________________________________
> > DOLFIN-dev mailing list
> > DOLFIN-dev@xxxxxxxxxx
> > http://www.fenics.org/mailman/listinfo/dolfin-dev
> 
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev



Follow ups

References