To me IFunction really means IFunction obtained from implicit part (-
potentially explicit part depending on the solver). It is not just the
implicit part, it is the implicit function (not part). The default is
just the part thing. To me this makes it simple, less interfaces and it
is transparent to the user. This will change the interfaces in all
solvers, will fix little and make up really long names along the way. I
mean this may confuse users by implying that there are multiple parts
whereas most users have just one.
My point is the following: how does this affect how Matt implements
things? If you two find this is really worth it, I have nothing against
it. To me it's just a name.
Emil
On 10/20/17 11:22 AM, Barry Smith wrote:
Emil, see my email just sent. We need to rename this function (and its
Jacobian partner).
On Oct 20, 2017, at 11:20 AM, Emil Constantinescu <emcon...@mcs.anl.gov> wrote:
Matt, that depends, if TS method is imex, then it computes just F, not F-G so
your argument is not correct. If the method can do only implicit it computes F
and subtracts G *if defined*. If the TS method can only do explicit and you
define F then it fails.
Again, this has to do with the TS methods and PETSc doing the work for you of
packing the functions in different ways.
Emil
Matt
Now internally, because different solvers have different needs the
IFunction ... presented to the TS solver may look differently. This
is a design choice - if you are not a TS developer it should not
affect you.
This is a design decision: if implemented at this level, we avoid
having every TS method be aware of the upper level functions.
Emil
--
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.caam.rice.edu/~mk51/>
