[petsc-users] Problems with DMDAVecGetArrayF90 + Intel

[Satish Balay]

On Tue, 15 May 2018, Jed Brown wrote:

> Satish Balay <balay at mcs.anl.gov> writes:
> 
> > On Tue, 15 May 2018, Jed Brown wrote:
> >
> >> > Your notation requires the following change
> >> >
> >> > PETSC_EXTERN void PETSC_STDCALL dmdavecgetarrayf901_(DM *da,Vec *v,F90Array1d *a,PetscErrorCode *ierr PETSC_F90_2PTR_PROTO(ptrd))
> >> > PETSC_EXTERN PetscErrorCode F90Array1dCreate(void*,MPI_Datatype,PetscInt,PetscInt,F90Array1d* PETSC_F90_2PTR_PROTO_NOVAR);
> >> >
> >> > to:
> >> >
> >> > PETSC_EXTERN void PETSC_STDCALL dmdavecgetarrayf901_(DM *da,Vec *v,F90Array1d a,PetscErrorCode *ierr PETSC_F90_2PTR_PROTO(ptrd))
> >> > PETSC_EXTERN PetscErrorCode F90Array1dCreate(void*,MPI_Datatype,PetscInt,PetscInt,F90Array1d PETSC_F90_2PTR_PROTO_NOVAR);
> >> 
> >> Yes.
> >> 
> >> > [this doesn't look right.] 
> >> 
> >> I don't know why not, 
> >
> > output argument without a explicit pointer in definition is weird for c - and can result in future bugs [when this code is changed]
> 
> The pointer is inside a typedef for all the basic PETSc types.

Sure - but we have: 'MatCreate(MPI_Comm,Mat*)' and not 'MatCreate(MPI_Comm,Mat)' - which the above prototype would suggest.

> 
> >> but I don't care about this narrow bit of
> >> compiler-enforced type safety enough to push for the more intrusive fix.
> >
> > I'm not sure I understand what extra type safety is obtained by 'F90Array1d*' vs 'F90Array1d' usage
> >
> > Or does 'typedef struct { void *ptr; } F90Array3d;' give the extra safety? I could change this part of typedef.
> 
> Yeah, that's an alternative way to get a strong typedef, and you could
> keep the other code unmodified.
> 
> typedef struct { char dummy; } F90Array1d;
> typedef struct { char dummy; } F90Array2d;
> typedef struct { char dummy; } F90Array3d;
> 
> These are all distinct types.  

I'm not sure if they need to be distinct. Perhaps they are collapsible
into a single type. [I suspect its a design we used to keep it in sync
with our old f90 interface code. We had both versions for a while]

For now - I've updated the commit to use the above typedef.

Satish

> Better to use char for the dummy because
> we don't have reason to know that the pointer is word aligned, but the
> standard says that any data pointer can be cast to a char*.
> 
> >> 
> >> > So I guess 'pointer to address (void*)' is the correct notation - as
> >> > we pass these back to fortran calling routine wrt
> >> > dmdavecgetarrayf901_() and an output argument for F90Array1dCreate().
> >> 
> >> It's actually just the pointer that we have.  The thing it points to is
> >> of some type that is not known statically in F90Array1dCreate/Destroy.
> >
> > Yes. we get something opaque - and we pass it down to fortran utility routine or up to the calling fortran routine - unmodified.
> >
> > My current patch is at balay/fix-F90Array__Destroy/maint
> >
> > Satish
>