Updated TO-DO.txt file (removed finished items)
- CVODES serial
- KINSOL
-2. In all solver Dls interfaces: add in checks to all SUNMatrix and
- SUNLinsol calls (I forgot to check SUNMatZero, so perhaps others as
- well).
-
-3. In solver Spils and Dls interfaces, ensure that I consistently
- check that the integrator and linear solver memories are non-NULL
- (this is currently somewhat inconsistent).
-
-4. Revisit ATSetup idea. It is currently not called frequently enough
+2. Revisit ATSetup idea. It is currently not called frequently enough
to support the main use: for iterative linear solvers, allow a user
to precompute some information regarding J so that they can
subsequently perform (multiple) J*v evaluations. This should be
the Newton iteration so that iterative methods could use current
Jacobian information at each Newton step.
-5. Update documentation on Dls and Spils interfaces for all
+3. Update documentation on Dls and Spils interfaces for all
integrators. [CVODE is finished]
-6. Revisit CVODE(S) 'diagonal' linear solver interface w.r.t. J and
+4. Revisit CVODE(S) 'diagonal' linear solver interface w.r.t. J and
gamma updates. It currently supports lagging both for a
user-defined number of steps, but old interface always lagged J
but forced use of the current gamma (through unraveling M-inverse =
setting the parameter. The parameter would then be used inside the
diagonal DQ approximation routine.
-7. Consider update to SUNMatrix 'copy' routine to swap order of
+5. Consider update to SUNMatrix 'copy' routine to swap order of
arguments (second is a copy of the first) to match N_Vector and
previous matrix operations.
-8. Revisit scaling vectors with PCG (without preconditioning) -- this
+6. Revisit scaling vectors with PCG (without preconditioning) -- this
seems to work improperly now. Perhaps it is the testing code, or
maybe the solver itself.
-9. idaFoodWeb_kry_omp had been explicitly disabled from our testing
+7. idaFoodWeb_kry_omp had been explicitly disabled from our testing
(in the examples/ida/C_openmp/CMakeLists.txt file). Why? It runs
correctly, although my results differ from the 'answer' file.
Perhaps this problem should be investigated more thoroughly and
added back in?
-10. Revisit the question of the differencing parameter used in the
+8. Revisit the question of the differencing parameter used in the
IDADls and IDASDls interfaces. Previously we had different
increments for GMRES than for BiCGStab and TFQMR; currently these
all use the GMRES value, but that value seems off in general (see
internal check to see if the LS object is actually a SUNSPGMR
object (perhaps check if LS->ops->solve == SUNLinSolSolve_SPGMR ?)
-11. Test whether LAPACK can solve NxN problems where although N can be
+9. Test whether LAPACK can solve NxN problems where although N can be
stored as an int32_t, N^2 cannot. Our old interface stored all
integers relating to dense/band matrices as 64-bit, but called
LAPACK with 32-bit 'N' values -- was this nonsense? If LAPACK can
use 64-bit integers for the actual 1D data array, to match our
previous support.
-12. Add <solver>Cls interfaces to all integrators for 'custom' linear
+10. Add <solver>Cls interfaces to all integrators for 'custom' linear
solvers. These should:
- assume a SUNMatrix object is provided
- assume an iterative linear solve is performed
