[petsc-dev] MatCreateVecs from Fortran problem

Satish Balay balay at mcs.anl.gov
Tue Mar 17 14:25:29 CDT 2020


Well - if the issue is not catching errors - current petsc has cleaner mode of adding CHKERRA(ierr) in fortran.

Satish

On Tue, 17 Mar 2020, Mark Adams wrote:

> I see what is happening. I think. We have:
> 
>   call MatCreateVecs(solver%KKTmat,solver%xVec2,solver%bVec2,ierr)
>   call VecDuplicate(solver%bVec2,solver%rVec2,ierr)
> 
> Well it turns out that [x|b]Vec2 are used only in debugging code that is
> turned off. rVec2 is only used in a SNESSetFunction call.
> 
> What we see in the code is that this call to VecDuplicate throws an error,
> which we do not catch, in the current PETSc but is silent in v3.7.7.
> Unless MatCreateVecs does create bVec2 in v3.7 (ie, CHKFORTRANNULLOBJECT did
> not null it out back then, which BTW is not a great side effect of a "CHK"
> macro IHMO).
> 
> So we are are seeing a bunch of error messages but the code chugs along
> after that, for a while. We do get another error eventually, that was a
> NULL Vec as I recall. I am guessing that SNESSetFunction does not like to
> get a NULL vector, but we will have to move on to debugging that.
> (Did SNESSetFunction require a non-null vector since v3.7?)
> 
> Thanks,
> Mark
> 
> 
> On Tue, Mar 17, 2020 at 2:52 PM Matthew Knepley <knepley at gmail.com> wrote:
> 
> > On Tue, Mar 17, 2020 at 2:48 PM Mark Adams <mfadams at lbl.gov> wrote:
> >
> >>
> >>
> >> On Tue, Mar 17, 2020 at 2:25 PM Matthew Knepley <knepley at gmail.com>
> >> wrote:
> >>
> >>> On Tue, Mar 17, 2020 at 2:16 PM Mark Adams <mfadams at lbl.gov> 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
> >>>>
> >>>
> >>> That is wrong.
> >>>
> >>>
> >>>>
> >>>>
> >>>>>
> >>>>> https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MatCreateVecs.html
> >>>>>
> >>>>> 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
> >>>>
> >>>
> >>> How could v3.7 have the check? If so, you code would be broken.
> >>>
> >>
> >> Barry did it 12 years ago:
> >>
> >>
> >> https://gitlab.com/petsc/petsc/-/commit/7c54600c425fb8d0ad4ad4bb40f7fac17c980c51
> >>
> >
> > What you are saying does not make sense. You are saying:
> >
> >   1) We are passing in NULL Vec objects
> >
> >   2) Barry put in code to check for such objects
> >
> >   3) We are getting valid Vec objects back
> >
> > One of those statement is not true
> >
> >   Thanks,
> >
> >      Matt
> >
> >
> >>
> >>>
> >>>> ex73f90t does not initialize the "x" vector that it gives
> >>>> to matcreatevecs_. Should we just remove initialization of our vectors to
> >>>> PETSC_NUILL_VEC?
> >>>>
> >>>
> >>> Yes.
> >>>
> >>>
> >>>> 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.
> >>>>
> >>>
> >>> I am not sure what you are asking here.
> >>>
> >>
> >> That we should not initialize our PETSc Vec,Mat,etc. with some sort of
> >> NULL.  I am sure this is the case.
> >>
> >>
> >>>
> >>>   Matt
> >>>
> >>>
> >>>> 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/>
> >>>>>
> >>>>
> >>>
> >>> --
> >>> 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/>
> >>>
> >>
> >
> > --
> > 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/>
> >
> 



More information about the petsc-dev mailing list