-
Notifications
You must be signed in to change notification settings - Fork 0
Description
Latest thinking at https://docs.google.com/document/d/1B1TLdeOMD44hwb7Cb4d09GOfHRQmElZJS5e3s6N2ccM
Hi all,
Below is my idea of what a fitting spec (script) might look like.
For context, an example of fitting with PINTS is found here, with lots more examples here.
PINTS interacts with models through the ForwardModel class, and with model+data pairs in the Single|MultiOutputProblem classes.
Base class
The user implements this class:
class FittingSpec(object):
"""
Abstract base class for all fitting specifications.
"""
@staticmethod
def output():
"""
Returns the variable to fit to, as an oxmeta annotation.
For example ``membrane_rapid_delayed_rectifier_potassium_current``.
"""
raise NotImplementedError
@staticmethod
def parameters():
"""
Returns a list where each entry specifies a type of parameter for the
:meth:`output()` variable, as an annotation.
For example::
return [
'conductance',
'forward_a',
'forward_b',
'backward_a',
'backward_b',
]
"""
raise NotImplementedError
@staticmethod
def fit(problem, parameter_counts):
"""
Performs a fit on the given ``problem`` and returns a vector of
obtained parameters.
The problem to optimise is given by ``problem``, which is either a
``pints.SingleSeriesProblem`` or a ``pints.MultiSeriesProblem``.
It contains both the model to fit and the data to compare to.
A list of ``parameter_counts`` is provided that lists the number of
parameters found in the CellML model of each type given in
:meth:`parameters()`.
The list has the same ordering as the list returned by
:meth:`parameters()`, so that its i-th entry provides the number of
parameters of type ``parameters()[i]``.
Returns a list (or any other sequence type) of obtained parameter
values.
"""
raise NotImplementedError
Weblab implementation
The weblab backend then implements some bit of python code that loads FC, scans a CellML model for parameters matching the annotations, wraps a call to FC in a pints.ForwardModel
, constructs a Problem
, and calls fit()
.
All of this is then run in some kind of sandboxed environment
The weblab frontend has some stand-alone bit of Python code that basically does this:
- import spec
- call output() and parameters()
- write the output of those methods to disk
To analyse a spec it runs the above code in a subprocess and reads (and deletes) the output file.
(Doing this in a subprocess stops syntax errors in fitting specs from breaking the front-end).