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
> [email protected]
> http://www.fenics.org/mailman/listinfo/dolfin-dev
_______________________________________________
DOLFIN-dev mailing list
[email protected]
http://www.fenics.org/mailman/listinfo/dolfin-dev
