[petsc-dev] TS Terminology

[Jed Brown]

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.