Conditions and functions¶
Initial conditions¶
Every state that has a differential equation needs a value at the start of the
simulation. A new Model Realization gives every state an initial condition of
1.0; replacing those placeholders with real numbers is usually the second
thing you do after setting rate laws.
Set them either
- in the Action Items panel, by typing into the Formula column of the Initial Condition rows; or
- in a state's Properties dialog, opened from a diagram that is inside the realization.
Initial conditions belong to the realization, not to the state, so two realizations of the same model can start from different places — which is exactly how you model a wild-type and a knockout from one diagram.
Boundary states¶
A boundary state is one whose value is imposed rather than computed: a buffered pH, a substrate held constant by a large external pool, a concentration you clamped experimentally. It gets no differential equation.
ProcessDB makes this choice for you in one case: a state that only ever plays a modifier role — an enzyme, an activator, an inhibitor that is never produced or consumed by any process in the model — starts as a boundary state, because the model contains nothing that would change it.
To make any other state a boundary state, tick On boundary in its Properties dialog inside the realization. Its Action Items row changes from Initial Condition to Boundary Formula, and the Boundary formula (RHS) field takes a formula for its value at any time:
- a constant —
2.5— for something simply held fixed; - an expression in time or in other states, if the imposed value varies.
The formula is the right-hand side; you are saying "this state equals this", not writing a rate of change.
Boundary state or protocol?
Use a boundary state when the value is a property of the model — a pool you have decided to treat as infinite in every experiment. Use a protocol when the value is a property of a particular experiment — what you clamped it to on the day. Protocols override per experiment; boundary states apply throughout.
MR functions¶
An MR function is a named algebraic definition attached to the realization: a name and a formula. It is written into the equations of every Model of Experiment built on this realization.
Use them for quantities that are part of the model's description rather than of one simulation:
- derived readouts — a total that sums several states, a ratio, a flux combination you always want plotted;
- shared intermediate expressions that several rate laws refer to, so the definition lives in one place;
- unit conversions between what the model computes and what you measured.
MR functions are edited on the MR Functions tab of any MOE pane built on the realization, alongside that MOE's own functions. There is a search box — useful once the list grows — and edits are saved by the ordinary Commit.
The related, narrower object is the MOE function, which is attached to one MOE and one experiment. The rule of thumb: if the definition is about the biology, it is an MR function; if it is about how one experiment was read out, it is a MOE function.
Where the values end up¶
Initial conditions, boundary formulas, and MR functions are all written into
the equation listing of every MOE on the realization,
as INIT lines, boundary equations, and a Model realization functions block
respectively. Reading the listing is the most reliable way to confirm that
what you entered is what the simulator will use.