OK, so we could check if (obj==FORTRAN_TYPE_INITIALIZE) .... and remove all of our initializations. And then MatCreateVecs should work. On Tue, Mar 17, 2020 at 3:52 PM Satish Balay <[email protected]> wrote:

Ah - found it. So PETSc is doing this initialization for you.

config/BuildSystem/config/compilersFortran.py: help.addArgument('Compilers', '-with-fortran-type-initialize=<bool>', nargs.ArgBool(None, 1, 'Initialize PETSc objects in Fortran')) config/BuildSystem/config/compilersFortran.py: self.addDefine('FORTRAN_TYPE_INITIALIZE', ' = -2') src/vec/f90-mod/petscvec.h: PetscFortranAddr:: v PETSC_FORTRAN_TYPE_INITIALIZE

Satish

On Tue, 17 Mar 2020, Satish Balay wrote:

...

The issue is:

C has:

Vec v=NULL; Vec *v=NULL;

However its not clear how to implement this with current f90 interface.

I think we currently have:

Vec v = PETSC_NULL_VEC = 0 => the second one.

What you are looking for is the first one. I see this is automatically set. I don't see this initialization in petsc - so perhaps the compiler is doing this automatically? [atleast by gfortran]

Satish

-------------

Breakpoint 2, MAIN__ () at ex1f.F90:51 51 x = PETSC_NULL_VEC (gdb) list 33 28 ! 29 Vec x,b,u 30 Mat A 31 KSP ksp 32 PC pc 33 PetscReal norm,tol 34 PetscErrorCode ierr 35 PetscInt i,n,col(3),its,i1,i2,i3 36 PetscBool flg 37 PetscMPIInt size (gdb) p x $2 = ( v = -2 ) (gdb) p b $3 = ( v = -2 ) (gdb) p u $4 = ( v = -2 ) (gdb) p A $5 = ( v = -2 ) (gdb) p ksp $6 = ( v = -2 ) (gdb) p pc $7 = ( v = -2 ) (gdb) c Continuing.

Breakpoint 3, MAIN__ () at ex1f.F90:52 52 call MPI_Comm_size(PETSC_COMM_WORLD,size,ierr) (gdb) p x $8 = ( v = 0 ) (gdb)

On Tue, 17 Mar 2020, Mark Adams wrote:

...

...

Passing NULL to MatCreateVecs() means that you do not want a vector

out:

...

Yes, I want both vectors out and we pass it Vec that have been initialized with PETSC_NULL_VEC

...

https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatCreateVe...

...

I am guessing that this was broken in 3.7 so that it ignored NULL

input,

...

but we fixed that.

v3.7 has these CHKFORTRANNULLOBJECT. Well the "fix" broke working code

ex73f90t does not initialize the "x" vector that it gives to matcreatevecs_. Should we just remove initialization of our vectors to PETSC_NUILL_VEC?

Is the PETSc model that you don't inialized PETSc object to NULL because you check that pointers are valid PETSc pointers instead of testing on NULL? So maybe we should remove all these initializations.

Thanks, Mark

...

Thanks,

Matt

...

call MatCreateVecs(solver%KKTmat,solver%xVec2,solver%bVec2,ierr)

Petsc code: PETSC_EXTERN void PETSC_STDCALL matcreatevecs_(Mat *mat,Vec *right,Vec *left, int *ierr) { PetscPrintf(PETSC_COMM_SELF,"ZZZ 1) matcreatevecs_ start right=%p left=%p\n",right,left); CHKFORTRANNULLOBJECT(right); CHKFORTRANNULLOBJECT(left); PetscPrintf(PETSC_COMM_SELF,"ZZZ 2) matcreatevecs_ start right=%p left=%p\n",right,left); *ierr = MatCreateVecs(*mat,right,left); }

produces this:

ZZZ 1) matcreatevecs_ start right=0x7fffffff3758 left=0x7fffffff3760 ZZZ 2) matcreatevecs_ start right=(nil) left=(nil)

Shouldn't this be?

PETSC_EXTERN void PETSC_STDCALL matcreatevecs_(Mat *mat,Vec *right,Vec *left, int *ierr) { *ierr = MatCreateVecs(*mat,right,left); }

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

https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>