Matthew Knepley <[email protected]> writes: > On Fri, Oct 20, 2017 at 4:21 PM, Jed Brown <[email protected]> wrote: > >> Matthew Knepley <[email protected]> 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.
