On Tue, Jul 14, 2015 at 10:56 AM, Jared Crean <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>>
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
<[email protected] <mailto:[email protected]>> 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
