dolfin team mailing list archive

[Ola Skavhaug <skavhaug@xxxxxxxxx>]

On Thu, Feb 26, 2009 at 9:46 AM, Garth N. Wells <gnw20@xxxxxxxxx> wrote:

>
>
> 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



I don't know how widespread the use of SciPy's spase matrix facilities is,
but if we assume people do real science or simulator development based on
it, software integration is, imo, a good thing. Of course, the people having
the motivation to integrate DOLFIN and SciPy should drive this effort. I
would be surprised if a code patch for this would be rejected by the main
DOLFIN developers.

I think application code already distinguishes the Python and C++ code quite
substantially, although the demos and tests in DOLFIN look similar. The
languages do differ, and so does the relevant software modules / libraries
that people might want to integrate with DOLFIN.


>
>
> > 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<https://www.fenics.org/mailman/listinfo/dolfin-dev>
> >>
> >> _______________________________________________
> >> DOLFIN-dev mailing list
> >> DOLFIN-dev@xxxxxxxxxx
> >> http://www.fenics.org/mailman/listinfo/dolfin-dev<https://www.fenics.org/mailman/listinfo/dolfin-dev>
> >
>
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev<https://www.fenics.org/mailman/listinfo/dolfin-dev>
>



-- 
Ola Skavhaug