I recently discovered that COPASI does not actually use the value it calls 'absolute tolerance' as the absolute tolerance in its ODE solver. Instead, it multiplies that value by the value of the elements of the state vector*, creating an absolute tolerance vector, which it then uses.
There actually is already a term in KiSAO that Jonathan Karr got from PySCeS: "absolute tolerance adjustment factor" (571), which is described (in KiSAO) as 'how much to adjust the absolute tolerance'. This is not quite how the PySCeS documentation describes it, to wit:
Additionally, CVODE allows per step step-size optimisation and automatic tolerance scaling:
'cvode_abstol': 1.0e-15
'cvode_abstol_factor': 1.0e-8
'cvode_auto_tol_adjust': True
'cvode_mxstep': 1000
'cvode_reltol': 1.0e-9
'cvode_stats': False
cvode_abstol is considered to be the minimum absolute tolerance, PySCeS first uses the initial species values multiplied by cvode_abstol_factor (so that [s]*[factor] >= [abstol]) to calculate its absolute tolerance. Once the simulation is underway PySCeS periodically readjusts the absolute tolerance on a per species basis based on the current species value.
I believe that KiSAO's 'absolute tolerance adjustment factor' is essentially a combination of PySCeS's 'cvode_abstol_factor' and 'cvode_auto_tol_adjust', i.e. if the term 571 is present, that would mean in PySCeS that cvode_auto_tol_adjust should be 'True' and cvode_abstol_factor' should be set to 571's value (i.e. 1e-8).
I don't know why PySCeS only allows this for CVODE when COPASI uses the same thing for LSODA. It seems to me that it could be used for either.
At any rate, I believe that term 571 is what COPASI was doing for LSODA, what roadrunner is doing now for CVODE (now that I changed it to match COPASI, since it worked so well), and what PySCeS is doing with its cvode_abstol_factor. Does this sound correct? If so, I propose that COPASI and roadrunner start using 571 instead of 211 ('absolute tolerance') when exporting SED-ML.
-Lucian