[petsc-dev] Julia Petsc Wrapper

[Garth N. Wells]

On 6 July 2015 at 16:59, Matthew Knepley <knepley at gmail.com> wrote:
> On Mon, Jul 6, 2015 at 10:56 AM, Garth N. Wells <gnw20 at cam.ac.uk> wrote:
>>
>> On 6 July 2015 at 14:56, Matthew Knepley <knepley at gmail.com> wrote:
>> > On Mon, Jul 6, 2015 at 8:40 AM, Patrick Sanan <patrick.sanan at gmail.com>
>> > wrote:
>> >>
>> >> On Mon, Jul 6, 2015 at 3:02 PM, Matthew Knepley <knepley at gmail.com>
>> >> wrote:
>> >>>
>> >>> On Mon, Jul 6, 2015 at 4:59 AM, Patrick Sanan
>> >>> <patrick.sanan at gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> I had a couple of brief discussions about this at Juliacon as well. I
>> >>>> think it would be useful, but there are a couple of things to think
>> >>>> about
>> >>>> from the start of any new attempt to do this:
>> >>>> 1. As Jack pointed out, one issue is that the PETSc library must be
>> >>>> compiled for a particular precision. This raises some questions -
>> >>>> should
>> >>>> several versions of the library be built to allow for flexibility?
>> >>>> 2. An issue with wrapping PETSc is always that the flexibility of
>> >>>> using
>> >>>> the PETSc options paradigm is reduced - how can this be addressed?
>> >>>> Could/should an expert user be able to access the options database
>> >>>> directly,
>> >>>> or would this be too much violence to the wrapper abstraction?
>> >>>
>> >>>
>> >>> I have never understood why this is an issue. Can't you just wrap our
>> >>> interface level, and use the options just as we do? That
>> >>> is essentially what petsc4py does. What is limiting in this
>> >>> methodology?
>> >>
>> >> I don't see any fundamental problems with this, either, but in practice
>> >> people tend to want to hardcode things (like the deal.ii interface
>> >> does, in
>> >> my limited experience with it). Hopefully this is just a suboptimal
>> >> design
>> >> choice which can be avoided with an interface to the options database
>> >> included in the wrapper.
>> >
>> >
>> > The deal.II wrapper is crazy. I have told Wolfgang. It makes the same
>> > mistake as FEniCS, which is to provide
>> > an interface type for each PETSc implementation type. This kind of
>> > confusion
>> > takes a flexible, runtime configuration
>> > and makes it an inflexible, compile-time configuration while introducing
>> > a
>> > load of new types and making the
>> > closed-world assumption.
>> >
>>
>> Your assertion on the FEniCS interface to PETSc is wrong for recent
>> FEniCS; users can set PETSc object types via the PETSc options system,
>> and users can access and manipulate directly the PETSc object, if they
>> wish (or initialise a wrapper with a PETSc object).
>
>
> Excellent! Can you point me toward the doc so I know what i am talking about
> next time.
>

Below is a link to a solver using BDDC, where the solver code is all
PETSc.  The user builds a matrix via the wrappers (using the options
system to set the PETSc matrix type), and then unwraps the matrix to
pass to the PETSc solver:

https://bitbucket.org/garth-wells/dolfin-dd/src/42a203e094bf61f7c312604809ec599f15943649/demo/undocumented/div-div/cpp/main.cpp?at=stefano_zampini/bddc-and-ams-examples

Garth

>   Thanks,
>
>      Matt
>
>>
>>
>> Garth
>>
>> >>> On the other hand, requiring specific types, ala FEniCS,
>> >>> is very limiting.
>> >>
>> >> What tradeoffs does FEniCS make in this context? Are there other
>> >> wrappers
>> >> which make different ones?
>> >> How wrong is it to say "If we have real and complex double types, 99%
>> >> of
>> >> the use cases are covered?".
>> >
>> >
>> > I think this is essentially true, and is what is done by the Purdue
>> > guys.
>> > You can accomplish it by using dynamic
>> > libraries and a fair bit of hacking. C still does not have a great way
>> > to do
>> > this, but I am hopeful for the Karl-style
>> > type handling from GPUs migrated to handle the real/complex divide.
>> >
>> >    Matt
>> >
>> >>
>> >>
>> >>>
>> >>>
>> >>>    Matt
>> >>>
>> >>>>
>> >>>> On Sat, Jul 4, 2015 at 11:00 PM, Jared Crean <jcrean01 at gmail.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> Hello,
>> >>>>>      I am a graduate student working on a CFD code written in Julia,
>> >>>>> and I am interested in using Petsc as a linear solver (and possibly
>> >>>>> for the
>> >>>>> non-linear solves as well) for the code.  I discovered the Julia
>> >>>>> wrapper
>> >>>>> file Petsc.jl in Petsc and have updated it to work with the current
>> >>>>> version
>> >>>>> of Julia and the MPI.jl package, using only MPI for communication (I
>> >>>>> don't
>> >>>>> think Julia's internal parallelism will scale well enough, at least
>> >>>>> not in
>> >>>>> the near future).
>> >>>>>
>> >>>>>      I read the discussion on Github
>> >>>>> [https://github.com/JuliaLang/julia/issues/2645], and it looks like
>> >>>>> there currently is not a complete package to access Petsc from
>> >>>>> Julia.
>> >>>>> With your permission, I would like to use the Petsc.jl file as the
>> >>>>> basis for
>> >>>>> developing a package.  My plan is create a lower level interface
>> >>>>> that
>> >>>>> exactly wraps Petsc functions, and then construct a higher level
>> >>>>> interface,
>> >>>>> probably an object that is a subtype of Julia's AbstractArray, that
>> >>>>> allows
>> >>>>> users to store values into Petsc vectors and matrices.  I am less
>> >>>>> interested
>> >>>>> in integrating tightly with Julia's existing linear algebra
>> >>>>> capabilities
>> >>>>> than ensuring good scalability.  The purpose of the high level
>> >>>>> interface it
>> >>>>> simple to populate the vector or matrix.
>> >>>>>
>> >>>>>      What do you think, both about using the Petsc.jl file and the
>> >>>>> overall approach?
>> >>>>>
>> >>>>>      Jared Crean
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> What most experimenters take for granted before they begin their
>> >>> experiments is infinitely more interesting than any results to which
>> >>> their
>> >>> experiments lead.
>> >>> -- Norbert Wiener
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > What most experimenters take for granted before they begin their
>> > experiments
>> > is infinitely more interesting than any results to which their
>> > experiments
>> > lead.
>> > -- Norbert Wiener
>
>
>
>
> --
> What most experimenters take for granted before they begin their experiments
> is infinitely more interesting than any results to which their experiments
> lead.
> -- Norbert Wiener