SMILE and XMILE

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.
Robert Eberlein
Site Admin
Posts: 179
Joined: Sat Dec 27, 2008 8:09 pm

SMILE and XMILE

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

As much as I admire Jim Hines and his wonderful penchant for coming up with words intended to make us feel better, I do think we should stop using SMILE. XMILE is the standard and it encompasses both the equations and the display. I do think it makes sense to separate out the computational portion of the model structure from the display information. I also think the computational portion deserves substantial discussion before the Schema implementation is described.

Given that I would suggest the following layout (though it may be that the standards for standards writing dictate something else):

1. Short background as is
2. Container Schema (version codes, producer...)
3. Model equation structure
4. Model equation schema
5. Display and widget structure
6. Display and widget schema

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

Re: SMILE and XMILE

Post by Magne Myrtveit » Thu Aug 08, 2013 4:18 pm

A) To Bob's suggestion about stop using SMILE:

A language - such as a modelling language - is an abstract phenomenon, which requires a representation to become useful. The human-centric equations syntax, and the corresponding graphical syntax, are two representation of a system dynamics language, while a computer-centric XML-based document format is another representation.

This supports Bob's suggestion to work with just one name for the language.

My opinion is - for what it is worth - that the core system dynamics language (the standard) should be called something like SDL or SDCML (System Dynamics Community Model Language), while extensions to that language should be named by the respective vendors.

Since XMILE de facto is a isee language, given its elaborate definition of non-standard extensions to core SD, it should either be reserved for isee, or otherwise XMILE must be scaled down to the bone, and isee asked to pick a new name for their extended version, for example The isee modelling language, or the iThink language.

In general, it makes no sense that a vendor's language and the standard language for a community are one and the same. One way to see why, is to notice that the first extension or change this vendor makes to the language, will introduce a conflict between the standard language and the vendor's language.

(The naming and scope of XMILE belongs to a larger discussion of potentially good and bad consequences of different ways to set the standard).

B) To Bob's suggestions for layout of our discussion: I agree that we need to structure our exchange. But in my view, schemas (DTD and XSD) belong to the syntax level of the document representation of a language, i.e., quite far down in the language levels, as I described in viewtopic.php?f=21&t=350. A DTD can, if people learn how to read it, serve as a high-level definition of objects, object properties, and object relationships at the conceptual level of a model. However, it is better to use simple class diagrams or drawings at this level. (XSD is quite unreadable, and useful only at the final stages of specification, as a help for developers to create and test their implementation of the standard). Therefore, I think we can postpone schema definitions to quite late in the process.

Best regards from sunny Norway,
Magne

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

Re: SMILE and XMILE

Post by Magne Myrtveit » Fri Aug 09, 2013 3:42 am

Regarding naming of the SD standard core language, it is a pity that "J" is already occupied for another computer language. It would have been great to honour the founder of the field by naming the language after him. However, "JF" too, is a nice name for a language -- not to mention JFK :D

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

Re: SMILE and XMILE

Post by Robert Eberlein » Fri Aug 09, 2013 8:44 am

Magne,

Thanks for the comments on this and your excellent writeup on data flow modeling frameworks.

I believe that you have ultimately argued in favor of distinction between the name by which the computational language is called and that for its encoding (not to mention the encoding for visual representations and control features). It would indeed have been cool to use a moniker like J for a common computational language, but perhaps something more mundane such a SDCL for System Dynamics Computational Language would work. I guess my biggest objection to SMILE is that is always getting mixed up with XMILE.

Leaving naming aside for a moment, there is a more fundamental question of what is the clearest way of representing the underlying computational language. Dynamo and Vensim use the very traditional ordinary text representation with = for assignment as in:

A=B

In Dynamo that representation was exactly what there was, and users changed it by editing the text. In the modern SD languages, however, people rarely deal with such text. The XMILE encoding which would be

<aux name="A">
<eqn>B</eqn>
</aux>

This is probably closer to what most users see (replacing the markup with a dialog of some sort). So the question I am struggling with is whether it is best to specify the entire language in a more traditional format, then specify the encoding which is necessarily a partially parsed version of that language, or specify the language in such a way that the encoding adds only tag formality and does not require any parsing relative to the specification.

Originally I was leaning toward the former, which is not surprising given that this is exactly how Vensim works. Now, however, I am leaning somewhat more toward the latter, as it simplifies a number of issues. Two exemplars are subscripts and non-negative levels.

Using the traditional assignment representation when a variable appears with subscripts it is necessary to try to determine what those subscripts mean. Encountering "Population[1]" in an equation simply tells us that the variable "Population" has a single subscript, nothing about what the subscript is. If, however, the variable Population shows up with something like:

Level: Population
Subscripts: AgeGroup
Units: Person

and so on then "Population[1]" is perfectly well defined.

Similarly, for a non negative level we ,might have something like

Level: WorkInProcess
Outflows: Rejects, Completions
Nonnegative: Completions, Rejects

and so on. (Two important comments. 1. I completely reject the use of nonnegative level constructs because the explicitly mask the feedback that must be in place to make them come true. 2. I do not think we should restrict Level formulations to only have explicitly named input and outputs as this is too constraining especially for people (like me) who never use SMOOTH/SMTH1).

I think the current computational description (the SMILE draft) should reflect these structures more clearly. I recognize that there is a bit of a chicken and egg problem here (that the XML definition depends on the spec which is created with the XML definition in mind). And that there are some programmatic overtones (what data structures are necessary to implement will partly drive the definitions). Still, I think we can achieve clarity and have the computational specification as readable by a typical modeler as it would be with the more traditional assignment notation.

I would very much like to hear the thoughts of others on this.

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

Re: SMILE and XMILE

Post by Magne Myrtveit » Sat Aug 10, 2013 4:47 pm

Hi Bob,

It would be great to have more people involved in this thread. Hopefully we will get company soon. Below are some comments to your recent post. (Page numbers refer to "A framework for dataflow models").

Naming
I guess my biggest objection to SMILE is that is always getting mixed up with XMILE.
Agree. If used for the SD Core Language (SDCL) the X in XMILE is also misleading, since XML is a computer-centric representation of structured contents.

Equation format
So the question I am struggling with is whether it is best to specify the entire language in a more traditional format, then specify the encoding which is necessarily a partially parsed version of that language, or specify the language in such a way that the encoding adds only tag formality and does not require any parsing relative to the specification.
A language should be defined in terms of its abstract concepts, and represented in different ways, depending on the purpose or situation. Here are some examples:

Example 1: When listing model equations as part of a document (an article, a book, or similar), the conventional mathematical equation is the preferred form:

Code: Select all

name=definition
Example 2: Modern software typically provide access to individual object properties via widgets that are part of the GUI. When this is the case, name will be edited in one widget, and definition in another. (There is no need for the software to parse the equation to separate the name part from the definition part).

Code: Select all

Name: <Enter name here>
Definition: <Enter definition here>
Example 3: Internally, the software represents a variable as an object, with multiple properties. When saving the object to file, a structured representation has many advantages over plain text. XML is one possible framework to use. In my definition of the dataflowml framework, I have specified that the definition property is plan text. The reason for that, is that different vendors use significantly different syntax for the right-hand-side of equations. Vendors can provide extra XML elements for the right-hand side in addition to the text. One possibility is to store the definition as mathml, and as a collection of other XML elements, the way XMILE does it. Following dataflowml, the XML representation for an equation is like this (page 38):

Code: Select all

<m:Variable Id="..." Definition="...">
   <m:Names>
      <m:Name>...</m:Name>
   </m:Names>
   <m:Description/>
<variable/>
The XML format (like the example above) can obviously not be used for publishing equations for humans to read. We do need an equations syntax, that is clear.

Example 4: A DTD can be used to represent the structure of the XML representation of a model (see page 39). It is an "almost human-readable" format, that can be used by programmers to define language structure. (I used it when writing the XML specification of Smia models. Smia documents still contain a complete DTD and XSD defining the document format. The DTD and XSD is auto-generated by Smia's code, so they are always up-to-date when a new Smia release is made).

Structure of expressions
For the text-based representation of equations, it would be nice of we could come up with a framework (a set of keywords) that can be recommended to use. As an example, here is an example of what I suggest for stock definitions:

Code: Select all

account = stock 1000USD inflow interest inflow deposits outflow withdrawals
Subscripts
Encountering "Population[1]" in an equation simply tells us that the variable "Population" has a single subscript, nothing about what the subscript is.
The equation where population is defined, will contain the necessary information about the dimensions of Population. When the variable is used on the right-hand-side of some equation, subscripts will be checked against the definition of the subscribed variable. This will be the case no matter how the variables are represented, assuming that the equations-based representation contains as much information as any structured representation that might be used instead. To be specific, let us look at your example:

Code: Select all

Level: Population
Subscripts: AgeGroup
Units: Person
A single equation can capture exactly the same information, like this:

Code: Select all

Population = stock {AgeGroup | ... } as Person
Here I make use of my suggestion to use braces {...} for arrays and "as ..." for giving the type and/or unit of a variable. Note that "as Person" is needed only if the expression defining the variable does not implicitly determine the data type and unit of the variable.

A problem with representing the definition of a variable, say, as a structured text, is that this would require a very elaborate structure definition, if we are going to support many vendor's dialects (and extensions) of the grammar (syntax as well as semantics) of equations.

Non-negative stocks
I completely reject the use of nonnegative level constructs
Agree 100%

Flow expressions
I do not think we should restrict Level formulations to only have explicitly named input and outputs as this is too constraining
Agree 100%. In Smia, any mathematical expression can be used in the position of a flow. As mentioned on p 49 in my dataflow PDF, it is conceptually wrong to define a separate variable type for flows. It is up to each vendor, of course, to break concepts, but it should not be permitted in a standard for SD.

Best regards,
Magne

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

Re: SMILE and XMILE

Post by Robert Eberlein » Sun Aug 11, 2013 5:47 am

Hi Magne,

Just one comment on this. A pretty standard equation for population in Vensim is:

Population [gender, AG00]= INTEG (
+ births[gender]- deaths[gender,AG00] + net migrating[gender,AG00],
init pop[gender,AG00]) ~~|
Population[gender,AG01andOver]= INTEG (
-deaths[gender,AG01andOver] + net migrating[gender,AG01andOver],
init pop[gender,AG01andOver])
~ person
~ |

or, if you are not using a cohort control function

Population[gender,A0]= INTEG (
births[gender]-deaths[gender,A0]-aging[gender,A0],
initial population[gender,A0]) ~~|
Population[gender,AR1To99]= INTEG (
aging[gender,AR0To98]-deaths[gender,AR1To99]-aging[gender,AR1To99],
initial population[gender,AR1To99]) ~~|
Population[gender,A100P]= INTEG (
aging[gender,A99]-deaths[gender,A100P],
initial population[gender,A100P])
~ Person
~ |

In both cases, and others like this, the subscripts on population can only be determined by knowing that the subscript elements and subranges used are part of the subscript Age. In Vensim this works because no numbers are allowed and all subscript element names must be unique names. Without that (or tagging) the models would become indeterminant in some cases.

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

Re: SMILE and XMILE

Post by Magne Myrtveit » Mon Aug 12, 2013 4:32 am

Hi Bob,

First, allow me to correct something in my previous posting. My Example 4 does actually not belong together with the other tree examples, as DTD is a representation of a language, rather than a model. (DTD is similar to BNF in may ways). Example 4 can be replaced by stock-and-flow or causal-loop representations of models.

Also, I don't know if the point I meant to make about equations language disappeared inside my lengthy text. Restating it here: Model equations are needed when writing about models (in forums like this, for example). Equations should be complete in the sense that it must be possible for humans, and computers as well, to reconstruct and evaluate the model from its equations. It is up to each vendor to determine if the equations syntax will be used by their software also when writing models to file (the MDL (Vensim) way), or if model files use a structured representation of models (the SIP (Powersim), DPA (Dynaplan), Excel, and XMILE way). Smia has a File | Save as feature, that allows the user to store a model in binary format, XML format, or equations format (plain text or HTML).

To your statement in our most recent post:
The subscripts on population can only be determined by knowing that the subscript elements and subranges used are part of the subscript Age. In Vensim this works because no numbers are allowed and all subscript element names must be unique names. Without that (or tagging) the models would become indeterminant in some cases.
There is another solution to this problem, which is to make the full dimensions available at the right-hand side of Population's equation, and to merge multiple equations into one, using the approach shown in Figure 66, page 48, in "A framework for dataflow models". This also opens up for using any data type for dimensions; not only lists of named elements.

Let me demonstrate with the basis in your first code example, which looks like this:

Code: Select all

Population [gender, AG00]= INTEG (
 + births[gender]- deaths[gender,AG00] + net migrating[gender,AG00],
 init pop[gender,AG00]) ~~|
Population[gender,AG01andOver]= INTEG (
 -deaths[gender,AG01andOver] + net migrating[gender,AG01andOver],
 init pop[gender,AG01andOver])
 ~ person
 ~ |
A single-equation version would look something like this:

Code: Select all

Population = stock {gender, Age | 'init pop' }
	inflow { gender, AG00 => births(gender) }
	outflow deaths
	inflow 'net migrating'
Line-by-line explanation:
  1. Population is defined as a stock with dimensions gender and Age and initial value init pop.
  2. Births is defined as an inflow, capturing the information that Vensim puts into multiple equations for Population.
  3. Deaths is defined as an outflow. Since all elements of Pop can use the same expression, no array syntax is needed here.
  4. Net migration is defined as an inflow.
The tricks are located in line 1 and 2, which defines full dimensions (line 1) and multiple expressions (line 2).

Smia has many ways to express equations like the one above. One alternative syntax for line 2, makes use of index variables and dimension operators (==) and (:=):

Code: Select all

Population = stock {g==gender, a==Age | 'init pop' }
	inflow { g==*, a:=* | births(gender), 0 }
	outflow deaths
	inflow 'net migrating'
The operator == says that all elements of the dimension share the same expression, while := says that the first element has one expression, and the rest another one.

Best regards,
Magne

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

Re: SMILE and XMILE

Post by Robert Eberlein » Mon Aug 12, 2013 7:31 am

Hi Magne,

I am with you on equations. I am just thinking in the specifications we write how we distinguish these from the encoding. I will ask Ignacio Martinez to jump in with comments as well as I know he has spent some time thinking about this.

You picked the easy subscript example, and I unfortunately can't see how the more complex one fits this pattern. If you could reconstruct the following it would be helpful to me:

WIP[Stage1]= INTEG (ProductionStarts-WIP[Stage1]/ProdTime[Stage1], 0) ~~|
WIP[StageMid]= INTEG (WIP[StagePrior]/ProdTime[StagePrior]-WIP[StageMid]/ProdTime[StageMid],0) ~~|
WIP[Stage22]= INTEG (WIP[Stage21]/ProdTime[Stage21]-shipments,0) ~ Widget ~|

in this case StageMid is Stage2...Stage21 and StagePriod is Stage1...Stage20 with a map to StageMid to make the second equation sensible.

Bob Eberlein

Travis Franck
Posts: 34
Joined: Sun Jan 11, 2009 7:48 pm

Re: SMILE and XMILE

Post by Travis Franck » Tue Aug 13, 2013 8:32 am

Apologies in advance if I missed a subtly in the discussion -- it appears you both have thought about all this for a long time. But you did ask for company! ;)

In my head, there is the file format and what is printed in journals (i.e., the human readable form). The discussion appears to be whether the human-readable (say, SMILE) needs to be defined separate from the file format (XMILE) as a spec/standard.

Isn't the human-readable form pretty much defined already by standard mathematics? Right-hand side equals left-hand side? I guess I don't know how else you would write human-readable equations in a journal. I know there many fields, e.g., economics, that code a model in a programming language, but then use standard math formatting when publishing and discussing. I did the same in my SD work.

So, this would lead me to think that defining the XML format is most important. That is, we might be able to get by having XMILE without SMILE.

And when it comes to model documentation, people would archive the XMILE, use XMILE in their dissertation appendix, use 'math' formatting in their papers and dissertation discussion, and use a XMILE-to-HTML converters for cool documentation tools like Ignacio makes.

I write this acknowledging that I didn't fully follow the above thread about subscripts, but maybe this is a moment to pause and bring more of us up to speed.

~Travis

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

Re: SMILE and XMILE

Post by Thomas Fiddaman » Tue Aug 13, 2013 2:18 pm

My possibly naive impression was that the purpose of SMILE is to define the constructs that constitute the equations and ancillary bits of a model, with XMILE as a file format for storing SMILE. But on reflection there seems to be quite a bit of overlap - both SMILE and XMILE define stocks and flows, for example, whereas an alternate approach would be to have a SMILE-like spec for what constitutes an equation, and then an XMILE spec for storing an equation that's agnostic about what kind of equation it is.

As long as XMILE defines an <eqn> field without caring what's in it, it seems that SMILE is needed in order to specify the operators, functions, naming etc. needed to interpret the RHS of the <eqn>.

Regarding naming, I don't mind the current options, but in the spirit of Travis' comment, we could use .J or .JK, with a nod to the dynamo integration syntax.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest