Model Structure Generation

Inductive Process Modeling (IPM) is based on the generation and evaluation of model structures (eg, sets of differential equations). During evaluation, unresolved parameters are fitted to observed data and an error score (eg, least squares) is calculated. This page examines assorted aspects of model structure generation, in the context of IPM Lab.


A model set specification (spec) defines the entities, processes, and constraints that pertain to an IPM Lab experiment. These items can be defined (informally) as:

  • entity - a collection of attributes
  • process - a collection of behaviors
  • constraint - limits on process usage

The generated model structures are unique combinations of processes (and related entities) that satisfy the applicable constraints.


As the number of processes (P) increases, the number of possible combinations (C) increases exponentially, eg:

 P   C = 2^P
 8                          256
16                       65,536
32                4,294,967,296
64   18,446,744,073,709,551,616


Using IPM's constraints (ie, Boolean predicates), we can limit the combinations of processes that may appear in a model structure. Here is the current list (others may be introduced, if needed):

  • Always-together - these processes always appear together
  • At-most-one - at most, one of these processes may appear
  • Exactly-one - exactly one of these processes must appear
  • Necessary - all of these processes must appear

  • Any-number - any number of these processes may appear
  • Forbidden - none of these processes may appear

The first four constraints are typically used to prevent IPM Lab from evaluating model structures that make no scientific sense. This reduces both the amount of time spent on evaluation and the generation of false positive results.

The remaining constraints are used for ancillary purposes. Any-number is a no-op, but it ensures that the processes are considered for inclusion in the generated model structures. Forbidden can be used to disable a process (eg, for testing).


Constraints can also be used (in a dynamic fashion) to control exploration of the model space. For example, we might start with a constraint that completely disallows multiple predation processes. After evaluating these models, we find that the Foo process gives the best results. We can then relax the constraint to allow (say) the Foo process plus one other predation process. This is the basis for the Extend Model capability.

More generally, iterative generation of model structures can take advantage of information harvested from successive model evaluation runs. The only requirement is that each generation of models "learn" from its predecessors.

Various techniques may be employed, eg:

Basic Example

Consider a simple predator-prey model, with 17 possible processes. A brute-force approach, generating all possible combinations, would produce 131,072 (2^17) model structures. However, a few constraints can trim this down dramatically.

For example, the following constraints eliminate all but 52 (2*2*13) of these combinations:

Any-number  [ growth_exponential(P), growth_logistic(P) ]
Exactly-one [ loss_exponential(P) ]
Exactly-one [ grazing(P, G) ]
Exactly-one [ crowley_martin(P, G),
              deangelis_beddington(P, G),
              generalized_gause(P, G),
              hassell_varley_1(P, G), hassell_varley_2(P,G),
              holling_2(P, G), holling_2_rd(P, G),
              holling_3(P, G), holling_3_rd(P, G),
              ivlev(P, G), lotka_volterra(P, G),
              monod(P, G), watts(P, G) ]


In this example, it would be fairly reasonable to perform an exhaustive search, generating and testing all of the (131K) possible combinations. However, if more processes were involved, this could become impractical. Fortunately, there is a simple alternative.

The combinations (ie, model structures) can be represented as a collection of 17-position bit fields (eg, a, b). If a bit is set (ie, 1), the corresponding process is included in the model structure. For example, the left-most model structure (a) includes the processes crowley_martin, grazing, and loss_exponential.

    a  b  c  d  e  f  g  h  ...  Process Name
 1  1  1  1  1  0  0  0  0  ...  crowley_martin
 2  0  0  0  0  1  1  1  1  ...  deangelis_beddington
 3  0  0  0  0  0  0  0  0  ...  generalized_gause
13  0  0  0  0  0  0  0  0  ...  watts
14  1  1  1  1  1  1  1  1  ...  grazing
15  1  1  1  1  1  1  1  1  ...  loss_exponential
16  0  0  1  1  0  0  1  1  ...  growth_exponential
17  0  1  0  1  0  1  0  1  ...  growth_logistic

We use the exactly-one constraints to create our starting point, shifting the 1 bit through all possible positions (13 positions for the predation constraints, one each for grazing and loss_exponential):

    a  e  ...               ...  Process Name
 1  1  0  0  0  0  0  0  0  ...  crowley_martin
 2  0  1  0  0  0  0  0  0  ...  deangelis_beddington
13  0  0  0  0  0  0  0  1  ...  watts
14  1  1  1  1  1  1  1  1  ...  grazing
15  1  1  1  1  1  1  1  1  ...  loss_exponential
16  0  0  0  0  0  0  0  0  ...  growth_exponential
17  0  0  0  0  0  0  0  0  ...  growth_logistic

Using each of these bit fields as a basis, we now create four (2^N) variants to handle the two remaining fields (growth_exponential, growth_logistic). Checking the resulting values against our constraints, we can determine whether the corresponding model structures are "legal".

It should be fairly trivial to extend this approach to handle the Extend Model capability described below. Basically, we would set bits for the already-accepted processes, then slide a bit to cover the extension.

If the legal models exceed a user-specified limit, we need to select a pseudo-random subset of them for generation. If need be, the selection can be biased in some manner (eg, to favor certain processes).

Desired Capabilities

SC-IPM (Structural Constraints for Inductive Process Modeling; IPM Lab's predecessor) offers a range of capabilities. Eventually, IPM Lab should support all of these:

Test Models

SC-IPM's Test Models tab is used to generate and evaluate sets of model structures, based on generic definitions of constraints, entities, and processes. A limit on the number of generated models allows the modeler to try out a pseudo-random subset of the possibilities. ...
-- Test Models

This is basically the set of capabilities described above.

Learn Constraints

SC-IPM's Learn Constraints tab allows the program to "learn" new constraints, based on model-characterization selections made by the user. The new constraints will ensure that Bad models are avoided and Good models are retained. Neutral models may or may not be retained. ...
-- Learn Constraints tab

This capability is supported in SC-IPM by some Python code. We'll need to integrate this code into a web application server, create an interactive front end, etc.

Simplify Model

Models are "simplified" by removing a process that was previously present. So, a simplified model is identical to its parent, save that it has one fewer process. ...
-- Simplify Model tab

This capability is supported in SC-IPM by some Lisp code. We'll need to replicate this code in a web application server, create an interactive front end, etc.

Extend Model

Models are "extended" by adding a process that was previously missing. So, an extended model is identical to its parent, save that it has one additional process. ...
-- Extend Model tab

This capability is supported in SC-IPM by some Lisp code. We'll need to replicate this code in a web application server, create an interactive front end, etc.

This wiki page is maintained by Rich Morin, an independent consultant specializing in software design, development, and documentation. Please feel free to email comments, inquiries, suggestions, etc!

Topic revision: r13 - 04 Apr 2016, RichMorin
This site is powered by Foswiki Copyright © by the contributing authors. All material on this wiki is the property of the contributing authors.
Foswiki version v2.1.6, Release Foswiki-2.1.6, Plugin API version 2.4
Ideas, requests, problems regarding CFCL Wiki? Send us email