Model Nesting

This forum is for discussion of the System Dynamics model representation standard XMILE. Discussion here will be monitored by the Society's technical standards committee with ideas and concerns conveyed to the OASIS Technical Committee responsible for defining the standard.
Forum rules
Please note: By posting here you grant permission to the Society Technical Committee members to repost with attribution on the OASIS discussion forum. If you have material for which you wish to maintain copyright control please post a link to the copyrighted work.
Post Reply
Robert Eberlein
Site Admin
Posts: 179
Joined: Sat Dec 27, 2008 8:09 pm

Model Nesting

Post by Robert Eberlein » Mon Aug 05, 2013 6:21 pm

It seems that it would be valuable to specify two ways that a nested model behaves - call them transparent and opaque.

A transparent model nested inside of another model would behave at the same level computationally. That is, when ordering equations to determine dependency the equations of the nested model would be treated the same as equations of the nesting model. During computation the equations of the nesting and nested models would thus be interleaved in an arbitrary fashion. Any <sim_specs> in a transparent nested model would be ignored, and only used when that model was extracted to be run in isolation.

An opaque nested model would behave as a coherent computational unit. Thus, if the nesting model had an equation

a=nmod1.out

Then the computation of a would require that the entire set of equations for nmod1 be computed. The nested model nmod1 would be computed in its entirety after its inputs had been computed (and before a was). The internal structure of nmod1 is thus opaque to the nesting model beyond the determination of its input requirements. There is a subtlety here because of the potential to identify spurious simultaneous equations (or fail to identify real ones). If, for example the input to the nested model nmod1 is the variable a then, even if there is an intervening level internal to nmod1, a simultaneous equation will be identified. To get around that each output of a model that might be nested should be identified as connected to the inputs simultaneously or through a level. This identification need not be accurate, in which case some ambiguity of the resulting simulation may result.

The sim_specs for opaque nested models might be used so specifying how much of them to use (none, dt only, all) would be helpful. In the case of all having a specification of whether to reinitialize the nested model would also be helpful.

See also the discussion of namespaces.

Karim Chichakly
Posts: 46
Joined: Fri Apr 10, 2009 11:52 am

Re: Model Nesting

Post by Karim Chichakly » Mon Aug 05, 2013 7:56 pm

These are both supported in the draft XMILE spec, as well as a third intermediate type: one that has a smaller DT so runs many times for each DT at the higher level (but has the same start and end). The first type you mention and the third type are treated directly as nested models while the second type you mention is in only available in a macro. There has been a suggestion we unify these related methods as nested models.

Thomas Fiddaman
Posts: 152
Joined: Thu Jan 15, 2009 6:55 pm
Location: Bozeman, MT
Contact:

Re: Model Nesting

Post by Thomas Fiddaman » Tue Aug 13, 2013 1:52 pm

I think there are at least two more cases:

- A nested model that has its own time dimension, as in the case of an optimization subproblem embedded in a larger model, which executes at every dt (or perhaps some other interval) of the host. In this case, the <sim specs> would be needed. Normally the causality from the submodel's inputs to outputs would be regarded as instantaneous (no persistent states between runs), so this would execute at a particular point in the equation order of the host.

- A model, or multiple models, that are iterated to equilibrium within some host. This is actually pretty bad from a behavioral perspective, but nevertheless often done, as in DOE's NEMS model.

One could solve the opaque equation ordering problem by specifying an (inputs x outputs) matrix that indicates whether the model has internal states between input and output[j].

I'm actually not advocating any extension to accommodate these as I prefer minimalism, but thought I'd mention the possibilities.

Magne Myrtveit
Posts: 57
Joined: Mon Jan 12, 2009 6:52 am

Re: Model Nesting

Post by Magne Myrtveit » Fri Aug 16, 2013 8:21 am

Thanks for a nice overview of the nature of, and the use of, nested models.

To keep concepts clean, it can be useful to distinguish between model hierarchy as one abstraction mechanism, and various kinds of interacting model components as another. The latter will typically also make use of hierarchical arrangements of objects, but it will in addition provide functionality of the nature(s) you describe: Interfaces for communication between components, and specifications for individual simulation settings.

The concept of hierarchy can be used for any object type. As an example, Smia variables can be arranged in an hierarchy, where some variables can have other variables as children, nested to any depth. Also list types can he hierarchical.

When a new parent node in the hierarchy is wanted, and the parent has no equation (no value), a variable object is maybe not the right thing to use. Inspired by Forrester's concepts of model and submodel, representing the real-world system and subsystem, we should introduce an object type (named submodel) that has as its sole purpose to create hierarchy. This object has no interface and no separate simulation (sim specs). It is just like a void-type variable, but without equation and value.

Submodels without simspec, but with interfaces for inputs and output, and maybe also support for replication (instances, clones, ...), can be labelled components. The name reflects that they are building-blocks of models, and not just abstractions for hiding details inside larger structures.

If a part of a model has its own simulation process, separate from the main model, consider the term comodel. It is inspired by co-routines in Algol (or was it Modula?), which are functions running within their own execution contexts. Mechanisms for synchronization and communication can be defined along the lines indicated in previous posts in this thread.

In sum, the terminology I propose is the following:
  • hierarchy - Any object can have children, or be a parent in an object hierarchy. In particular, variables can be arranged hierarchically. Path notation is used to refer up, down, and across the hierarchy.
    submodel - An object without semantics (no equation and no value), used only to build hierarchy in a model. All submodels can be deleted from a model, and the model will still do the same thing.
    component - Similar to a submodel, but with mechanisms for defining the interface between the inside and the outside of the object, i.e. public and private variables, inputs and outputs, etc. Runs inside the same simulation process as the main model. May or may not have mechanisms for replication or instantiation.
    comodel - A model running with its own simulation process, synchronized with the main model according to different settings, and exchanging information via defined input and output variables.
Only comodels need a special protocol and syntax for exchanging information with the main model or other comodels. All the other object types listed above run inside the main model's simulation process, and equations are evaluated according to a global sorting of all variables/variable elements (excluding varables inside comodels). Path notation can be used to refer from any object to any other object in the hierarchy. For comodels, only defined inputs and outputs can be accessed from the outside.

In my view, hierarchy of variables and submodels should be part of a level of the standard that comes before components and comodels. The reasons are that variable and submodel hierarchies are useful abstraction mechanisms, easy to understand (conceptually), easy to define (semantically), and intuitive (close to real-world systems and subsystem). The same is not true for components and comodels, both being rather complex programming concepts, with a host of different implementations.

Best regards,
Magne

PS: It would be great if someone could enlighten me on the meaning of, and the difference between, macro and submodel as used in the SMILE draft.

Robert Eberlein
Site Admin
Posts: 179
Joined: Sat Dec 27, 2008 8:09 pm

Re: Model Nesting

Post by Robert Eberlein » Sun Aug 18, 2013 5:52 am

Hi Magne,

You have introduced different terminology which may be clearer than that in the SMILE draft which I suggested some refinement of. They are not obviously more intuitive or related the observable systems to me - hierarchy in everyday use refers to both components and comodels in your terminology which is why capturing them all under the name model (suggesting there are get broader boundary models containing any model we work with) is as intuitive to me. I would be curious to hear the thoughts of others.

Macros and Submodels (or just Models as I like to call them) have a lot in common but Macros are not expected to have a visual representation and are proposed to be Turing complete (or at least almost so) whereas Models follow the protocols of cause/effect rate/level modeling in which equation order is not important.

Magne Myrtveit
Posts: 57
Joined: Mon Jan 12, 2009 6:52 am

Re: Model Nesting

Post by Magne Myrtveit » Sun Aug 18, 2013 8:57 am

Hi Bob,

A model consists of objects.

Support for hierarchy is a property an object may or may not have. So you are right, it refers both to components and comodels, as well as variables and submodels.

In order to pick good naming (terminology), we first need to identify the objects that need a name. In my previous posting, I propose three new object types: submodel, component, and comodel, with a brief description/purpose of each, and a name.
  • The question is: are these the right object types to add to "basic SD"?
Before we can answer that, we need to look at the alternatives.

If I understand you correctly, you propose that "model" is used for everything relating to model nesting, making "model" a super-flexible object type that can play all the roles of submodels, components, and comodels, depending on configuration.

Best regards,
Magne

Robert Eberlein
Site Admin
Posts: 179
Joined: Sat Dec 27, 2008 8:09 pm

Re: Model Nesting

Post by Robert Eberlein » Tue Aug 20, 2013 7:28 am

Hi Magne,

You are definitely right that terminology is an issue. Generally I think of objects as things with more than one attribute. A variable, since it has only a value, does not really bring to mind an object to me. So my mental model (indeed using the word again) would look something like this

Reality
-----Model with really broad boundaries not explicit
----------Verbal arguments about my problem
----------Variable (say cash flow) and what drives it
-----SD Model for my problem (the enclosing model)
----------Variable cash flow computed from sales, price and expenses
----------Model of market generating sales and using price
-----------------Variable customers
----------Model of finance producing price and using sales
---------------Variable pressure_from_margin

Suppose my SD model was a simple one - then the two nested models would be what I called transparent - everything would behave as it would in a single model except there might be different naming conventions, or a different namespace, or perhaps just a different color for displayed variables.

The purpose of nesting models in this case is just to organize thinking, not to have an impact on computation. This is essentially the way Vensim works, with Views and Groups as such organizing mechanisms. Stella/iThink introduce a little more formality with what are there called modules. But in all cases we can think of a model as taking some assumptions (inputs), doing some computation, and generating some values that might be used elsewhere (outputs). With a bit of extra work and some assumptions (eg standins for inputs are constants) we can extract and simulate models at any level of nesting as long as we still get to keep any models they may have nested in them.

So yes, I am thinking of everything as a model with variables where sometimes those variables take us to another model. That model might be computationally transparent requiring that every equation be evaluated at the same time as the equations in the nesting model. Or it might be computationally opaque, meaning that it is evaluated as an entirety by the nesting model. In this case it might also have different rules for value by time (a shorter dt, a full simulation over a different time range, an optimization and running to steady state are the obvious categories).

I would actually be quite satisfied with just what I call the transparent case, where the only real effect is to break up the naming conventions (introducing variable name paths as you have said) but I don't think that captures the way PowerSim deals with partitioned models.

Karim Chichakly
Posts: 46
Joined: Fri Apr 10, 2009 11:52 am

Re: Model Nesting

Post by Karim Chichakly » Tue Aug 20, 2013 4:47 pm

To clarify, SMILE/XMILE accounts for all of the following types of "submodels":

1. Substructure of a larger model that exists primarily for organizational reasons (but see my caveat at the end) - it reduces the complexity of the model, it allows independent development and testing, etc. - i.e., the process of "model decomposition" led to this submodel. It has clear inputs and outputs that can be connected to other parts of the model (and it can be nested). This is called a "submodel" in the spec. This is what Bob called transparent.

2. Substructure of a larger model that is organizational certainly, but exists due to operating at a different time scale (the enclosing model's time step must be an integral multiple of this submodel's time step). This is also called a "submodel" in the spec, but it has sim specs with a different DT. SMILE names this the "normal" mode of a submodel.

3. An independent computational unit that runs from start to end every DT. This is also called a "submodel" in the spec, but it has a full set of sim specs that define how many iterations to run it using what DT. Tom's example of models iterated to equilibrium (or through some arbitrary criteria) can be done with these as long as we allow the end time to be variable (while SMILE does allow this for both submodels and macros, it has to be a parameter value, so is not based on the submodel variables). We could also use an event poster to do this, as Bob pointed out in one of his posts. SMILE names this the "independent" mode of a submodel. This is what Bob called opaque.

4. A computational unit that can be used as a builtin function in an equation and which may or may not be independent (depending on whether it has sim specs, just as in #1-3). This is called a "macro" in the spec. What do macros include that submodels don't? Macros support recursion through their output equation. Macros can influence building block behavior (see #5 below). Macros have their own scope independent of the model (in particular, nested submodel names will not conflict with those in the model). Macros specify the order of parameters in the call (i.e., how each parameter maps to the macro's or submodel's input), default parameter values, and the <i>single</i> output value, which is an <i>equation</i>, not a model variable. The purpose of macros is to allow vendors to provide implementations for their unique builtin functions and to allow users to build their own libraries of builtin functions - basically, to allow users to extend the language. Bob has pointed out that this is a computational model and is not likely to have a visual representation.

5. An independent piece of code that runs whenever a building block is evaluated, the so-called macro filters (but still a macro in every way). These allow the building block behavior to be extended by vendors or users.

I am pretty sure I have hit all the cases described in the spec. Agreeing on some terminology for the different types will help (SMILE calls #1 "submodel", #2 "submodel normal mode", #3 "submodel independent mode", #4 "macro", and #5 "macro filter"), but we should be careful. For example, you can build functional submodels that can be re-used over and over again by just using the features of type 1. I specifically used the phrase "model decomposition" in that description to bring to mind software's "functional decomposition." When we decompose the problem, we can get both separate pieces of a larger model <i>and</i> functionally re-usable components - without having to use macros. It is the same underlying mechanism in both cases (submodels), but a different (sub)model design by the user.

Magne Myrtveit
Posts: 57
Joined: Mon Jan 12, 2009 6:52 am

Re: Model Nesting

Post by Magne Myrtveit » Wed Aug 21, 2013 6:22 am

Hi Karim,

Thanks for your detailed explanation.

Is it correct to say that your submodel concept is quite similar to a full model, only that it can be placed inside other models? Are submodels typically stored in separate files, or are they defined inside a (main) model. How are new instances of submodels created.

Can you explain more about how information is transferred into and out of submodels? (You mention parameters, inputs and outputs. How are they defined and used. Can a variable A inside a submodel M refer directly to a variable X outside M, and vice versa?).

It seems that a light-weight building block just for creating hierarchy is missing, and that variables cannot be nested. Is this right?

Best regards,
Magne

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests