search

Data2Dynamics / d2d

a modeling environment tailored to parameter estimation in dynamical systems
https://github.com/Data2Dynamics/d2d
57 stars 28 forks source link

Problems in the case of multilevel assignments of model parameters #53

Closed leshaker closed 8 years ago

leshaker commented 9 years ago

Originally reported by: Anonymous

Dear 2D2 crew,

Thank you for very quick resolving the issue reported last week [https://bitbucket.org/d2d-development/d2d-software/issues/52/model-substitution-failure-error-during](Link URL). This works fine now, but I encounter further problems in defining relations o model parameters. Consider the following simple model for Michaelis–Menten kinetics:

#!matlab

STATES
  x1          C "uM" "conc." default   1 "x1"  1
  x2          C "uM" "conc." default   1 "x2"  1

REACTIONS
  x1  ->  x2     CUSTOM   "R * x1/(K + x1)"     "r1"

Given a parametrisation of R, K and the initial states init_x1, init_x2, it is sometimes convenient to split the parametrisation formulas into multilevel assignments, e.g. it can be more readable to write them like this

#!matlab

CONDITIONS

  init_x2  "xtot - int_x1"
  init_x1  "c1*c2"

  c1       "k11/k12"

  R        "cR1*cR2*K"
  K        "cR1 - cR3"

than like this

#!matlab

CONDITIONS

  init_x2  "xtot - c2*k11/k12"
  init_x1  "c2*k11/k12"

  R        "cR1*cR2*(cR1 - cR3)"
  K        "cR1 - cR3"

Unfortunately, the assignments in the former variant are not resolved equivalently to the latter variant. In the latter case, init_x1 is eliminated from the model after compilation, as expected. After compilation of the former, init_x1 is listed as a free variable, since it was declared in a formula in CONDITIONS section. Changing the order of definitions in CONDITIONS does not affect this behaviour. I attach testmodel_2.def file with the model definition and the former assignment style, resulting in behaviour as described.

A sort of workaround it to use INPUTS section. E.g. define f1 = cR1 - cR3 as an input and later use it n CONDITIONS, see testmodel_3.def. However:

  1. This method enforces use of INPUTS for parameters which conceptually are not inputs (as therapy scenarios), but just convenience formulas reducing the size of other large formulas.
  2. This method does not work for initial vale assignments. Defining an input function and using it later in CONDITIONS section for substitution in initial conditions results in an compilation error, see testmoel_4.def.

For complex models, it would be inconvenient to manually substitute mathematically concise formulas, making them longer and less readable. Thus, some mechanism for handling multilevel assignments would be nice. I don't know if the above described behaviour concerning multilevel formulas is a bug or is correct, thus hereby I make a functionality request: to allow multilevel assignments in CONDITIONS section. What do you think about it.

Concerning error when using inputs for parametrisation of the initial conditions, I suspect it is a bug thus I mark this issue so. If this is not the case, please re-qualify my post.

Best regards,

Grzegorz

leshaker commented 9 years ago

Original comment by Joep Vanlier (Bitbucket: JoepVanlier, GitHub: JoepVanlier):

Hey Grzegorz,

I added this in commit 39cd7ac and 78c6923 . After discussing it with my colleagues here, we came to the conclusion that it would be better/safer to specify it in a separate field, since substitutions behave differently than the classical conditions and this could lead to unnecessary confusion.

You can now specify an optional field before CONDITIONS, named SUBSTITUTIONS. These will be substituted on model and data conditions at load time.

Note that this means that any data substitution will happen after the model substitution (unlike the CONDITION transforms where a new condition overrides the old one). Substituted expressions can be used within other substituted expressions as long as the referencing isn't cyclic. It will substitute up to 15 times, before it returns an error and aborts loading.

I did test it, but please consider the feature beta for now and carefully interpret simulation results. Let me know if there are any issues.

Closing this topic, since we do not consider the input issue to be a bug. States and inputs are not accessible in the conditions in the way proposed.

I hope this helps.

Kind regards, Joep.

leshaker commented 9 years ago

Original comment by Grzegorz Dudziuk (Bitbucket: gdudziuk, GitHub: Unknown):

Right, there is a typo. Both in my post and in the attachments it should be init_x1 instead of int_x1. Since I have posted as anonymous, I cannot edit that. Luckily, it doesn't affect the essence of my post.

Additional substitutions for parameters that are not in the model indeed would be an enhancement. If I understand what you propose well, it would in fact allow what I have suggested by creating some additional abstract variables. To be more precise, it would be always possible possible to 1) define a formula for an abstract parameter and then 2) assign that abstract parameter to a model parameter. In my example it would look like:

#!matlab

CONDITIONS

% Section with formulas for abstract parameters

  a_init_x2  "xtot - a_init_x1"
  a_init_x1  "c1*c2"
  c1         "k11/k12"

  a_R        "cR1*cR2*a_K"
  a_K        "cR1 - cR3"

% Section with abstract-to-model parameters assignment

  init_x1   "a_init_x1"
  init_x2   "a_init_x2"

  R         "a_R"
  K         "a_K"

If that was possible, I would find it useful. My original problem was with moving SBML models to D2D. The arImportSBML function has not done the job properly, perhaps due to problems with repeated substitutions in the SBML file in the Initial Assignments section. Thus, I was trying to move it manually (first convert SBML formulae to some human-readable text and then manually paste the obtained text of formulas into a .def file). But, since repeated substitutions occurred to be not possible, the only solution seemed to be to manually execute the substitutions and then move it to D2D. I wanted to avoid it for the sake of convenient control of the structure of the formulas. With what you propose, the original structure of formulas would be preserved, at acceptable cost of creating some additional abstract variables.

Best regards, Grzegorz

leshaker commented 9 years ago

Original comment by Joep Vanlier (Bitbucket: JoepVanlier, GitHub: JoepVanlier):

Okay, I've had a look at it. Regarding issue 2, inputs were never meant to be used in conditions since their value is time dependent and condition variables are specified before simulation.

The issue with repeated substitution is that I cannot implement this feature without breaking existing models. The reason for this is as follows:

Often, to decouple dynamics from scale, we tend to divide or multiply kinetic parameters by their initial conditions or scaling parameters (e.g. rna_pro = rna_pro / rna_scale). Implementing something which does repeated substitutions would break many existing models. The variables as specified in the conditions are only a single pass. One parameter transformation.

What I can do however, is implement additional substitutions for parameters that are not in the model. For your problem, it would look something like this then:

#!matlab

  init_x2  "xtot - c2*k11/k12"
  init_x1  "c2*k11/k12"

  R        "cR1*cR2*D"
  D        "cR1 - cR3"
  K        "D"

Again, they would be treated as substitutions, not solving a system of equations, and anything cyclic would throw an error. Do you think it would be beneficial to you if I implemented such a feature?

Best, Joep.

leshaker commented 9 years ago

Original comment by Joep Vanlier (Bitbucket: JoepVanlier, GitHub: JoepVanlier):

Hey Grzegorz,

I can see if I have some time to add this this week. Repeated substitutions in the conditions should not be too difficult I think. And yes, I think this would be a useful feature.

I assume that there is a typo in the first one (init_x2 "xtot - int_x1")? Shouldn't that be init_x1?

Best, Joep.