hi
On 31/10/17 11:21, Adrian Croucher wrote:
I just pulled the latest next branch and found that the PetscSF stuff
doesn't appear to work in Fortran anymore for me.
I think I've found the trouble- after you put in the check to see if
Fortran has type(*) support, I needed to reconfigure P
On 01/11/17 16:20, Jed Brown wrote:
Adrian Croucher writes:
On 01/11/17 09:50, Smith, Barry F. wrote:
Please send the full traceback. Cut and paste
It's not really giving me much, only:
Program received signal SIGSEGV, Segmentation fault.
0x7efe8574d6a9 in Pack_int_1 (n=2, bs=1, idx
Adrian Croucher writes:
> On 01/11/17 09:50, Smith, Barry F. wrote:
>>Please send the full traceback. Cut and paste
>
> It's not really giving me much, only:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x7efe8574d6a9 in Pack_int_1 (n=2, bs=1, idx=0xfd6430,
> unpacked=0x
On 01/11/17 09:50, Smith, Barry F. wrote:
Please send the full traceback. Cut and paste
It's not really giving me much, only:
Program received signal SIGSEGV, Segmentation fault.
0x7efe8574d6a9 in Pack_int_1 (n=2, bs=1, idx=0xfd6430,
unpacked=0xfffb03ec, packed=0xfe9a00)
at /hom
Please send the full traceback. Cut and paste
> On Oct 31, 2017, at 3:37 PM, Adrian Croucher
> wrote:
>
>
> On 01/11/17 03:02, Smith, Barry F. wrote:
>> Adrian,
>>
>> I fixed some bugs but apparently broke something at the same time. At a
>> meeting now, maybe you could use -star
On 01/11/17 03:02, Smith, Barry F. wrote:
Adrian,
I fixed some bugs but apparently broke something at the same time. At a
meeting now, maybe you could use -start_in_debugger and get the traceback where
it crashes for you?
OK I did that, and it appears to be dying in
src/vec/is/sf/imp
Adrian,
I fixed some bugs but apparently broke something at the same time. At a
meeting now, maybe you could use -start_in_debugger and get the traceback where
it crashes for you?
Barry
> On Oct 30, 2017, at 5:21 PM, Adrian Croucher
> wrote:
>
> hi,
>
> I just pulled the latest n
hi,
I just pulled the latest next branch and found that the PetscSF stuff
doesn't appear to work in Fortran anymore for me.
When I run the ex1f example it gives:
[0]PETSC ERROR:
[0]PETSC ERROR: Caught signal number 11 S
Barry Smith writes:
>> On Oct 24, 2017, at 6:58 AM, Jed Brown wrote:
>>
>> Lawrence Mitchell writes:
>>
On 24 Oct 2017, at 06:21, Barry Smith wrote:
>>> - With PetscSFBcastBegin() / PetscSFBcastEnd() you currently still have
>>> to use the C MPI types in the Fortran calli
Never mind, this is MPI Uni ;) I'll fix it tonight
> On Oct 24, 2017, at 5:34 PM, Barry Smith wrote:
>
>
> This didn't last too long
>
> /opt/atlassian/pipelines/agent/build/src/sys/f90-src/f90_cwrap.c: In function
> 'PetscErrorCode PetscMPIFortranDatatypeToC(MPI_Fint, MPI_Datatype*)':
This didn't last too long
/opt/atlassian/pipelines/agent/build/src/sys/f90-src/f90_cwrap.c: In function
'PetscErrorCode PetscMPIFortranDatatypeToC(MPI_Fint, MPI_Datatype*)':
/opt/atlassian/pipelines/agent/build/src/sys/f90-src/f90_cwrap.c:29:16: error:
'MPI_INTEGER' was not declared in this
Adrian,
I have updated the branch barry/fortran-PetscSFBcastBegin to support using
Fortran datatypes and PetscSFGetGraph()
Please let me know of additional difficulties.
Barry
> On Oct 24, 2017, at 6:58 AM, Jed Brown wrote:
>
> Lawrence Mitchell writes:
>
>>> On 24 Oct 201
> On Oct 24, 2017, at 6:58 AM, Jed Brown wrote:
>
> Lawrence Mitchell writes:
>
>>> On 24 Oct 2017, at 06:21, Barry Smith wrote:
>>>
>> - With PetscSFBcastBegin() / PetscSFBcastEnd() you currently still have
>> to use the C MPI types in the Fortran calling code, rather than the
>>>
Lawrence Mitchell writes:
>> On 24 Oct 2017, at 06:21, Barry Smith wrote:
>>
> - With PetscSFBcastBegin() / PetscSFBcastEnd() you currently still have
> to use the C MPI types in the Fortran calling code, rather than the
> Fortran ones. I think it is a bit confusing to have to mix
> On 24 Oct 2017, at 06:21, Barry Smith wrote:
>
- With PetscSFBcastBegin() / PetscSFBcastEnd() you currently still have to
use the C MPI types in the Fortran calling code, rather than the Fortran
ones. I think it is a bit confusing to have to mix the two up in the same
co
> On Oct 23, 2017, at 11:11 PM, Adrian Croucher
> wrote:
>
> hi
>
>
> On 24/10/17 17:00, Barry Smith wrote:
>>> - With PetscSFBcastBegin() / PetscSFBcastEnd() you currently still have to
>>> use the C MPI types in the Fortran calling code, rather than the Fortran
>>> ones. I think it is a b
hi
On 24/10/17 17:00, Barry Smith wrote:
- With PetscSFBcastBegin() / PetscSFBcastEnd() you currently still have to use
the C MPI types in the Fortran calling code, rather than the Fortran ones. I
think it is a bit confusing to have to mix the two up in the same code. If you
put MPI_INTEGER
> On Oct 23, 2017, at 9:53 PM, Adrian Croucher
> wrote:
>
> hi
>
>
> On 24/10/17 13:55, Adrian Croucher wrote:
>>
>> The stub for PetscSFSetGraph() is getting automatically generated (I can see
>> it in /vec/f90-mod/ftn-auto-interfaces/petscpetscsf.h90), but the one for
>> PetscSFGetGraph(
hi
On 24/10/17 13:55, Adrian Croucher wrote:
The stub for PetscSFSetGraph() is getting automatically generated (I
can see it in /vec/f90-mod/ftn-auto-interfaces/petscpetscsf.h90), but
the one for PetscSFGetGraph() is missing for some reason. Any clues?
Oh, I see, all it needs to turn on th
Adrian,
Sorry for the delay in generating the bindings for you. I have put them in
the branch
barry/fortran-PetscSFBcastBegin
the example src/vec/sf/examples/tutorials/ex1f.F90 attempts to test them.
Please let us know if this works for you and if you need anything else. They
will only
Barry Smith writes:
>> What does that has to do with PetscSF, which never used PetscDataType
>> and uses MPI datatypes with support for derived types (albeit with a
>> limited number of combiners)?
>
>Because the code he started to write uses F90Array1dAccess() which
>is built around Pets
> On Oct 20, 2017, at 8:09 PM, Jed Brown wrote:
>
> Barry Smith writes:
>
>>> On Oct 20, 2017, at 12:31 PM, Jed Brown wrote:
>>>
>>> Barry Smith writes:
>>>
Adrian,
You should not use F90Array1d *rptr as arguments in the Fortran
interface. You should just use a reg
Barry Smith writes:
>> On Oct 20, 2017, at 12:31 PM, Jed Brown wrote:
>>
>> Barry Smith writes:
>>
>>> Adrian,
>>>
>>>You should not use F90Array1d *rptr as arguments in the Fortran
>>> interface. You should just use a regular Fortran one dimensional array of
>>> real/scalar.
>>> For
> On Oct 20, 2017, at 12:31 PM, Jed Brown wrote:
>
> Barry Smith writes:
>
>> Adrian,
>>
>>You should not use F90Array1d *rptr as arguments in the Fortran
>> interface. You should just use a regular Fortran one dimensional array of
>> real/scalar.
>> Fortran doesn't handle polymorphis
Barry Smith writes:
>Adrian,
>
> You should not use F90Array1d *rptr as arguments in the Fortran
> interface. You should just use a regular Fortran one dimensional array of
> real/scalar.
> Fortran doesn't handle polymorphism in this way at all. You have to have
> multiple f90 interfac
Adrian,
You should not use F90Array1d *rptr as arguments in the Fortran interface.
You should just use a regular Fortran one dimensional array of real/scalar.
Fortran doesn't handle polymorphism in this way at all. You have to have
multiple f90 interfaces, one for each type and provide a
> On Oct 19, 2017, at 10:29 PM, Jed Brown wrote:
>
> Adrian Croucher writes:
>
>> hi
>>
>>
>> The problem is this only seems to work if I declare the datatype in the
>> calling Fortran code to be of the appropriate C MPI datatype, e.g.
>> MPI_INT, rather than the corresponding Fortran data
Adrian Croucher writes:
> hi
>
>
> On 19/10/17 06:45, Matthew Knepley wrote:
>> On Tue, Oct 17, 2017 at 11:35 PM, Adrian Croucher
>> mailto:a.crouc...@auckland.ac.nz>> wrote:
>>
>>
>> So, now I'm trying to add Fortran bindings for PetscSFBcastBegin()
>> and PetscSFBcastEnd().
>>
>> F
hi
On 19/10/17 06:45, Matthew Knepley wrote:
On Tue, Oct 17, 2017 at 11:35 PM, Adrian Croucher
mailto:a.crouc...@auckland.ac.nz>> wrote:
So, now I'm trying to add Fortran bindings for PetscSFBcastBegin()
and PetscSFBcastEnd().
From the C side I have added the following into
On Tue, Oct 17, 2017 at 11:35 PM, Adrian Croucher wrote:
> hi
>
> On 16/10/17 15:16, Jed Brown wrote:
>
>> Adrian Croucher writes:
>>
>> So do you think the SF stuff in petsc/finclude/petscis.h should be taken
>>> out, and put into a new petsc/finclude/petscsf.h ?
>>>
>> I think that's desirable
hi
On 16/10/17 15:16, Jed Brown wrote:
Adrian Croucher writes:
So do you think the SF stuff in petsc/finclude/petscis.h should be taken
out, and put into a new petsc/finclude/petscsf.h ?
I think that's desirable for symmetry with include/petscsf.h, but it
isn't important for your contributi
Adrian Croucher writes:
> On 16/10/17 14:14, Matthew Knepley wrote:
>>
>> This last file petscao.h is including a "petsc/finclude/petscao.h",
>> which contains various definitions including the definition of AO. Do
>> I need to make some sort of similar "petsc/finclude/petscsf.h"?
>>
>>
>>
On 16/10/17 14:14, Matthew Knepley wrote:
This last file petscao.h is including a "petsc/finclude/petscao.h",
which contains various definitions including the definition of AO. Do
I need to make some sort of similar "petsc/finclude/petscsf.h"?
It looks like PetscSF is already defined
On Sun, Oct 15, 2017 at 9:13 PM, Adrian Croucher
wrote:
> On 16/10/17 13:12, Matthew Knepley wrote:
>
>
> Okay, I was wrong about what gets produced. Barry rewrote the Fortran
> bindings last, and I did not understand how everything
> was put together. You will need to make some modifications. He
On 16/10/17 13:12, Matthew Knepley wrote:
Okay, I was wrong about what gets produced. Barry rewrote the Fortran
bindings last, and I did not understand how everything
was put together. You will need to make some modifications. Here is
the idea: we build an F90 module for each class, and your
On Sun, Oct 15, 2017 at 6:54 PM, Adrian Croucher
wrote:
> hi
>
> On 14/10/17 00:47, Matthew Knepley wrote:
>
>
> If you want the wrapper to take in F90 pointer arguments, then you have to
> declare it or you get an SEGV. These
> get autogenerated in include/petsc/finclude/ftn-auto/*.h90 when you
hi
On 14/10/17 00:47, Matthew Knepley wrote:
If you want the wrapper to take in F90 pointer arguments, then you
have to declare it or you get an SEGV. These
get autogenerated in include/petsc/finclude/ftn-auto/*.h90 when you
run 'make allfortranstubs'. Did this happen
for your function?
I
On Fri, Oct 13, 2017 at 12:25 AM, Adrian Croucher wrote:
> hi Jed
>
> I have had a go at writing a Fortran binding for the PetscSFGetGraph()
> function, along the lines of what you suggested:
>
> On 21/09/17 15:15, Jed Brown wrote:
> Unfortunately PetscSFSetGraph/PetscSFGetGraph need custom bindi
hi Jed
I have had a go at writing a Fortran binding for the PetscSFGetGraph()
function, along the lines of what you suggested:
On 21/09/17 15:15, Jed Brown wrote:
Unfortunately PetscSFSetGraph/PetscSFGetGraph need custom bindings for
Fortran and they have not been written. Shouldn't be diffi
hi
On 28/09/17 15:34, Adrian Croucher wrote:
So I think I will need to use PetscSFSetGraph() after all, so I can
increase the number of roots, update the leaf point indices, and also
update the remote root index for each leaf (presumably I can use the
original SF and PetscSFBcastBegin/ Pets
hi
On 28/09/17 04:18, Matthew Knepley wrote:
Okay, I think this should be easy to solve.
First a little bit about SF. There are two parts to the specification.
You have the communication part, which maps
a certain location p on this process to another location q on another
process. This migh
On Tue, Sep 26, 2017 at 11:49 PM, Adrian Croucher wrote:
> hi Matt,
>
> On 25/09/17 23:12, Matthew Knepley wrote:
>
>
> If you truly need the exact same SF for your grid, you should be able to
> use DMGet/SetPointSF() since it will just reference count it for you. Then
> the default SF is created
hi Matt,
On 25/09/17 23:12, Matthew Knepley wrote:
If you truly need the exact same SF for your grid, you should be able
to use DMGet/SetPointSF() since it will just reference count it for
you. Then
the default SF is created automatically from the point SF. Does this work?
It doesn't seem
On Sun, Sep 24, 2017 at 8:57 PM, Adrian Croucher
wrote:
>
>
> On 25/09/17 13:37, Adrian Croucher wrote:
>
>>
>> Actually it looks like DMGetDefaultSF() does already work in Fortran
>> though, and could be used to do the same thing.
>>
>> Do you think that would be a reasonable way to do it?
>>
>>
On 25/09/17 13:37, Adrian Croucher wrote:
Actually it looks like DMGetDefaultSF() does already work in Fortran
though, and could be used to do the same thing.
Do you think that would be a reasonable way to do it?
Hmm, I just tried it and it looks like the default SF produced by this
fun
On 25/09/17 13:18, Adrian Croucher wrote:
Alternatively, it occurred to me I could probably just use
DMCreateDefaultSF() to create the point SF on the new DM- would there
be any disadvantage in doing it that way?
However, at the moment I can't, because it appears the Fortran
interface for
hi
On 21/09/17 15:15, Jed Brown wrote:
Unfortunately PetscSFSetGraph/PetscSFGetGraph need custom bindings for
Fortran and they have not been written. Shouldn't be difficult, but
will take a little work/testing. I would probably make the array of
PetscSFNode be a PetscInt array of length 2n (o
Unfortunately PetscSFSetGraph/PetscSFGetGraph need custom bindings for
Fortran and they have not been written. Shouldn't be difficult, but
will take a little work/testing. I would probably make the array of
PetscSFNode be a PetscInt array of length 2n (or of shape (2,n)) --
that's an equivalent m
hi
For the dual-porosity stuff I'm working on, I'm creating a modified
DMPlex. Looking at e.g. TS ex11.c (in the SplitFaces() routine), it
appears I am going to have to set up a PetscSF for the new DM (from what
I can gather, that is needed for managing parallel communication of
partition gho
49 matches
Mail list logo