[petsc-dev] Julia Petsc Wrapper

[Garth N. Wells]

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

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