[petsc-dev] Julia Petsc Wrapper

[Matthew Knepley]

On Tue, Jul 14, 2015 at 9:35 PM, Jared Crean <jcrean01 at gmail.com> wrote:

>      Hello,
>         PETSC_SCALAR is not a symbol either.  I skimmed through the names
> in the shared library, and it doesn't look like any data type information
> is there.
>

Damn, yes PETSC_SCALAR and PETSC_REAL are defines. I think we are careful
about this so that you can use
a real and complex PETSc together by building multiple versions of the
library (no symbol clash). However, I believe
you can use

  PetscDataTypeFromString("scalar", &stype, &found);
  PetscDataTypeFromString("complex", &ctype, &found);
  isComplex = stype == ctype;

  Thanks,

    Matt


>
>         Jared Crean
>
>
> On 7/14/2015 9:22 PM, Matthew Knepley wrote:
>
>  On Tue, Jul 14, 2015 at 8:03 PM, Jared Crean <jcrean01 at gmail.com> wrote:
>
>>      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.
>>
>
>  That is crazy. How about
>
>    isComplex = PETSC_COMPLEX == PETSC_SCALAR
>
>     Matt
>
>
>>          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>
>> 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>
>>> 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>
>>>> 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
>
>
>


-- 
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/f8e67950/attachment.html>