MIRA Integration

[jpfairbanks]

I've implemented the schema to support integration with MIRA models as discussed at the TA2 WG call today.

https://github.com/AlgebraicJulia/ASKEM-demos/blob/master/Mira/mira.jl

Output:

{"V": [{"nameV": "v1"},{"nameV": "v2"},{"nameV": "v3"},{"nameV": "v4"}],
  "P": [{"subject_P": 1,
      "nameP": "p",
      "rateP": 1.0,
      "lawP": "const"}],
  "D": [{"outcome_D": 1,
      "nameD": "d",
      "rateD": 1.0,
      "lawD": "const"}],
  "NC": [
    {"subject_NC": 2,
      "outcome_NC": 3,
      "nameNC": "nc",
      "rateNC": 1.0,
      "lawNC": "linear"},
    {"subject_NC": 4,
      "outcome_NC": 1,
      "nameNC": "return",
      "rateNC": 2.0,
      "lawNC": "linear"}],
  "CC": [{"subject_CC": 2,
      "control_CC": 3,
      "outcome_CC": 1,
      "nameCC": "cc",
      "rateCC": 1.0,
      "lawCC": "MAK"}],
  "GCC": [{"subject_GCC": 2,
      "control₁_GCC": 3,
      "control₂_GCC": 4,
      "outcome_GCC": 1,
      "nameGCC": "gcc",
      "rateGCC": 1.0,
      "lawGCC": "generic"}]
}

The next step is to get models from the MIRA team and then do stratification on them.

[jpfairbanks]

@olynch, this is more evidence that we need some namespacing for homs and attrs.

[bgyori]

Thanks! I think

  "P": [{"subject_P": 1,
      "nameP": "p",
      "rateP": 1.0,
      "lawP": "const"}],
  "D": [{"outcome_D": 1,
      "nameD": "d",
      "rateD": 1.0,
      "lawD": "const"}],

should be

  "P": [{"outcome_P": 1,
      "nameP": "p",
      "rateP": 1.0,
      "lawP": "const"}],
  "D": [{"subject_D": 1,
      "nameD": "d",
      "rateD": 1.0,
      "lawD": "const"}],

to fit the roles we use in MIRA.

[jpfairbanks]

@kris-brown, we actually could generate this schema from just the arity signature.

@present SigMira(FreeSymmetricMonoidalCategory) begin
    X::Ob
    p::Hom(munit(), X)
    d::Hom(X, munit())
    nc::Hom(X, X)
    cc::Hom(X⊗X, X)
    gcc::Hom(X⊗X⊗X, X)
end

Did you do anything like that for the rewriting code? Automatically generating the hypsigma representations from the presentation syntax seems useful.

[kris-brown]

Not exactly, the input was a vector of DWD Box which has the data of a name + input/output types. But it's basically the same data.

https://github.com/AlgebraicJulia/GraphicalLinearAlgebra.jl/blob/hypsig/src/ChaseInterface.jl#L227

There's even code to go from Vector{Box} to Presentation (so that the @program macro can be used) https://github.com/AlgebraicJulia/GraphicalLinearAlgebra.jl/blob/hypsig/src/ChaseInterface.jl#L516

[jpfairbanks]

[jpfairbanks]

@bgyori Can you post the Mia model examples that we discussed on Friday in this thread? Thanks

[bgyori]

In our latest conversation we discussed focusing on one or more models where symptomatic/asymptomatic infected populations are differentiated. There are a few models in the BioModels set that have this property, let me post a couple of such models. They each have distinct challenges when it comes to how the model is defined, for instance the use of various non-standard rate laws, questionable choices in identifiers assigned to model components, etc.

Below is an example model represented as JSON in a zip file since Github doesn't allow JSON attachments.

BIOMD0000000971_petri.json.zip

For each transition in the export, in addition to the (automatically generated) tname attribute, we add the following additional attributes:

• template_type: the MIRA template type from which the transition was generated
• parameter_name: if the rate law is governed by a single parameter and corresponds to mass-action kinetics, this is the name of the corresponding parameter in the original model. If these conditions don't hold, this is a MIRA-generated parameter key instead.
• parameter_value: if the rate law is governed by a single parameter and corresponds to mass-action kinetics, this is the value of the corresponding parameter in the original model. If these conditions don't hold, the value is null. Note that in several cases, MIRA internally has a representation of non-standard rate laws, sometimes referring to multiple model parameters but encoding these appropriately in the Petri net export will require more planning.

We can change aspects of this export as needed, let me know if something isn't right.

Once we are all satisfied with how the Petri net JSON export looks, we can deploy an updated endpoint to the MIRA web service so that you can get to the same Petri net JSON using REST API calls.

[bgyori]

Here is another example model: BIOMD0000000958_petri.json.zip

[bgyori]

I also wanted to add some sample code for how you will be able to call the MIRA REST API. I am using Python here but hopefully it's straightforward to make a Julia version based on this:

import requests

# This call gets you a MIRA template model from a BioModels model ID
res = requests.get('http://34.230.33.149:8771/api/biomodels/BIOMD0000000971')

# This call gets you a Petri net JSON based on the MIRA template model returned in the previous call
# (you have to get the JSON content of res2).
res2 = requests.post('http://34.230.33.149:8771/api/to_petrinet', json=res.json())

Note: the JSON content returned from the public service when I am posting this doesn't yet include the 3 additional attributes I mentioned above. These will appear when we make a new deployment.