[petsc-dev] MatCreateVecs from Fortran problem

Tue Mar 17 14:52:46 CDT 2020

OK, I misspoke. We do use these x/bVec2 Vecs in our code sometimes.

So PETSc did change from v3.7 (Albert and I have been chasing this down for
a week). I don't understand why but we have been building the same code
base with v3.7 and maint all week.

It looks to me like optional pointer return arguments are not going to work
in Fortran and we need to work around it.

On Tue, Mar 17, 2020 at 3:09 PM Mark Adams <mfadams at lbl.gov> 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/>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20200317/d182355b/attachment-0001.html>