Refactoring of TS handling of reuse of Jacobians after shifts and scalings have been applied
Created by: BarryFSmith
The TS management of reuse of right hand side Jacobians after shifts and scalings have been applied is convoluted and prone to bugs. It needs to be refactored to be simpler and have test cases for all possible combinations. Rather than having each individual struggle with understanding it and modifying it I propose we work together to understand the current behavior, add new test cases, and design and refactor the code. It is important that we all be involved in the process and understand the new code or we likely miss certain cases and not trust the outcome @jedbrown @stefano_zampini @caidao22 Logically it should be possible to make it much simpler than the current code, it really doesn’t do all that much, but previous attempts to remove bugs have just made it even more convoluted and difficult to understand.
So the case I am discussing is when the user provides a RHS Jacobian and does not provide a IJacobian function and IJacobian matrix. Is this the case we care about, or is there more?
The special cases are
-
A constant time independent RHS linear operator
-
A RHS linear operator that depends on time
-
A nonlinear problem but where the user is willing and able to update only parts of the Jacobian because they know other parts are Jacobian do not change. A special case of this is perhaps
- when only the diagonal of the Jacobian changes (I don’t believe we handle this now in particular)
-
Have I missed any cases?
I think it is also important to not be afraid of refactoring the code by adding additional functions. For example, perhaps there should be different TSComputeIJacbian() functions for different cases instead of trying to handle everything in one overloaded function. Also we should not be afraid of changing the user API if that improves the refactoring significently.