[petsc-dev] Julia Petsc Wrapper

[Jared Crean]

     Hello,
         PETSC_USE_COMPLEX isn't a symbol in the shared library when 
Petsc is built with complex scalars, so I don't see a way to access it 
at runtime. I'll have to write a simple C program that uses sizeof() and 
write the value to a file.

         As for the MPI communicator, the julia MPI package uses a C int 
to store it, so I will typealias to that to ensure consistency.  If an 
MPI implementation uses an 8 byte pointer, MPI.jl will have to change too.

     Jared Crean

On 7/14/2015 1:04 PM, Matthew Knepley wrote:
> On Tue, Jul 14, 2015 at 10:56 AM, Jared Crean <jcrean01 at gmail.com 
> <mailto:jcrean01 at gmail.com>> wrote:
>
>         Hello everyone,
>             I got the package in a reasonably working state and Travis
>     testing setup, so I am putting the package up on Github.
>
>     https://github.com/JaredCrean2/PETSc.jl
>
>             There is still a lot more work to do, but its a start.
>
>             A couple questions:
>             When looking though the code, I noticed the MPI
>     communicator is being passed as a 64 bit integer. mpi.h typedefs
>     it as an int, so shouldn't it be a 32 bit integer?
>
>
> Some MPI implementations store the communicator as a pointer, which 
> may be 64 bits. I think the only thing the standard says is
> that MPI_Comm should be defined.
>
>             Also, is there a way to find out at runtime what datatype
>     a PetscScalar is?  It appears PetscDataTypeGetSize does not accept
>     PetscScalar as an argument.
>
>
> If PETSC_USE_COMPLEX is defined its PETSC_COMPLEX, otherwise its 
> PETSC_REAL. You can also just use sizeof(PetscScalar). What do you
> want to do?
>
>   Thanks,
>
>      Matt
>
>
>         Jared Crean
>
>
>
>     On 07/06/2015 09: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
>
>
>
>
> -- 
> 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/20150714/bb748cde/attachment.html>