Model Composition/Optimization/Fitting Demo Script

[m10f]

• [x] Load epidemic model:

seirdh = loadESL("seird.esl")

• [x] Make simple SIR model as reaction net:

sir =
  reaction begin
    state S
    state I = 3
    state R = 0

    param beta = 0.4
    param gamma = 0.1

    beta, S + I --> 2I
    gamma, I --> R
  end

• [x] Compose models, sharing state "S"

double_epidemic = join(["ep1_", seirdh],
                       ["ep2_", sir],
                       [["S", "S"]])

• [ ] Display composed model

displayModelGraph(double_epidemic)

• [x] Optimize model for inspection of ep2_I

double_epidemic_simpl = simplifyStates(double_epidemic, ["ep2_I"])

• [ ] Display optimized model

  displayModelGraph(double_epidemic_simpl)

• [ ] Try to fit model to data

observed_data = loadCSV("fit_data.csv")
fit_result = fitParams(double_epidemic_simpl.ep2_I, observed_data.I, observed_data.time, ["ep2_beta"])

• [x] Reparameterize model

double_epidemic_simpl_fit = withParams(double_epidemic_simpl, fit_result.values)

• [x] plot model means and fit model on the same axis

de_sim = simulate(double_epidemic_simpl at observed_data.time)
de_fit_sim = simulate(double_epidemic_simpl_fit at observed_data.time)

plot(["data", "before_fit", "after_fit"], [observed_data.I, de_sim.I, de_fit_sim.I], observed_data.time)

[samcowger]

double_epidemic = join(["ep1_", seirdh], ["ep2_", sir], [["S", "S"]]) displayModelGraph(double_epidemic)

Are "ep1_" and "ep2_" meant to act as differentiating prefixes for variables duplicated between these models?

[m10f]

double_epidemic = join(["ep1_", seirdh], ["ep2_", sir], [["S", "S"]]) displayModelGraph(double_epidemic)

Are "ep1_" and "ep2_" meant to act as differentiating prefixes for variables duplicated between these models?

Yes, that's the idea anyway.

[samcowger]

double_epidemic = join(["ep1_", seirdh], ["ep2_", sir], [["S", "S"]]) displayModelGraph(double_epidemic)

Are "ep1_" and "ep2_" meant to act as differentiating prefixes for variables duplicated between these models?

Yes, that's the idea anyway.

Makes sense, and seems desirable. Other than that prefixing (and the synthesis of a model's graphical representation), the functionality we want here is implemented in feature/model-composition.

[samcowger]

Optimize model for inspection of ep2_I

Model state space simplification/pruning is now realized in https://github.com/GaloisInc/ASKE-E/commit/5510556c9f91a84330f5e0aff7d1fed18ac5fb57 and https://github.com/GaloisInc/ASKE-E/commit/baedc47c9a64e45904c5684a451db45c25630418.

[samcowger]

double_epidemic = join(["ep1_", seirdh], ["ep2_", sir], [["S", "S"]]) displayModelGraph(double_epidemic)

Are "ep1_" and "ep2_" meant to act as differentiating prefixes for variables duplicated between these models?

Yes, that's the idea anyway.

This behavior (but with suffixes, which seemed more readable) has been realized in #82. Can we split displayModelGraph into a separate checkbox? Without it, and on merge of the aforementioned, I'd be prepared to check the third and fourth boxes.

[m10f]

double_epidemic = join(["ep1_", seirdh], ["ep2_", sir], [["S", "S"]]) displayModelGraph(double_epidemic)

Are "ep1_" and "ep2_" meant to act as differentiating prefixes for variables duplicated between these models?

Yes, that's the idea anyway.

This behavior (but with suffixes, which seemed more readable) has been realized in #82. Can we split displayModelGraph into a separate checkbox? Without it, and on merge of the aforementioned, I'd be prepared to check the third and fourth boxes.

Sure, I have done so

[ewdavis]

This all looks amazing and very responsive.

How generalizable is the current compose framework?

[samcowger]

How generalizable is the current compose framework?

I'm not sure if this answers your question, but the composition primitives we now have were created in #82 - in addition to join we have compose (serial model composition) and ensemble (a flavor of parallel model composition/combination), but both rely on join under the hood.

[ewdavis]

I'm not sure if this answers your question, but the composition primitives we now have were created in #82 - in addition to join we have compose (serial model composition) and ensemble (a flavor of parallel model composition/combination), but both rely on join under the hood.

That actually answers it really well. I notice above we're using the join, will we be ready to show Joshua serial and ensemble composition as well if we had some examples?

Side note: really loving this functionality.

[samcowger]

I'm not sure if this answers your question, but the composition primitives we now have were created in #82 - in addition to join we have compose (serial model composition) and ensemble (a flavor of parallel model composition/combination), but both rely on join under the hood.

That actually answers it really well. I notice above we're using the join, will we be ready to show Joshua serial and ensemble composition as well if we had some examples?

Side note: really loving this functionality.

Yes, depending on the examples - I've verified them on some of our SIR-like models, which should be enough to demonstrate the capabilities/ideas at play, but they should be widely applicable as well.