[petsc-dev] Julia Petsc Wrapper

[Jared Crean]

     Hello,
         I agree with Matt, all the functions PetscOptions*(...) pass 
standard C data types, so Julia can call them directly.  For well 
written interfaces like Petsc's, I prefer very thin wrappers that 
provide as similar a user experience as possible to the original 
interface.  For the higher level interface, my goal is to provide 
abstraction for populating the array but not for creating it or doing 
math with it, so there is no violation of the abstraction by allowing 
option setting.

         As for typing, I think the wrappers should employ the same 
abstract that Petsc itself does and typealias PetscInt, PetscScalar etc. 
to the proper Julia types, and use those aliases for all the wrapper 
functions.

       To find out the proper sizes, PetscInitialize can be called with 
no arguments,  and then PetscDataTypeGetSize(PETSC_TYPE,&sz)  can be 
used to figure out the required type.

         Patrick, by bitbucket username is jcrean.  I'd definitely like 
to take a look at your slides.  I did some reading about Julia on 
PowerPC, and the results aren't good.  I think running on the BG will 
have to wait for statically compiled Julia.  For now, I am targeting an 
1024 core Sandy Bridge cluster with InfiniBand.

         Jared Crean

On 7/6/2015 9:02 AM, Matthew Knepley wrote:
> On Mon, Jul 6, 2015 at 4:59 AM, Patrick Sanan <patrick.sanan at gmail.com 
> <mailto: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? On the other hand, requiring specific types, ala FEniCS,
> is very limiting.
>
>    Matt
>
>     On Sat, Jul 4, 2015 at 11:00 PM, Jared Crean <jcrean01 at gmail.com
>     <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20150706/f90d5fb7/attachment.html>