Kent Andre wrote:
> 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.
>
I still don't see a motivation for scipy specifically. My point is that
there should be a concrete reason to work on integration because it will
naturally lead to an increase in the complexity of DOLFIN. We should be
cautious in integrating pure Python libraries since the Python and C++
interfaces of DOLFIN will deviate. A strength is the present similarity
of the interfaces.
Garth
> 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
>>> [email protected]
>>> http://www.fenics.org/mailman/listinfo/dolfin-dev
>>
>> _______________________________________________
>> 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
