<div dir="ltr">OK, so we could check if (obj==FORTRAN_TYPE_INITIALIZE) .... and remove all of our initializations.<div>And then MatCreateVecs should work.<br><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 17, 2020 at 3:52 PM Satish Balay <<a href="mailto:balay@mcs.anl.gov">balay@mcs.anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Ah - found it. So PETSc is doing this initialization for you.<br>
<br>
config/BuildSystem/config/compilersFortran.py:    help.addArgument('Compilers', '-with-fortran-type-initialize=<bool>',   nargs.ArgBool(None, 1, 'Initialize PETSc objects in Fortran'))<br>
config/BuildSystem/config/compilersFortran.py:      self.addDefine('FORTRAN_TYPE_INITIALIZE', ' = -2')<br>
src/vec/f90-mod/petscvec.h:        PetscFortranAddr:: v PETSC_FORTRAN_TYPE_INITIALIZE<br>
<br>
Satish<br>
<br>
On Tue, 17 Mar 2020, Satish Balay wrote:<br>
<br>
> The issue is:<br>
> <br>
> C has:<br>
> <br>
> Vec v=NULL;<br>
> Vec *v=NULL;<br>
> <br>
> However its not clear how to implement this with current f90 interface.<br>
> <br>
> I think we currently have:<br>
> <br>
> Vec v = PETSC_NULL_VEC = 0 => the second one.<br>
> <br>
> What you are looking for is the first one. I see this is automatically<br>
> set.  I don't see this initialization in petsc - so perhaps the<br>
> compiler is doing this automatically? [atleast by gfortran]<br>
> <br>
> Satish<br>
> <br>
> -------------<br>
> <br>
> Breakpoint 2, MAIN__ () at ex1f.F90:51<br>
> 51            x = PETSC_NULL_VEC<br>
> (gdb) list 33<br>
> 28      !<br>
> 29            Vec              x,b,u<br>
> 30            Mat              A<br>
> 31            KSP              ksp<br>
> 32            PC               pc<br>
> 33            PetscReal        norm,tol<br>
> 34            PetscErrorCode   ierr<br>
> 35            PetscInt i,n,col(3),its,i1,i2,i3<br>
> 36            PetscBool  flg<br>
> 37            PetscMPIInt size<br>
> (gdb) p x<br>
> $2 = ( v = -2 )<br>
> (gdb) p b<br>
> $3 = ( v = -2 )<br>
> (gdb) p u<br>
> $4 = ( v = -2 )<br>
> (gdb) p A<br>
> $5 = ( v = -2 )<br>
> (gdb) p ksp<br>
> $6 = ( v = -2 )<br>
> (gdb) p pc<br>
> $7 = ( v = -2 )<br>
> (gdb) c<br>
> Continuing.<br>
> <br>
> Breakpoint 3, MAIN__ () at ex1f.F90:52<br>
> 52            call MPI_Comm_size(PETSC_COMM_WORLD,size,ierr)<br>
> (gdb) p x<br>
> $8 = ( v = 0 )<br>
> (gdb) <br>
> <br>
> <br>
> <br>
> On Tue, 17 Mar 2020, Mark Adams wrote:<br>
> <br>
> > ><br>
> > > Passing NULL to MatCreateVecs() means that you do not want a vector out:<br>
> > ><br>
> > ><br>
> > Yes, I want both vectors out and we pass it Vec that have been initialized<br>
> > with PETSC_NULL_VEC<br>
> > <br>
> > <br>
> > ><br>
> > > <a href="https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatCreateVecs.html" rel="noreferrer" target="_blank">https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatCreateVecs.html</a><br>
> > ><br>
> > > I am guessing that this was broken in 3.7 so that it ignored NULL input,<br>
> > > but we fixed that.<br>
> > ><br>
> > ><br>
> > v3.7 has these CHKFORTRANNULLOBJECT. Well the "fix" broke working code<br>
> > <br>
> > ex73f90t does not initialize the "x" vector that it gives<br>
> > to matcreatevecs_. Should we just remove initialization of our vectors to<br>
> > PETSC_NUILL_VEC?<br>
> > <br>
> > Is the PETSc model that you don't inialized PETSc object to NULL because<br>
> > you check that pointers are valid PETSc pointers instead of testing on<br>
> > NULL? So maybe we should remove all these initializations.<br>
> > <br>
> > Thanks,<br>
> > Mark<br>
> > <br>
> > <br>
> > >   Thanks,<br>
> > ><br>
> > >     Matt<br>
> > ><br>
> > ><br>
> > >> call MatCreateVecs(solver%KKTmat,solver%xVec2,solver%bVec2,ierr)<br>
> > >><br>
> > >> Petsc code:<br>
> > >> PETSC_EXTERN void PETSC_STDCALL matcreatevecs_(Mat *mat,Vec *right,Vec<br>
> > >> *left, int *ierr)<br>
> > >> {<br>
> > >> PetscPrintf(PETSC_COMM_SELF,"ZZZ 1) matcreatevecs_ start right=%p<br>
> > >> left=%p\n",right,left);<br>
> > >>   CHKFORTRANNULLOBJECT(right);<br>
> > >>   CHKFORTRANNULLOBJECT(left);<br>
> > >> PetscPrintf(PETSC_COMM_SELF,"ZZZ 2) matcreatevecs_ start right=%p<br>
> > >> left=%p\n",right,left);<br>
> > >>   *ierr = MatCreateVecs(*mat,right,left);<br>
> > >> }<br>
> > >><br>
> > >> produces this:<br>
> > >><br>
> > >> ZZZ 1) matcreatevecs_ start right=0x7fffffff3758 left=0x7fffffff3760<br>
> > >> ZZZ 2) matcreatevecs_ start right=(nil) left=(nil)<br>
> > >><br>
> > >> Shouldn't  this be?<br>
> > >><br>
> > >> PETSC_EXTERN void PETSC_STDCALL matcreatevecs_(Mat *mat,Vec *right,Vec<br>
> > >> *left, int *ierr)<br>
> > >> {<br>
> > >>   *ierr = MatCreateVecs(*mat,right,left);<br>
> > >> }<br>
> > >><br>
> > >><br>
> > ><br>
> > > --<br>
> > > What most experimenters take for granted before they begin their<br>
> > > experiments is infinitely more interesting than any results to which their<br>
> > > experiments lead.<br>
> > > -- Norbert Wiener<br>
> > ><br>
> > > <a href="https://www.cse.buffalo.edu/~knepley/" rel="noreferrer" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br>
> > > <<a href="http://www.cse.buffalo.edu/~knepley/" rel="noreferrer" target="_blank">http://www.cse.buffalo.edu/~knepley/</a>><br>
> > ><br>
> > <br>
> <br>
> <br>
<br>
</blockquote></div>