dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Thursday 26 February 2009 09:20:13 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?

SciPy is a python module that provides a lot of different numerical 
functionality to the user. Making PyDOLFIN attractive to the SciPy comunity 
will eventually make the impact of our software broader.

That was mainly politics, but hopefully some SciPy enthusiast can fill in some 
more details on the up side of the numerical methods that SciPy provides :)

Johan


> 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