Recent changes:
- updated SPILS and DIRECT to separate functions for setting prec and jac 
  for EXPL vs. IMPL
- updated prec modules (bandpre and bbdpre) to work directly on internal memory
  instead of having another void*
- updated CPODES to deal with TSTOP without having two additional mode values
  (for the argument to CPode())
- updated to use a single user-supplied data pointer throughout (except for
  the data pointer to the error handler)





Not implemented yet:
- various functions needed for projection in WRMS norm 
  (in cpodes_dense and cpodes_lapack)
- function to compute consistent y' for implicit-form ODEs 
  (in cpodes_ic)
- add some more optional I/O functions for IC calculation

More tests needed:
- test quadrature integration
- test BAND linear solver for CP_IMPL case
- test BANDPRE and BBDPRE preconditioner modules
- recheck SPGMR, SPBCG, and SPTFQMR (particularly the CP_IMPL case) and test.

Under consideration:
- do I want to add a function to change from its default value of 1.0 the
  variable dqincfac (cpSpilsDQjtvImpl in cpodes_spils), like it's done in IDA?
- automatic stiff-nonstiff switch (through nonlinear solver switch)?
  We could add a Lipschitz constant estimator for this. But what about the
  influence of problem size (when using DQ Jacobians) or the relative cost 
  of fct/Jac. evals (when the user provides the Jacobian)?

NOTES: 

- At this time, unless we allocate one additional vector, we cannot return the 
  proper estimated local error vector if the error estimate was actually projected.
  (i.e. we still return acor/tq[2] when we really should return P*acor/tq[2], but we
  do not have P*acor anymore -- it was stored into a temporary vector). 

- To save an additional function evaluation at the projected state (i.e. finding
  yP' such that yP' = f(t,yP) or F(t, yP', yP) = 0, the latter also requiring
  a nonlinear solve with a Jacobian which is not readily available), we use a
  special trick in applying the projection correction (i.e. we do something slightly
  different than it's done for the application of the NLS correction) => potential
  problems when using Adams.




====================================================================================

An exhaustive list of things that need to be done in CPODES before a public release

====================================================================================

Development

(1) There are several portions that were not completely implemented:
- consistent intialization module:
  - complete 2nd step (computation of time derivatives) for the implicit-form ODE case.
  - add globalization of the projection (a line search algorithm) 
- internal direct dense linear solver module:
  - complete QR and QR with pivoting for oblique projection (i.e. projection in error norm)
  - implement Schur complement method for oblique projection 
- blas/Lapack direct dense linear solver module:
  - complete all 4 available decompositions (LU, QR, QRP, and SC) for oblique projection
- integration nonlinear solver module:
  - complete functional iteration method for implicit-form ODEs (this may be tricky and maybe not worth it - this combination is currently deemed illegal at initialization)
- main integratin module
  - complete projected Adams method (probably not in a first stage since I'm not clear yet on the theoretical implications - this one needs more thinking...)


(2) Additionally, there are a few things that Sherm, Peter, and I agreed need to be added:
- extend the event detection algorithm to capture transitions to exact zeros (currently only zero-crossings are reported)
- add option to reset the internal history to the location of the last event detected (in order to allow integration without restarts over some types of discontinuities)

(3) Some general code clean-up:
- check comments throughout
- remove all debug compiler directives
- finalize API to bring CPODES 100% in sync with the current development versions of the other SUNDIALS solvers

(4) It would also be nice to have an add-on module to facilitate integration of index-3 DAEs fom multibody simulations outside SimTK. Reformulating these equations as ODEs with invariants and hand-coding them is not easy except for trivial mechanisms (SimTK does that behind the hood). For this it may also be convenient to extend the code to use the index-1 DAE form rather than the underlying ODE for these systems.


Examples

Each solver in the SUNDIALS suite is shipped with a set of examples which are meant to excercise as much of the solver as possible and cover as many of the variuous options. For CPODES I currently have only a handful of examples coded (out of which only 4 serial examples and 1 parallel example are CPODES-specific, in that they could not be solved with either CVODE or IDA).

Testing

Quite a bit more testing would be required, both to make sure all options are exercised and to help deciding on the best possible default values for many of the algorithmic constants (all the other codes in SUNDIALS have a very long history and the heuristics in those codes have been tuned based on considerable experience).


Documentation

For each of the SUNDIALS solvers (4 in the current release, 5 in the next one), we provide two documents, a "User Guide" and an "Example Programs". The former is a combination manual/reference and includes a mathematical description of the algorithm(s), typical usage directions and an exhaustive list of all functions in the API. Additionally, it includes installation instructions as well as directions for extending the solver (with user-provided module replacements). Each User Guide is at least 100 pages long (the one for CVODES is ~170 pages long). The "Example Programs" document contains step-by-step descriptions of a few selected examples distributed with the code and are 20-30 pages long.

For CPODES, the User Guide would probably run towards the longer end of the spectrum as it would have to practically include as a subset a (modified) CVODE guide. 


Ongoing work

Since it is unlikely that CPODES will be released before the next SUNDIALS version (which I do hope to get out soon...) CPODES will have to be kept up-to-date with the development version of SUNDIALS (for example, I will soon start working on a project under which I hope to sneak-in :-) support for sparse direct linear algebra in SUNDIALS.)


