> On Jul 19, 2015, at 2:25 PM, Jared Crean <jcrea...@gmail.com> wrote:
>
> Hello,
> Yeah, Clang.jl was supposed to be the answer to that, but it doesn't
> handle preprocessor macros and a few other things quite right.
>
> Anyways, type detection is working, but when running the tests with
> PetscScalar as a double precision complex number, Petsc gives the 1 norm of
> the vector [1.0 + 0im; 2.0 + 1.0im; 3.0 + 2.0im] as 9.0, where as Julia
> calculates it as 6.841619252963779. It looks like Petsc isn't taking the
> modulus of the elements of the vector before summing them. Is this a bug or
> is there a particular reason for it?
I have changed PETSc master branch to use the more traditional 1 norm for
complex numbers. This is how it will work in future releases (but not in the
patch releases).
Thanks for reporting our nonstandard usage
Barry
>
> Jared Crean
>
> On 07/14/2015 10:53 PM, Barry Smith wrote:
>> The Julia folks should give up their delusion that a C package is
>> characterized completely by its .so, it is not, it is defined by its .so and
>> its .h; a .so without its .h it is fairly useless.
>>
>> Barry
>>
>>
>>
>>> On Jul 14, 2015, at 9:40 PM, Matthew Knepley <knep...@gmail.com> wrote:
>>>
>>> On Tue, Jul 14, 2015 at 9:35 PM, Jared Crean <jcrea...@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 <jcrea...@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 <jcrea...@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.sa...@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 <jcrea...@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
>
