Numerus Simulation Architecture - Revision history

Rsalter: /* Components and Scope */

2018-06-09T19:45:40Z

Components and Scope

← Older revision		Revision as of 19:45, 9 June 2018
Line 6:		Line 6:
	The simplest Container is the '''Chip''', which wraps a Capsule for insertion as a component in a parent Capsule. Other containers are called '''aggregators''' since they bind together multiple Capsule elements in a specific topology. Currently there are 5 aggregators: '''CellMatrix''', '''AgentVector''', '''SimWorld''', '''NodeNetwork''' and '''NetWorld'''. Each of these is described in detail [[Component_Guide_II:_Containers\|elsewhere]]. The Capsule type used in each aggregator is an extension to the fundamental Capsule type, designed to complement the topology introduced by that aggregator. For example, the contents of a CellMatrix are of a Cell type which is a Capsule that is aware of its row/column location.		The simplest Container is the '''Chip''', which wraps a Capsule for insertion as a component in a parent Capsule. Other containers are called '''aggregators''' since they bind together multiple Capsule elements in a specific topology. Currently there are 5 aggregators: '''CellMatrix''', '''AgentVector''', '''SimWorld''', '''NodeNetwork''' and '''NetWorld'''. Each of these is described in detail [[Component_Guide_II:_Containers\|elsewhere]]. The Capsule type used in each aggregator is an extension to the fundamental Capsule type, designed to complement the topology introduced by that aggregator. For example, the contents of a CellMatrix are of a Cell type which is a Capsule that is aware of its row/column location.

	==Components and Scope==		==Scope==
			===Components and Scope===
	Every value-producing component (Stock, Term, Flow, etc.) is part of the architecture in two ways. First there is the component object itself which holds the machinery for producing its value, and then there is the value that is produced. So if a particular component ''pop'' is part of some Capsule, we might refer to ''pop'' either to obtain its current value (such references are almost always used in the equations defining the model); or we might need to obtain a reference to the component object to, say, look up an old value or access some parameter<ref>Given a component object ''c'', its current value is obtained using <code>c.value()</code></ref>. While the latter is uncommon, such situations occasionally arise.		Every value-producing component (Stock, Term, Flow, etc.) is part of the architecture in two ways. First there is the component object itself which holds the machinery for producing its value, and then there is the value that is produced. So if a particular component ''pop'' is part of some Capsule, we might refer to ''pop'' either to obtain its current value (such references are almost always used in the equations defining the model); or we might need to obtain a reference to the component object to, say, look up an old value or access some parameter<ref>Given a component object ''c'', its current value is obtained using <code>c.value()</code></ref>. While the latter is uncommon, such situations occasionally arise.

Rsalter: /* Scope and Formulas */

2018-06-09T19:27:55Z

Scope and Formulas

← Older revision		Revision as of 19:27, 9 June 2018
Line 28:		Line 28:
	etc.		etc.
	===Scope and Formulas===		===Scope and Formulas===
	The "connective tissue" that links the components in model is comprised of algebraic formulas or program code that ~~computes the value~~ of ~~a component~~ using the values of other components. A reference to a component in such a formula should represent its scope value rather than its component value. Thus we have the following rule:		The "connective tissue" that links the components in a model is comprised of algebraic formulas or program code that compute values of components using the values of other components. A reference to a component in such a formula should represent its scope value rather than its component value. Thus we have the following rule:

	<big>Every equation, formula or algorithm used to compute the value of a component does so with respect to the scope of the Capsule instance containing that component.</big>		<big>Every equation, formula or algorithm used to compute the value of a component does so with respect to the scope of the Capsule instance containing that component.</big>

Rsalter: /* Components and Scope */

2018-06-09T18:43:47Z

Components and Scope

← Older revision		Revision as of 18:43, 9 June 2018
Line 11:		Line 11:
	Consequently, the unadorned reference ''pop'' is ambiguous: do we mean the object or the value? In order to make this precise we introduce the concept of '''scope'''. Each simulator (Capsule, AgemtVector, CellMatrix, etc.) has a ''scope'' object which is contained in its ''scope'' property. The scope is a property list<ref>A ''property list'' associates property names, which are strings, with values. For example, if ''P'' is a property list containing values for properties ''a'', ''b'', and ''c'', then the notation <code>P.a</code>, <code>P.b</code>, and <code>P.c</code> is used to extract the property values from the list. Alternatively we could use <code>P["a"]</code>, <code>P["b"]</code> and <code>P["c"]</code>.</ref> mapping the names of all components in the Simulator to their current values. The scope also contains references to primitive operators (primops) and properties germane to that Simulator.		Consequently, the unadorned reference ''pop'' is ambiguous: do we mean the object or the value? In order to make this precise we introduce the concept of '''scope'''. Each simulator (Capsule, AgemtVector, CellMatrix, etc.) has a ''scope'' object which is contained in its ''scope'' property. The scope is a property list<ref>A ''property list'' associates property names, which are strings, with values. For example, if ''P'' is a property list containing values for properties ''a'', ''b'', and ''c'', then the notation <code>P.a</code>, <code>P.b</code>, and <code>P.c</code> is used to extract the property values from the list. Alternatively we could use <code>P["a"]</code>, <code>P["b"]</code> and <code>P["c"]</code>.</ref> mapping the names of all components in the Simulator to their current values. The scope also contains references to primitive operators (primops) and properties germane to that Simulator.

	The scope also contains a special property, '''_cap_'''<ref>in Nova 2 this was called '''Self'''</ref> referring to the Simulator for which it ths scope. ~~Thus~~ if ''Y'' is the scope object for Simulator ''X'', then <code>Y._cap_</code> will produce X. Thus we have a way of going from Simulator to scope (using the "scope" property) and from scope to Simulator (using the "_cap_" property). This provides a means for retrieving either the component object or its value from any component in a Capsule.		The scope also contains a special property, '''_cap_'''<ref>in Nova 2 this was called '''Self'''</ref> referring to the Simulator for which it ths scope. For example, if ''Y'' is the scope object for Simulator ''X'', then <code>Y._cap_</code> will produce X. Thus we have a way of going from Simulator to scope (using the "scope" property) and from scope to Simulator (using the "_cap_" property). This provides a means for retrieving either the component object or its value from any component in a Capsule.

	Example: Assume Capsule ''C'' contains components ''a'', ''b'' and ''c'', with current values 10, 20 and 30, respectively. Let ''CS'' be the scope of ''C''. Then		Example: Assume Capsule ''C'' contains components ''a'', ''b'' and ''c'', with current values 10, 20 and 30, respectively. Let ''CS'' be the scope of ''C''. Then

Rsalter: /* Components and Scope */

2018-06-09T18:43:21Z

Components and Scope

← Older revision		Revision as of 18:43, 9 June 2018
Line 11:		Line 11:
	Consequently, the unadorned reference ''pop'' is ambiguous: do we mean the object or the value? In order to make this precise we introduce the concept of '''scope'''. Each simulator (Capsule, AgemtVector, CellMatrix, etc.) has a ''scope'' object which is contained in its ''scope'' property. The scope is a property list<ref>A ''property list'' associates property names, which are strings, with values. For example, if ''P'' is a property list containing values for properties ''a'', ''b'', and ''c'', then the notation <code>P.a</code>, <code>P.b</code>, and <code>P.c</code> is used to extract the property values from the list. Alternatively we could use <code>P["a"]</code>, <code>P["b"]</code> and <code>P["c"]</code>.</ref> mapping the names of all components in the Simulator to their current values. The scope also contains references to primitive operators (primops) and properties germane to that Simulator.		Consequently, the unadorned reference ''pop'' is ambiguous: do we mean the object or the value? In order to make this precise we introduce the concept of '''scope'''. Each simulator (Capsule, AgemtVector, CellMatrix, etc.) has a ''scope'' object which is contained in its ''scope'' property. The scope is a property list<ref>A ''property list'' associates property names, which are strings, with values. For example, if ''P'' is a property list containing values for properties ''a'', ''b'', and ''c'', then the notation <code>P.a</code>, <code>P.b</code>, and <code>P.c</code> is used to extract the property values from the list. Alternatively we could use <code>P["a"]</code>, <code>P["b"]</code> and <code>P["c"]</code>.</ref> mapping the names of all components in the Simulator to their current values. The scope also contains references to primitive operators (primops) and properties germane to that Simulator.

	The scope also contains a special property, '''_cap_'''<ref>in Nova 2 this was called '''Self'''</ref>. Thus if ''Y'' is the scope object for Simulator ''X'', then <code>Y._cap_</code> will produce X. Thus we have a way of going from Simulator to scope (using the "scope" property) and from scope to Simulator (using the "_cap_" property). This provides a means for retrieving either the component object or its value from any component in a Capsule.		The scope also contains a special property, '''_cap_'''<ref>in Nova 2 this was called '''Self'''</ref> referring to the Simulator for which it ths scope. Thus if ''Y'' is the scope object for Simulator ''X'', then <code>Y._cap_</code> will produce X. Thus we have a way of going from Simulator to scope (using the "scope" property) and from scope to Simulator (using the "_cap_" property). This provides a means for retrieving either the component object or its value from any component in a Capsule.

	Example: Assume Capsule ''C'' contains components ''a'', ''b'' and ''c'', with current values 10, 20 and 30, respectively. Let ''CS'' be the scope of ''C''. Then		Example: Assume Capsule ''C'' contains components ''a'', ''b'' and ''c'', with current values 10, 20 and 30, respectively. Let ''CS'' be the scope of ''C''. Then

Rsalter: /* Components and Scope */

2018-06-09T18:42:33Z

Components and Scope

← Older revision		Revision as of 18:42, 9 June 2018
Line 9:		Line 9:
	Every value-producing component (Stock, Term, Flow, etc.) is part of the architecture in two ways. First there is the component object itself which holds the machinery for producing its value, and then there is the value that is produced. So if a particular component ''pop'' is part of some Capsule, we might refer to ''pop'' either to obtain its current value (such references are almost always used in the equations defining the model); or we might need to obtain a reference to the component object to, say, look up an old value or access some parameter<ref>Given a component object ''c'', its current value is obtained using <code>c.value()</code></ref>. While the latter is uncommon, such situations occasionally arise.		Every value-producing component (Stock, Term, Flow, etc.) is part of the architecture in two ways. First there is the component object itself which holds the machinery for producing its value, and then there is the value that is produced. So if a particular component ''pop'' is part of some Capsule, we might refer to ''pop'' either to obtain its current value (such references are almost always used in the equations defining the model); or we might need to obtain a reference to the component object to, say, look up an old value or access some parameter<ref>Given a component object ''c'', its current value is obtained using <code>c.value()</code></ref>. While the latter is uncommon, such situations occasionally arise.

	Consequently, the unadorned reference ''pop'' is ambiguous: do we mean the object or the value? In order to make this precise we introduce the concept of '''scope'''. Each simulator (Capsule, AgemtVector, CellMatrix, etc.) has a ''scope'' object which is contained in its ''scope'' property. The scope is a property list<ref>A ''property list'' associates property names, which are strings, with values. For example, if ''P'' is a property list containing values for properties ''a'', ''b'', and ''c'', then the notation <code>P.a</code>, <code>P.b</code>, and <code>P.c</code> is used to extract the property values from the list. Alternatively we could use <code>P["a"]</code>, <code>P["b"]</code> and <code>P["c"]</code>.</ref> mapping the names of all components in the Simulator to ~~its~~ current ~~value~~. The scope also contains references to primitive operators (primops) and properties germane to that Simulator.		Consequently, the unadorned reference ''pop'' is ambiguous: do we mean the object or the value? In order to make this precise we introduce the concept of '''scope'''. Each simulator (Capsule, AgemtVector, CellMatrix, etc.) has a ''scope'' object which is contained in its ''scope'' property. The scope is a property list<ref>A ''property list'' associates property names, which are strings, with values. For example, if ''P'' is a property list containing values for properties ''a'', ''b'', and ''c'', then the notation <code>P.a</code>, <code>P.b</code>, and <code>P.c</code> is used to extract the property values from the list. Alternatively we could use <code>P["a"]</code>, <code>P["b"]</code> and <code>P["c"]</code>.</ref> mapping the names of all components in the Simulator to their current values. The scope also contains references to primitive operators (primops) and properties germane to that Simulator.

	The scope also contains a special property, '''_cap_'''<ref>in Nova 2 this was called '''Self'''</ref>. Thus if ''Y'' is the scope object for Simulator ''X'', then <code>Y._cap_</code> will produce X. Thus we have a way of going from Simulator to scope (using the "scope" property) and from scope to Simulator (using the "_cap_" property). This provides a means for retrieving either the component object or its value from any component in a Capsule.		The scope also contains a special property, '''_cap_'''<ref>in Nova 2 this was called '''Self'''</ref>. Thus if ''Y'' is the scope object for Simulator ''X'', then <code>Y._cap_</code> will produce X. Thus we have a way of going from Simulator to scope (using the "scope" property) and from scope to Simulator (using the "_cap_" property). This provides a means for retrieving either the component object or its value from any component in a Capsule.

Rsalter: /* Components and Scope */

2018-06-09T18:42:07Z

Components and Scope

← Older revision		Revision as of 18:42, 9 June 2018
Line 9:		Line 9:
	Every value-producing component (Stock, Term, Flow, etc.) is part of the architecture in two ways. First there is the component object itself which holds the machinery for producing its value, and then there is the value that is produced. So if a particular component ''pop'' is part of some Capsule, we might refer to ''pop'' either to obtain its current value (such references are almost always used in the equations defining the model); or we might need to obtain a reference to the component object to, say, look up an old value or access some parameter<ref>Given a component object ''c'', its current value is obtained using <code>c.value()</code></ref>. While the latter is uncommon, such situations occasionally arise.		Every value-producing component (Stock, Term, Flow, etc.) is part of the architecture in two ways. First there is the component object itself which holds the machinery for producing its value, and then there is the value that is produced. So if a particular component ''pop'' is part of some Capsule, we might refer to ''pop'' either to obtain its current value (such references are almost always used in the equations defining the model); or we might need to obtain a reference to the component object to, say, look up an old value or access some parameter<ref>Given a component object ''c'', its current value is obtained using <code>c.value()</code></ref>. While the latter is uncommon, such situations occasionally arise.

	Consequently, the unadorned reference ''pop'' is ambiguous: do we mean the object or the value? In order to make this precise we introduce the concept of '''scope'''. Each simulator (Capsule, AgemtVector, CellMatrix, etc.) has a ''scope'' object which is contained in its scope property. The scope is property list<ref>A ''property list'' associates property names, which are strings, with values. For example, if ''P'' is a property list containing values for properties ''a'', ''b'', and ''c'', then the notation <code>P.a</code>, <code>P.b</code>, and <code>P.c</code> is used to extract the property values from the list. Alternatively we could use <code>P["a"]</code>, <code>P["b"]</code> and <code>P["c"]</code>.</ref> mapping the names of all components in the Simulator to its current value. The scope also contains references to primitive operators (primops) and properties germane to that Simulator.		Consequently, the unadorned reference ''pop'' is ambiguous: do we mean the object or the value? In order to make this precise we introduce the concept of '''scope'''. Each simulator (Capsule, AgemtVector, CellMatrix, etc.) has a ''scope'' object which is contained in its ''scope'' property. The scope is a property list<ref>A ''property list'' associates property names, which are strings, with values. For example, if ''P'' is a property list containing values for properties ''a'', ''b'', and ''c'', then the notation <code>P.a</code>, <code>P.b</code>, and <code>P.c</code> is used to extract the property values from the list. Alternatively we could use <code>P["a"]</code>, <code>P["b"]</code> and <code>P["c"]</code>.</ref> mapping the names of all components in the Simulator to its current value. The scope also contains references to primitive operators (primops) and properties germane to that Simulator.

	The scope also contains a special property, '''_cap_'''<ref>in Nova 2 this was called '''Self'''</ref>. Thus if ''Y'' is the scope object for Simulator ''X'', then <code>Y._cap_</code> will produce X. Thus we have a way of going from Simulator to scope (using the "scope" property) and from scope to Simulator (using the "_cap_" property). This provides a means for retrieving either the component object or its value from any component in a Capsule.		The scope also contains a special property, '''_cap_'''<ref>in Nova 2 this was called '''Self'''</ref>. Thus if ''Y'' is the scope object for Simulator ''X'', then <code>Y._cap_</code> will produce X. Thus we have a way of going from Simulator to scope (using the "scope" property) and from scope to Simulator (using the "_cap_" property). This provides a means for retrieving either the component object or its value from any component in a Capsule.

Rsalter: /* Components and Scope */

2018-06-09T18:40:07Z

Components and Scope

← Older revision		Revision as of 18:40, 9 June 2018
Line 7:		Line 7:

	==Components and Scope==		==Components and Scope==
	Every value-producing component (Stock, Term, Flow, etc.) is part of the architecture in two ways. First there is the component object itself which holds the machinery for producing its value, and then there is the value ~~itself~~. So if a particular component ''pop'' is part of some Capsule, we might refer to ''pop'' either to obtain its current value (such references are almost always used in the equations defining the model); or we might need to obtain a reference to the component object to, say, look up an old value or access some parameter<ref>Given a component object ''c'', its current value is obtained using <code>c.value()</code></ref>. While the latter is uncommon, such situations occasionally arise.		Every value-producing component (Stock, Term, Flow, etc.) is part of the architecture in two ways. First there is the component object itself which holds the machinery for producing its value, and then there is the value that is produced. So if a particular component ''pop'' is part of some Capsule, we might refer to ''pop'' either to obtain its current value (such references are almost always used in the equations defining the model); or we might need to obtain a reference to the component object to, say, look up an old value or access some parameter<ref>Given a component object ''c'', its current value is obtained using <code>c.value()</code></ref>. While the latter is uncommon, such situations occasionally arise.

	Consequently, the unadorned reference ''pop'' is ambiguous: do we mean the object or the value? In order to make this precise we introduce the concept of '''scope'''. Each simulator (Capsule, AgemtVector, CellMatrix, etc.) has a ''scope'' object which is contained in its scope property. The scope is property list<ref>A ''property list'' associates property names, which are strings, with values. For example, if ''P'' is a property list containing values for properties ''a'', ''b'', and ''c'', then the notation <code>P.a</code>, <code>P.b</code>, and <code>P.c</code> is used to extract the property values from the list. Alternatively we could use <code>P["a"]</code>, <code>P["b"]</code> and <code>P["c"]</code>.</ref> mapping the names of all components in the Simulator to its current value. The scope also contains references to primitive operators (primops) and properties germane to that Simulator.		Consequently, the unadorned reference ''pop'' is ambiguous: do we mean the object or the value? In order to make this precise we introduce the concept of '''scope'''. Each simulator (Capsule, AgemtVector, CellMatrix, etc.) has a ''scope'' object which is contained in its scope property. The scope is property list<ref>A ''property list'' associates property names, which are strings, with values. For example, if ''P'' is a property list containing values for properties ''a'', ''b'', and ''c'', then the notation <code>P.a</code>, <code>P.b</code>, and <code>P.c</code> is used to extract the property values from the list. Alternatively we could use <code>P["a"]</code>, <code>P["b"]</code> and <code>P["c"]</code>.</ref> mapping the names of all components in the Simulator to its current value. The scope also contains references to primitive operators (primops) and properties germane to that Simulator.

Rsalter: /* Simulators and Aggregators */

2018-06-09T18:39:23Z

Simulators and Aggregators

← Older revision		Revision as of 18:39, 9 June 2018
Line 4:		Line 4:

	==Simulators and Aggregators==		==Simulators and Aggregators==
	The simplest Container is the '''Chip''', which wraps a Capsule for insertion as a component in a parent Capsule. Other containers are called '''aggregators''' since they bind together multiple Capsule elements in a specific topology. Currently there are 5 aggregators: '''CellMatrix''', '''AgentVector''', '''SimWorld''', '''NodeNetwork''' and '''NetWorld'''. Each of these is described in detail [[Component_Guide_II:_Containers\|elsewhere]]. The Capsule ~~types~~ used in each aggregator is an extension to the fundamental Capsule type ~~which complements~~ the topology introduced by that aggregator. For example, the contents of a CellMatrix are of a Cell type which is a Capsule that is aware of its row/column location.		The simplest Container is the '''Chip''', which wraps a Capsule for insertion as a component in a parent Capsule. Other containers are called '''aggregators''' since they bind together multiple Capsule elements in a specific topology. Currently there are 5 aggregators: '''CellMatrix''', '''AgentVector''', '''SimWorld''', '''NodeNetwork''' and '''NetWorld'''. Each of these is described in detail [[Component_Guide_II:_Containers\|elsewhere]]. The Capsule type used in each aggregator is an extension to the fundamental Capsule type, designed to complement the topology introduced by that aggregator. For example, the contents of a CellMatrix are of a Cell type which is a Capsule that is aware of its row/column location.

	==Components and Scope==		==Components and Scope==

Rsalter at 18:38, 9 June 2018

2018-06-09T18:38:14Z

← Older revision		Revision as of 18:38, 9 June 2018
Line 1:		Line 1:
	Numerus supports a multi-level architecture comprised of '''Simulators'''. The lowest level atomic simulator is called a '''Capsule''', and it is composed of simulation '''components''' (Stocks, Flows, etc.). '''Containers''' are component simulators that contain Capsule instances as elements.		Numerus supports a multi-level architecture comprised of '''Simulators'''. The lowest level atomic simulator is called a '''Capsule''', and it is composed of simulation '''components''' (Stocks, Flows, etc.). '''Containers''' are component simulators that contain Capsule instances as elements.

	A Numerus model is called a '''project'''. At a minimum a project contains a top-level Capsule instance called '''main'''. The ''main'' Capsule will contain components, some of which may be Containers. Each Container contains 1 or more instances of some Capsule<ref>or Agent, Cell, or Node, which are extended versions of the Capsule for use with specific Containers</ref>. Such a Capsule may include its own Containers among its components, and so we obtain a hierarchical structure<ref>Using this approach to obtain a hierarchy of submodels is described [[Modeling_in_Numerus#capsule\|here]]. More complex hierarchies are obtained when using one or more aggregators.<ref>.		A Numerus model is called a '''project'''. At a minimum a project contains a top-level Capsule instance called '''main'''. The ''main'' Capsule will contain components, some of which may be Containers. Each Container contains 1 or more instances of some Capsule<ref>or Agent, Cell, or Node, which are extended versions of the Capsule for use with specific Containers</ref>. Such a Capsule may include its own Containers among its components, and so we obtain a hierarchical structure<ref>Using this approach to obtain a hierarchy of submodels is described [[Modeling_in_Numerus#capsule\|here]]. More complex hierarchies are obtained when using one or more aggregators.</ref>.

	==Simulators and Aggregators==		==Simulators and Aggregators==

Rsalter at 18:37, 9 June 2018

2018-06-09T18:37:51Z

← Older revision		Revision as of 18:37, 9 June 2018
Line 1:		Line 1:
	Numerus supports a multi-level architecture comprised of '''Simulators'''. The lowest level atomic simulator is called a '''Capsule''', and it is composed of simulation '''components''' (Stocks, Flows, etc.). '''Containers''' are component simulators that contain Capsule instances as elements.		Numerus supports a multi-level architecture comprised of '''Simulators'''. The lowest level atomic simulator is called a '''Capsule''', and it is composed of simulation '''components''' (Stocks, Flows, etc.). '''Containers''' are component simulators that contain Capsule instances as elements.

	A Numerus model is called a '''project'''. At a minimum a project contains a top-level Capsule instance called '''main'''. The ''main'' Capsule will contain components, some of which may be Containers. Each Container contains 1 or more instances of some Capsule<ref>or Agent, Cell, or Node, which are extended versions of the Capsule for use with specific Containers</ref>. Such a Capsule may include its own Containers among its components, and so we obtain a hierarchical structure~~, as~~ described [[Modeling_in_Numerus#capsule\|here]].		A Numerus model is called a '''project'''. At a minimum a project contains a top-level Capsule instance called '''main'''. The ''main'' Capsule will contain components, some of which may be Containers. Each Container contains 1 or more instances of some Capsule<ref>or Agent, Cell, or Node, which are extended versions of the Capsule for use with specific Containers</ref>. Such a Capsule may include its own Containers among its components, and so we obtain a hierarchical structure<ref>Using this approach to obtain a hierarchy of submodels is described [[Modeling_in_Numerus#capsule\|here]]. More complex hierarchies are obtained when using one or more aggregators.<ref>.

	==Simulators and Aggregators==		==Simulators and Aggregators==