Release notes for sbmlsim 0.16.0

COPASI as a second simulation engine, the variability between the subjects of a fit with its visual predictive check, and a single run of differential evolution which uses every core of a fit.

Results which change: a fit of differential evolution without an explicit updating, which updates its population once per generation (updating="deferred") instead of after every trial vector, also on one core. A fit of differential evolution of an earlier version is repeated with updating="immediate".

Features

• COPASI is a second simulation engine (#219, #434). Simulator(engine="copasi") runs the same Simulation, Scan and observables as roadrunner, compiled to the same plan, and gives a result of the same shape (dimensions, coordinates, units, the two rows at a change), so the results of both engines compare directly, e.g. to verify a result of roadrunner with an independent simulator. It runs Simulator.simulate and Simulator.run (serially and in the pool), simulation experiments, the evaluation of a fit problem at stored parameters (problem.set_simulator(Simulator(engine="copasi")), metrics and report; optimizing with COPASI is no goal), sensitivity analyses and the propagation of uncertainty. The engine is recorded in the results, the JSON of an experiment and of a problem and the report. COPASI is the optional extra copasi.
• The variability between the subjects of a fit and its visual predictive check (#436). OptimizationProblem.predictions(x, factors=) evaluates a subject: every value a simulation assigns to a target is multiplied by the factor of the target (Plan.scaled), a target it does not assign gets the value of the model times the factor, so the subjects vary around the inputs every experiment sets for its study group. sbmlsim.fit.variability declares the variability as relative distributions of targets (Variability({"CL": LogNormal(cv=0.3)}), correlated by Covariances, e.g. the omega matrix of the logarithms), with between=Variability(...) the variability between the studies, whose factors the subjects of a study share. predictive_check evaluates the mappings for the subjects, nested in parameter vectors (e.g. draws of the uncertainty of the fit) and in studies, and compares a data point of a group of N subjects with the means of virtual groups of N subjects of a study (the geometric mean for data with a geometric SD), an individual with the subjects: the bands of a visual predictive check and their coverage of the data, per point and per mapping.
• Differential evolution evaluates the population of a run on the workers of the fit (#433). A fit parallelized over its runs only, so a single global optimization (n_cores=4, one run) ran on one core, e.g. more than 4 hours for a PBPK model. A worker cannot start workers of its own, so split_cores of sbmlsim.fit.runner gives the workers either to the runs, when there are as many runs as workers or more and always for least squares, or to the population: the runs of differential evolution then run one after another, and every run evaluates the members of its population on all workers of one pool, which the fit stops after it; the polishing by L-BFGS-B evaluates the points of its gradients on the workers together. The workers initialize the problem before the timeout of a run starts. A fit sets updating="deferred" unless it is given, and the costs return in the order of the members, so a seed gives the same optimum, cost and trajectory for any number of workers. The trajectory has every evaluation, the timeout of a run gives up the members which are not evaluated and keeps the best parameters, a member whose worker dies runs again alone (the restarts of the pool are counted per generation) and one which kills its worker alone has an infinite cost; members which fail together once three restarts of a generation are spent end the run with a PoolError. updating="immediate" keeps the former results and evaluates the population serially; workers of SciPy other than 1 is refused, n_cores gives the workers. On the HCTZ problem of the tests (8 ms per evaluation) one run takes 3.9 to 4.7 s on 4 workers instead of 7.8 s, a generation 2.6x less; a PBPK model with seconds per evaluation gains more.