[BUG]: AMR ingest error caused by SKEMA bug

[liunelson]

We have this source model from a paper:

It has several natural birth and death processes. The SKEMA model-from-equations tool only partially supports such processes and produces this AMR JSON:
pretty.json

Note that the natural birth process was ignored by SKEMA and the death processes are represented for example as:

            {
                "id": "s0",
                "input": [
                    "S",
                    "S"
                ],
                "output": null,
                "name": null,
                "description": "Transition representing the natural death of susceptible individuals.",
                "expression": null,
                "grounding": {
                    "identifiers": {
                        "ncit": "C28554"
                    },
                    "context": {},
                    "modifiers": {}
                },
                "properties": null
            },

MIRA's sources.amr.petrinet throws an error from this AMR JSON because "output" should be [] and not null. Replacing all the "output": null with "output": [] allows MIRA to produce a valid template model.

The AMR schema does specify that output needs to be an array of strings.

Should MIRA cover for this bug in SKEMA?

[bgyori]

Yes, we can handle the invalid value here. @nanglo123 could you check?

[liunelson]

A secondary issue (SKEMA bug?) is that MIRA interprets this AMR and duplicates this transition into 2 NaturalDegradation templates. Probably done by iterating over input: [S, S]. Is this logic intended?

[bgyori]

The structure

                "input": [
                    "S",
                    "S"
                ],
                "output": null,

is not exactly what we would consider a Natural Degradation of S, which would be

                "input": [
                    "S",
                ],
                "output": null,

which is probably the reason for the unexpected result.

[liunelson]

Totally. SKEMA seems to create these ["S", "S"] type of structure (and other unexpected behaviour) when it receives LaTeX equations with no matching terms (representing production/degradation processes).

Currently, MIRA does accept the above structure when I correct the output to []. It just creates two natural degradation templates from it. This creates a minor bug in Terarium where the model page shows Transition (2) (because it counts the transitions in the model AMR) but has an empty table (because it converts the AMR to a MIRA template model and counts the templates (?)).

[liunelson]

If I type in the following set of equations:

\frac{d S}{d t} = -\gamma S - \mu R
\frac{d R}{d t} = \gamma S

SKEMA returns this AMR:
Test 2.json

    "transitions": [
      {
        "id": "s0",
        "input": [
          "S",
          "R"
        ]
      },
      {
        "id": "t0",
        "input": [
          "S"
        ],
        "output": [
          "R"
        ]
      }
    ]

When I have MIRA ingest this model, that one -\mu R term is turned into two natural degradation templates. MIRA then produces this AMR that is quite different from the original, questionable AMR:
Test 2 - mira.json

    "transitions": [
      {
        "id": "s0",
        "input": [
          "S"
        ],
        "output": [],
        "properties": {
          "name": "s0"
        }
      },
      {
        "id": "s0",
        "input": [
          "R"
        ],
        "output": [],
        "properties": {
          "name": "s0"
        }
      },
      {
        "id": "t0",
        "input": [
          "S"
        ],
        "output": [
          "R"
        ],
        "properties": {
          "name": "t0"
        }
      }
    ]

These weird edge cases (all involving AMR files that are inconsistent with the AMR schema) are all due to bugs in SKEMA, giving us all the more reason to replace it sooner, rather than later with the eventual LaTeX-SymPy-MMT-AMR pipeline.

I think covering the initial issue of "output": null vs. "output": [] should be sufficient for now since it at least allows the Create Model from Equations operator to function without error.