[petsc-dev] TS Terminology

[Brad Aagaard]

On 10/21/17 7:00 AM, Jed Brown wrote:
> Matthew Knepley <knepley at gmail.com> writes:
>
>> On Sat, Oct 21, 2017 at 9:28 AM, Jed Brown <jed at jedbrown.org> wrote:
>>
>>> Matthew Knepley <knepley at gmail.com> writes:
>>>
>>>> On Fri, Oct 20, 2017 at 4:21 PM, Jed Brown <jed at jedbrown.org> wrote:
>>>>
>>>>> Matthew Knepley <knepley at gmail.com> writes:
>>>>>
>>>>>>> Note that TSComputeIFunction is very much like SNESComputeFunction,
>>>>>>> which includes
>>>>>>>
>>>>>>>   if (snes->vec_rhs) {
>>>>>>>     ierr = VecAXPY(y,-1.0,snes->vec_rhs);CHKERRQ(ierr);
>>>>>>>   }
>>>>>>>
>>>>>>> Why haven't you complained about that?
>>>>>>>
>>>>>>
>>>>>> Good point. I did not notice. This came up because the initialization
>>>>>> of input vectors is inconsistent between TSComputeIFunction() and
>>>>>> TSComputeIFunctionLocal(). The former does not zero the output vec,
>>>>>> but the later does.
>>>>>
>>>>> The latter function doesn't exist so maybe you mean
>>>>> TSComputeIFunction_DMDA with ADD_VALUES?  That's because the DMDA needs
>>>>> it when using ADD_VALUES, just like SNESComputeFunction_DMDA.  When
>>>>> using INSERT_VALUES, the user is responsible for setting every entry.
>>>>> Is any of this different from SNES?
>>>>>
>>>>
>>>> No I mean TSComputeIFunction_DMLocal().
>>>
>>> That's just some code you wrote for finite elements when you hard-coded
>>> it for ADD_VALUES.
>>>
>>>   ierr = DMLocalToGlobalBegin(dm, locF, ADD_VALUES, F);CHKERRQ(ierr);
>>>   ierr = DMLocalToGlobalEnd(dm, locF, ADD_VALUES, F);CHKERRQ(ierr);
>>>
>>> It's analogous to what TSComputeIFunction_DMDA does when you set
>>> ADD_VALUES.  Note that with INSERT_VALUES, as is typically used for FD
>>> and FV, you can assemble directly into the global vector
>>>
>>>> So if you use DMTSSetIFunction() you get different initialization
>>>> behavior than if you use DMTSSetIFunctionLocal().  This is what Brad
>>>> was complaining about originally.
>>>
>>> Maybe you should document your finite element interfaces better.
>>>
>>
>> I think the fair statement would be that it is not documented either way.
>
> Yes, it's EXACTLY the same as how SNESComputeFunction does not zero the
> vector, but SNESComputeFunction_DMLocal does because it's a finite
> element/ADD_VALUES interface.  You could start by documenting that.

 From the perspective of a PETSc user, I think 
TSComputeFunctionWhatever() should zero out the global function vector 
before calling the user ifunction and user rhsfunction. The top-level 
function knows when to zero out the function vector; the user doesn't 
unless they look at the details of the calling function. Additionally, 
the user code should not have to change if the top level calling 
function decides to reuse the global function vector rather than using a 
temporary. This way, it doesn't matter if the user inserts values into 
the global vector using ADD_VALUES or INSERT_VALUES. With the current 
implementation the user must zero out of the global vector in both the 
user ifunction and the user rhsfunction in assembling with ADD_VALUES. 
If someone changes the ComputeIFunctionWhatever() to reuse the same 
global vector in both calls, it would break the user code because 
intermediate values in the global function vector would get zeroed out. 
It seems obvious to me that the most robust approach is to zero out the 
global function vector in the top level code (TSComputeFunctionWhatever) 
so that the user code can be written to work with INSERT_VALUES or 
ADD_VALUES, doesn't care about the calling order of the user ifunction 
and user rhsfunction, and works with either temporary global function 
vectors being passed in or the same global function vector.

... and, yes, it would be nice if the state of the global vectors passed 
to the user were documented or at least assumptions about what the user 
needs to do are clearly documented in the API.

Brad