There seem no urgent changes left. The toolbox can be sent as a preliminary
version to some developers. The toolboxes should be published one after the
other.
Changes before publication (summaries of detailed lists below):
coco:
- clean up finite state machine, separate into continuation and manifold
parts
- constructor for manifold code (sets a number of functions called by
the fsm)
- symbolic parameter names and dynamic allocation of parameters
- location of singular special points with subdivision on line segment,
'singular' flag in coco_add_func
- allow function handle instead of a string label for events to
handle nontrivial events that are a combination of events for
several test functions (for example, folds and branch points)
- refine routine (coco_apply, coco_refine ??) for postprocessing of
a bifurcation diagram
mpbvp:
- include rescaling factors, parameters and possibly time (??) as
variables
- write functions for remeshing and further manipulations so that a full
set of function is available for other developers.
- adaptation, bandwidth reduction and computation of Floquet multipliers
in a forthcoming publication?
===========================================================================
general:
- introduce a uniform naming convention for variables, for example,
for filenames such as FName, mfname, etc.
- associate sol with func and xsol with xfunc; better: add pointers to
dictionary entry of solution structures
- clean up state machine functions: group code by task and to which
object it belongs to make replacements easier
- error tests in functions, in particular, check in and out arguments
- create correct data dependency tree to help clean up dependencies
and code
print_data, print_headline:
- make principle solution measure and hedline names for
parameter and principle solution measure user-definable
coll_linsolve:
- develop and use bandwidth reduction
mpbvp:
- allow restarts from previous solution
- allow parameters as variables (tori, Arnol'd tongues), introduce
appropriate index, which may be empty, and substitute and expand
list of parameters correctly
- stable computation of Floquet multipliers with generalised EVP
- compute interpolation error (on standard element)
- hybrid bvps: treat last boundary condition differently so that general
two-point hybrid bvps can be treated (last bc may depend on whole x,
not just boundary points like, for example, the periodicity condition),
specify as cell-array: {'hybrid', 'periodic'}; generalise periodic to
multi-segments but use only the very first and last boundary point;
initialisation in a loop over boundary conditions! compute bc in a loop
over boundary conditions
- save both time meshes plus x at the base points, save solution segments
separately
- compute proper L2-norm transforming the whole solution to [0 1],
such that the norm is independent of the number of segments
- allow mixing of internal and external parameters in continuation;
see matlab/continuation/ODEQPFOFM/tor_*.m as example
- allow parameters as additional variables (when more boundary
conditions than necessary are provided)? (OR: as user conditions)
- include amplitude as internal parameter in 'periodic'
- support all variants of vectorised/non-vectorised RHS and provided
derivatives
- include remeshing strategy:
NTST = [ [INIT MIN MAX] ; ... ]
- pmap and dmap sparse (?)
coco:
- indicate for each user function if bandwidth reduction is required,
for this, allow attaching properties to user functions via argunemt
pairs of type ('name', value) in coco_add_func
- allow to exclude vars/pars that occur multiple times through equations
like a=b; b=c from adaptation aso.; it is a bit confusing that certain
variables get higher wheights when they are duplicated for convenience
- handle cases with one-sided continuation or just Newton iteration:
ItMX = 0 | [0 0] | [n 0] | [], or par_int = [p0 p0] | [p p0]
- weight vector for norms and scalar products,
for example, NWTN: norm(w.*d)<TOL
- is it possible to write a check-settings function to validate
arguments for coco_set?
- introduce states for intermediate Newton iteration in
check_solution and compute_events
- try to split coco_print_data into save and print functions
- allow function handle for equation
step-size control:
- make step-size control an independent object that a predictor
may or may not use
predictor:
- use external step-size control if heuristic necessary;
point to current step-size method by dictionary entry
- reformulate predictor to use an internal point list;
this would make boundary handling much easier and consistent
with multi-dimensional continuation
- use automatic adaptation with additional constraint
0 = exp( arc(u(0)-u(-1), u(1)-u(0)) - arc_max ) - 1
+ exp( ||u(1)-u(0)|| - h ) - 1
- use quadratic predictor with three-point formula
linsolve:
- introduce simple scaling method
- introduce linsolve options for generating index-mappings
for bandwidth-reduction of bordered matricies, may be ignored
by linear solvers (should be transparent to continuation method)
bd:
- get rid of duplicate entry for first continuation step
- default functions should be coded for 'bddat_usr_init' and
'bddat_usr_data'. The latter functions should be renamed to apply to the
algebra toolbox. The default construction will eliminate the need for
'if' statements in 'bddat_init', 'bddat_append' and 'bddat_prepend'.
A more versatile construction for the continuation of internal boundary
points, rather than relying on the branch idea will also simplify the
'bddat_insert', 'bddat_append', and 'bddat_prepend' functions.
I think this is worthwhile to consider at this point. What is the
appropriate structure in which the bifurcation data should be saved in
this case?
EP, MPBVP:
- flag for including variational equation in continuation, otherwise
allow evaluation after correction only
xfunc:
- should xfunc have an update function?
gcont_nwtn_step:
- in MaxStep test allow ga>1 if ga0>1 (include ga in test!)
- use residuum in convergence test