[petsc-dev] Julia Petsc Wrapper
Jared Crean
jcrean01 at gmail.com
Tue Jul 14 21:55:35 CDT 2015
Hello,
It works! Just tested it for the complex case. Someone was
clever enough to make it work for "Scalar" even though it isn't a
PetscDataType.
Thanks for the help,
Jared Crean
On 7/14/2015 10:40 PM, Matthew Knepley wrote:
> On Tue, Jul 14, 2015 at 9:35 PM, Jared Crean <jcrean01 at gmail.com
> <mailto: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
>> <mailto: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 <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
>>
>>
>>
>>
>> --
>> 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/a220e16e/attachment.html>
More information about the petsc-dev
mailing list