Data2Dynamics / d2d

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

Reaction formulation Becker #135

Closed JanHasenauer closed 5 years ago

JanHasenauer commented 5 years ago

I just saw that in the Becker model the reaction

Epo_EpoR_i -> EpoR Epo CUSTOM "kex * Epo_EpoR_i"

is defined. I'm confused by the definition of the reactant. What does this mean? Is it a "EpoR + Epo"?

mschilling10 commented 5 years ago

Hi Jan,

it should be “Epo_EpoR_i -> EpoR + Epo" CUSTOM "kex * Epo_EpoR_i"

Best,

Marcel


Dr. Marcel Schilling
Project Leader and Deputy Head of Division
Division Systems Biology of Signal Transduction German Cancer Research Center (DKFZ)
Im Neuenheimer Feld 280 D-69120 Heidelberg
Germany Tel: +49 6221 424485
Fax: +49 6221 424488
m.schilling@dkfz.de


Von: Jan Hasenauer [mailto:notifications@github.com] Gesendet: Mittwoch, 5. Dezember 2018 10:58 An: Data2Dynamics/d2d Cc: Subscribed Betreff: [Data2Dynamics/d2d] Reaction formulation Becker (#135)

I just saw that in the Becker model the reaction Epo_EpoR_i -> EpoR Epo CUSTOM "kex * Epo_EpoR_i" is defined. I'm confused by the definition of the reactant. What does this mean? Is it a "EpoR + Epo"? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

JanHasenauer commented 5 years ago

Thanks for this very fast response. I guess it would be good to fix this.

Short follow up:

Becker includes a model for the dynamics and one for the Epo-EpoR binding. In the former, a replacement is used (kon "kon / init_Epo"). Yet, in the latter this is not used. According to the model for the Epo-EpoR binding, kon and koff are the standard one and off rates. On first glance it appears inconsistent to overwrite it in one model but not in the other. What is the logic behind this?

clemenskreutz commented 5 years ago

It seems that luckily the following two definitions Epo_EpoR_i -> EpoR Epo CUSTOM "kex Epo_EpoR_i" [wrong] Epo_EpoR_i -> EpoR + Epo CUSTOM "kex Epo_EpoR_i" [right] are parsed in a way that lead to exactly the same ODEs.

I can push the correct version.