Back to basics?

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
Thomas Fiddaman
Posts: 152
Joined: Thu Jan 15, 2009 6:55 pm
Location: Bozeman, MT
Contact:

Back to basics?

Post by Thomas Fiddaman » Tue Aug 13, 2013 3:24 pm

Returning for a moment to Magne's comments from the original Open thread, viewtopic.php?f=4&t=323&start=20#p1822,
My original MIF proposal aimed at creating a format for interchanging models among software tools, without forcing vendors to change their concepts and feature set. In 1995 this was possible, but since then, significant advances have been made by different vendors, in different directions. The definition of a superset of the most popular SD languages today would become a monster full of partially overlapping and conflicting concepts; extremely expensive to develop and practically impossible to learn.

Therefore, my recommendation to the OASIS committee is the following:

Create a new language / representation for “basic SD” models. It includes only the concepts and features that are needed to teach SD and develop models of general interest. In particular, I suggest that the basic SD supports measurement units and logical values, but probably not arrays and definitely not macros. All vendors should have few problems reading and writing this mini-language.
The design of the “basic SD” language and its companion XML representation should be such that it can be extended to include any of the concepts and features that are part of current SD software, including some of the newcomers where most of the highly needed innovation is to be found.
Each vendor is urged to open up its document format, preferably in an XML based, vendor-specific extension to “basic SD”. This makes it possible for each vendor to implement import from other model formats with a minimal loss of information. I have used this approach by implementing MDL import in Dynaplan Smia. It took me one week to complete. It allows Smia users to import almost any Vensim model without loss of functionality. (As a test, I loaded and run all the models accompanying “Business Dynamics” without any problems). I believe that import of models following the current XMILE specification can be implemented in roughly the same amount of time.
No vendor should be burdened by having its own native standard as the official SD standard. Therefore, XMILE should be reserved either for isee or for the SD society, and the other part should find a new name for its specifications. (Suggestion: isee finds a vendor-specific name for their language and file format).

Instead of boring you more with my own reasoning, I’d like to challenge the advocates of the XMILE standard to make visible their mental models, and even create an SD model, that shows how they expect that XMILE will influence the field and its stakeholders, how the feature set of each vendor is accounted for, what the costs will be and how they can be justified, and what we can expect in return.
I could imagine two outcomes for the field. The dream is for interchange to attract new business, through safety in numbers, enhanced productivity, etc. The nightmare is for the standard to become captive to a vendor that uses it to bludgeon competitors (imagine gov't RFPs requiring compliance with a convoluted standard).

To avoid the nightmare variant, I like Magne's idea of a minimal standard that represents the intersection of functionality rather than the union. This will also be quicker to implement, and if the dream works, time to market is important.

Regardless of history, we're OK with the current SMILE/XMILE as a starting point, because it's easy to work with. But perhaps we should be looking at things to exclude from it, or make optional, as well as ways to extend it, and perhaps creating a straightforward way to include <vendor specific> blocks that define things we haven't contemplated.

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

Re: Back to basics?

Post by Robert Eberlein » Wed Aug 14, 2013 5:39 am

Hi Tom,

Both the language and encoding discussions identify a base standard (no subscripts, no macros, minimal functions...) with additions to this in a given model being called out.

Most of the models that show up in our literature and practice (the SD Review, Conference Proceedings and SD Publications elsewhere as well as unpublished models in use) go beyond these basic elements. My hope is that we could come up with something that would capture 80-90% of such models. Capture in the sense that: 1) an XMILE encoding with a conformant engine would simulate and give essentially the same results as the original models (there are variants in random numbers and potential implementation differences in some functions that might cause some difference); 2) The XMILE encoding when run through something such as SDM-Doc would give accurate and coherent documentation and 3) a model encoded into XMILE by software A could be reopened by software A without loss of fidelity.

Vendor specific tags and blocks, part of the draft standard, are the way to do the last of these, but it still may be tough to do it elegantly (and consequently it might not get broadly implemented). So, we do want to be on the look out for anything in the specifications that might make straightforward vendor specific information encoding difficult.

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

Re: Back to basics?

Post by Magne Myrtveit » Thu Aug 15, 2013 2:25 am

Hi Bob,

You write:
Robert Eberlein wrote:Most of the models that show up in our literature and practice (the SD Review, Conference Proceedings and SD Publications elsewhere as well as unpublished models in use) go beyond these basic elements.
In chapter 6, page 43ff, of http://www.myrtveit.com/papers/A_framew ... models.pdf I have tried to sum up the core of SD languages, and some extensions. I have tested the "inner core SD" feature set against the models in Sterman's Business Dynamics, and found that if we include the extensions listed in chapters 6.1 through 6.4, all the models are covered. My conclusion is that the core SD language must contain at least the following:
  1. Inner core (immediate variables, stock variables, numerical integration, literals, and mathematical expressions involving variables, literals; the operators plus, minus, multiply, divide, and power).
  2. Choice (conditional expressions)
  3. Lookup (interpolation, extrapolation)
  4. Logarithm, exponential, and square root functions
  5. Trigonometric functions (sin, cos, tan)
  6. Statistical functions (min, max)
  7. Delay functions (information and material delays of order N=1, 3 and infinity)
  8. Test input functions (pulse, ramp, step)
  9. Random process functions
Do you have an overview of which extensions are needed to capture the bulk of models you have in mind? Are some of the needed features outside the list above?

Best regards,
Magne

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

Re: Back to basics?

Post by Robert Eberlein » Thu Aug 15, 2013 5:07 am

Hi Magne,

Subscripts are used in a large number of models (eg C-Roads).
Most people who model population use either subscripts of conveyors.
Throughput simulations make use of queues.
Many people use exogenous variables - admittedly input in different forms.
There are lots of module based models from Stella/iThink users.

I think those are the key things, and they (except data) are called out as extensions in section 3.1 of the draft XMILE spec.

The business dynamic models are intended as pedagogical and it is definitely true that you can do great system dynamics without using any of the above functionality. In practice, though, they are commonly used and if we are going to push our standards for documentation and replicatability in the field having a language rich enough to hand these would be of great value.

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

Re: Back to basics?

Post by Magne Myrtveit » Fri Aug 16, 2013 3:33 am

Hi Bob,

Thanks for the extended list. One way to deal with this, is to analyse each extension and try to come up with forward-looking (as opposed to backward-looking) functionality which at the same time is possible to support (with limited effort/modifications) by current vendors. Here is a list of questions to each of your items:
  1. Arrays/Subscripts - To me subscripts is a part of the larger concept of array variables. Do you agree?
  2. Conveyors - Can this be implemented as a function? (see note 1)
  3. Queues - As above
  4. Exogenous variables - Can we use literal arrays here, making it a special case if item 1?
  5. Modules - Can you define what you mean by a module? (see note 2)
Note 1: A possible function representation of conveyors can be the following:
  • Syntax:
    • delay material(input:number, length:duration, leak:urate=0, initial:number=input) : number
    Inputs:
    • input - Quantity to be delayed.
      length - Duration of the delay.
      leak - Leakage rate, i.e., %/month. Default value is 0.
      initial - Initial input flow used to initialise internal stocks. Default value is input.
    Return:
    • Infinite order material delay of input.
Note 2: Modules and other structural aggregation mechanisms
Vendors have introduced may partly overlapping concepts: groups, modules, macros, script functions, components, sectors, hierarchy, submodels, co-models, etc. We need to define what we mean by each of the terms, as they are used differently by different systems. Here are some criteria for categorisation:
  1. Hierarchy - Are objects placed inside objects by the feature?
  2. Namespace - Does the feature create a local namespace for objects?
  3. Equation/value - Does the feature calculate/return a value, or is it just a container for variables and other objects? (I.e., can the feature be used on the right-hand side of an equation?)
  4. Execution - Is the feature evaluated by a separate integration process?
  5. Visualisation - Does the feature support separate visualisation(s) of itself and/or its contents?
  6. Instantiation - Can each instance of the feature be "replicated" (without copying)?
  7. Other?
Which building blocks of the modelling language use the different combinations of the above attributes, what should they be named (in the standard), how will they work (semantics), and what will they look like (syntax)?

Best regards,
Magne

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

Re: Back to basics?

Post by Robert Eberlein » Sun Aug 18, 2013 6:05 am

Hi Magne,

There is a lot of overlap in the different discussion threads.

to respond to your questions

1. Subscripts/Arrays - as you pointed out elsewhere this is a lot of different terminology in use. Yes subscripted variables are simply arrayed variables. I would say variables with one or more dimension, but that would also be a cause for confusion. As you have pointed out elsewhere you can accomplish the same thing with models that can be instantiated multiple times so the overlap is more than just terminology.
2/3. Conveyors and Queues - yes these can be implemented as functions. We need to be careful to support different visual representations of this without requiring that.
4. Data - data can certainly be represented by time/value pairs in an array structure just as Table functions can.
5. Module is ithink terminology for a container for a submodel. Again so many words for the same thing.

Oh, and I forgot macros (at least simple macros) as things many people use in published models.

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

Re: Back to basics?

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

Hi Bob,
Ok, I think we are in line here. Your answer to item 5 is a little unclear to me:
Robert Eberlein wrote: 5. Module is ithink terminology for a container for a submodel.
Does "container" in your statement refer to a model object, while "submodel" refers to the descendants of that object?

Has "module" its own simulation process, or is it integrated together with the main model's equations?

Does the module have a parameter interface (inputs/outputs) or can equations outside the module refer to variables inside the module, and vice versa?

Best regards,
Magne

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

Re: Back to basics?

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

Hi Magne,

The <i>module</i> object in iThink is, as Bob says, just a vanilla container for a submodel. It has no equation and is not integrated, but its name is important as it qualifies names of variables in that submodel when they are used outside that submodel. The module object has inputs and outputs (both connectors), so it also visually represents the connections to the submodel.

We tend to also refer to the submodel itself as a module.

Karim

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest