[petsc-dev] PetscSF in Fortran
Barry Smith
bsmith at mcs.anl.gov
Mon Oct 23 23:00:18 CDT 2017
> On Oct 23, 2017, at 9:53 PM, Adrian Croucher <a.croucher at auckland.ac.nz> 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() is missing for some reason. Any clues?
>
> Oh, I see, all it needs to turn on the auto stub is to remove the 'C' at src/vec/is/sf/interface/sf.c:429.
>
> However it looks like this auto stub for PetscSFGetGraph() can't return pointers to the ilocal and iremote arrays, so you have to call it twice? First to get the number of leaves (with null in the array parameters), then allocate the arrays accordingly before calling PetscSFGetGraph() again to fill them up?
>
> If so it might be more convenient to have a custom binding that returned pointer arrays, if possible, so you only had to call it once. That was the kind of thing I did with my custom binding, but it was using integer arrays rather than the PetscSFNode type.
Yes, you are right, needs custom code for this one. I'll try to add it.
>
>
>
> I have a couple of other queries:
>
> - you've allowed users to declare variables as being 'type(PetscSFNode)'. With most other PETSc Fortran types you can declare variables as 'type(tXXX) :: foo' or 'XXX :: foo' (but not 'type(XXX) :: foo'). Should this one perhaps be altered to work the same way, for consistency?
I am not sure. The ones with the tXXX business are opaque objects, that is you cannot directly access the contents inside with Fortran code. They have the alternative XXX :: foo to match the previous syntax for declaring such objects.
I think I will leave it PetscSFNode as is but I've added example usage for Fortran to the manual page for PetscSFNode
>
> - 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 instead of MPI_INT for example, it dies in F90Array1dAccess() with 'unsupported MPI_Datatype'. Could the Fortran MPI types be supported in these routines just by adding them as alternatives into the conditionals?
Hmm, Jed will need to provide wisdom the Linux manual page for MPI_INTEGER clearly states:
Note that the Fortran types should only be used in Fortran programs, and the C types should only be used in C programs. For example, it is in error to use MPI_INT for a Fortran INTEGER. Datatypes are of type MPI_Datatype in C and of type INTEGER in Fortran.
If this is true then there is no place we can do the change properly.
Jed needs to chime in here. Do you know the acceptable way to handle this? That is DO all MPI implementations support MPI_INTEGER from C?
Barry
>
> - Adrian
>
> --
> Dr Adrian Croucher
> Senior Research Fellow
> Department of Engineering Science
> University of Auckland, New Zealand
> email: a.croucher at auckland.ac.nz
> tel: +64 (0)9 923 4611
>
More information about the petsc-dev
mailing list