[petsc-users] Problems with DMDAVecGetArrayF90 + Intel

[Satish Balay]

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]

> 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.
 
> 
> > 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