[petsc-dev] Julia Petsc Wrapper

[Matthew Knepley]

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.

  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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20150706/130e15cc/attachment.html>