Incorrect units in simple reaction in SimBiology?

I wonder why SimBiology does not detect any issues in the following model.

A cell, Cell, is producing signaling molecule, Sig, with following reaction:

Reaction 1: Cell -> Cell + Sig: kprod * Cell

Reaction 2: Sig -> null: kel*Sig

Units are as follows

Cell [molecule]

Sig [mole / milliliter]

kprod [gram / (molecule * day)]

kel [1/day]

The ODE seems to be correct: d(Sig)/dt = 1/Comp1*((kprod*Cell) - ((kel*Sig)*Comp1)) BUT there should be an error as the units don't match. Any comments would be very appreciated!

See below the screenshort of the model and settings plus sbproj.

EDIT: adding molecular mass into the production rate: kprod / MM * Cell solves the unit Issue of course, but I would expect that such inconsistency would be detected by the software. PS: MM [g/mol]

Answer 1

[Arthur Goldsipe]

This is a bug in SimBiology. SimBiology checks that all species participating in a reaction have dimensionally consistent units. For example, you would see an error if one species had units of gram while another had units of molecule. But SimBiology does not currently check that the reaction rate's units are dimensionally consistent with these species units.

I'll create a bug report so that we can fix this in a future release. Thanks again for bringing this to our attention.

[emjey]

Apart from the reaction rate's units issue, I have also noticed that the check SimBiology does, described in the first two sentences:

‘SimBiology checks that all species participating in a reaction have dimensionally consistent units. For example, you would see an error if one species had units of gram while another had units of molecule’

creates another issue. It prevents one from implementing reactions in which a cell with unit [molecule] produces something with mass unit [gram] – one of the key reactions if you model hormones/cytokines/else secretion.

Instead one has to define first a reaction with units [molecule] -> [molecule or mole] and convert it to [gram] in additional repeated assignment. This adds unnecessary complexity creating space for additional mistakes.

[Arthur Goldsipe]

Thanks for sharing. I think I'd heard about a similar pain from one other user several years ago. Given that low frequency, we haven't prioritized making this workflow easier. But I'll make sure to note your feedback in our enhancement database so that we can reevaluate the priority of fixing this.