← Back to team overview

dolfin team mailing list archive

Re: dolfin <-> scipy <-> pyamg

 

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




Follow ups

References