The concept (more complex than should be described in this comment) underlies the way that objects of Parameter
, KineticVariable
and ExchangeFlux
are converted from Symbolics to C++ code consistently when writing the dynamic library. This is the solution I came up with, which I am sure could still be improved considerably. If confusing I think we should organise a video chat to discuss in more detail and perhaps together come up with an improved solution.
For parameters this approach allows particular parameter values to be updated in dynamic library for a model using the update_parameters
method, as many times as required. Related but slightly different is issue #31 for KineticVariable
and ExchangeFlux
, where the current implementation is sufficient provided the guideline provided there is adhered to by the user. Ultimately solving the outstanding problem requires some more thinking about...
If implemented, I think also needs to be applied to KineticVariable
and ExchangeFlux
classes (respective attributes)
OK, yes
This can be applied to KineticVariable
and ExchangeFlux
classes as well
I thought these were required for the optlang.symbolics.Symbol
init (for which this is a derived class), but perhaps not?
UPDATE: Sorry, just read your suggestion below!
Yes, quite possibly. In any case for now the requirement is to provide new parameters as a numpy
array (i.e. without mapping to id
s) and so we need to work on a solution that allows this (see suggestion in #30).
davidtourigny (6b442110) at 16 Sep 16:57
simplify argument name
OK, that makes sense
davidtourigny (453f6f9f) at 16 Sep 16:45
Apply 1 suggestion(s) to 1 file(s)
davidtourigny (8fca7e7b) at 16 Sep 16:44
Apply 1 suggestion(s) to 1 file(s)
The stochiometric constraints of the LP problem (not the bounds) are of course discrete, but I don't think we should be allowing the user to vary those!
That would be up to the user, and is a possibility. But I think for the current implementation we should not make things too difficult and even Hill coefficients should be treated continuously.
Actually, I would argue that the only requirement for using discrete coefficients should pertain to having knowelege of a biological mechanism for (e.g.) binding that involves multiple subunits... the DFBA framework being flux-based is particularly agnostic to such biological knowledge.
Yes the way I got around this was using
optlang.symbolics.Symbol.__init__(kinetic_variable, "new_name")
so effectively creating a new object. Perhaps there is a cleaner way to do this?
Done
I only know superficially about this paper from before, but can read again in detail if you think relevant.
The ability to modify parameters of the LP through optlag would certainly be a very useful addition to this current framework. At present, the parameters for optimisation are those in the symbolic expressions for the ODE or variable upper/lower LP bounds. I would be very keen to consider the additional possibility of incorporating "constant" LP parameters, as my understanding is that the gradient-free frameworks will allow this and it would prove a very nice addition.
Preliminary implementation of objective function now provided in example6. This required adding new class Parameter
together with new DfbaModel
methods add_parameters()
and update_parameters()
. These will probably need to be cleaned up somewhat, but work well for now.
In the example script, a simple objective function is defined (lines 36-44) that takes as arguments a DfbaModel
, a List
corresponding to simulated measured observables (for Biomass only), and a Dict
of parameter values. The generic parameters of the model are then instantiated with their values on lines 48-51 where those to be estimated are objects of the new Parameter
class. The model is defined in the usual way on lines 55-84, except for an additional call to the new method add_parameters()
on line 69. Finally, noise is added to an initial simulation with these parameter values on lines 88-91 to generate measured observables (Biomass) for the required time points, and a grid scan of parameters is performed on lines 95-103 returning the value of the objective function at each point.
Still required:
clean up to pass CI
replace objective function arguments with numpy arrays, as described in comments here #30
OK sure, I think that can be done. @Midnighter and @carrascomj if you would like to get involved at this stage to comment on/tidy up any of my Python code then please feel free to do so!
OK well in that spirt what I have currently implemented should be almost sufficient, two parameters with a range of sensible values and a very simple model. I would prefer to try with this rather than building a toy one from scratch that might not capture the true nature of a DFBA problem, unless simulation time ends up particularly limiting for testing purposes (it also reduces the workload involved in coming up with a reasonable toy model ;)). If you can take a look at the implementation when you get a chance and suggest how the structure of the objective function and generation of data for testing could be improved for seamless integration with pyPESTO, that would be great. Perhaps it would be necessary to modify argument types, for example.
I say this just because what is currently implemented was just intended to illustrate the basic machinery rather than having any particular parameter inference problem in mind!
In principle yes, but before testing I would suggest improving the nature of the problem slightly to ensure our bases are covered. Do you have an ideal situation (i.e. number of observables, number parameters, simulation run time, and form of objective function) for inital testing purposes? You suggested starting with a smaller toy model, but the current model completes simulations in 1-2sec (on the quick side for DFBA) and has enough parameters and variables to make a good case study. There is perhaps some room to improve further, even for preliminary tests, without much additional work.