<< Click to Display Table of Contents >> 9. Add or Delete Entities Dynamically |
|
Show/Hide Hidden Text |
Actions, which we met in Exercise 8, can be used not only to change stocks and attributes, but also to add or remove entities during the simulation. This means that information generated during the run can be used to determine whether entities are created or deleted, and for those being created, what their initial characteristics will be.
The actions that do this are called create actions and self-delete actions. For a simple example of how they work, we'll define our pastures such that if there's more than enough grass, we'll add a cow. If a cow can't find enough grass, she'll self-delete from the model.
Stages of Ventity™ Modeling |
In this run, we will ... |
Stage 1 - Define entity types
|
Change the definition of the cow entity type to self-delete when food is scarce, and change the definition of the pasture entity type to add a cow when food is available. |
Stage 2 - Initialize the model
|
No change from previous runs.
|
Stage 3 - Run the model Configure time settings and perform calculations
|
No change from previous runs.
|
Stage 4 - Examine results See model behavior in graphs and tables
|
See how appearing and disappearing entities appear in charts and tables. |
Let's again pick up from the result of Exercise 6. Save a copy of Exercise 6 Complete, found [here], as "Exercise 9". We'll start by adding a self-delete action to the cow entity type, and a trigger to invoke the action when food supplies get low.
1. Right-click "cow" in the entity and choose "New Action".
2. In the action inspector that appears, change the name to "expire" and the kind to "self-delete".
That's it! Each cow will now disappear from the model if its Expire action is triggered. Self-delete actions are not complicated. However, self-delete actions--and indeed all actions--can also do anything that command actions (see also Exercise 8) can do. So while our cows will merely expire, another entity could include a self-delete action that could sell its house (by triggering a "sell the house" action), transfer its wealth to its heirs (through stocks and flows), appoint a successor to its job (by reassigning another entity's job title attribute) and so on before exiting the model.
We now need to create the trigger to determine when and if a cow should self-delete. An easy way to do this is to open the actions tab of the cow inspector, and drag the Expire action onto the cow diagram. A new trigger will be created called "Expire trigger". Right-click to edit the trigger. Let's say that cows should exit the simulation if they are eating less than 10% of their desired consumption. Set Trigger If: to "actual consumption < .1 * desired consumption" and "Action to Invoke" to "Expire".
And we're done. Cows will now exit the simulation if they are getting less than 10% of their recommended daily allowance of grass.
What about adding cows? This time let's add the action to the pasture entity. This is not terribly realistic; it would be better to have a rancher or farmer entity that would purchase a new cow under certain conditions, or to make the birth of a cow contingent on successful breeding. But we'll simplify all that to this rule: if a pasture is producing 10% more grass than is being consumed, one new cow will appear in that pasture.
Add a new action to the pasture entity, and call it "Add a cow".
Rename the action, Set it to type "Create",
Set it to create cows,
but only 1 cow each time it is invoked.
Note that once you've defined the action, two surrogates appear in the action's diagram. These are properties that every new cow must have: an ID and a pasture assigned. The "newCow" prefix shows that these apply to each new cow.
We will ignore the CowID surrogate. By leaving it blank, we tell Ventity to use whatever rules were used to initialize any cows at the start of the simulation. For ID's in particular, Ventity auto-generates these when no default is given. So we're basically telling Ventity to continue developing ID's for any newly created cows.
But in this model there's no default setting for pasture. We'll need to choose a pasture for each new cow. We already know what we want: for the cow to go to the pasture that has the extra grass, that is, the pasture that owns the action. So we can set the pasture surrogate equal to the pastureID of the parent of the action.To use the parent pasture's pastureID, edit the pasture surrogate:
If you right-click the underlined parent.PastureID, Ventity will give you an easy way to show the input to this attribute on the diagram. Choose "draw arrow". The following appears on the diagram, showing where the information for the new cow's pasture choice is coming from:
We need to trigger this new action; drag it onto the pasture diagram and make the resulting trigger a function of the growing and grazing rates:
Edit the trigger and set it to invoke the action in any time step where the growing rate is more than 10% larger than the grazing rate:
We have now set in place actions that remove and add cows, and triggers to invoke them in pastures where grass is scarce or plentiful, respectively.
|
No need to change anything here from Exercise 6, unless you prefer to disable the two Thistle Hill cows from the Many Pastures built-in data set under Input 1.
|
Let's do a little cleanup of Run Control from Exercise 6 before proceeding: delete the second row.
And we should be set. Run the model!
|
Examining plots of count from the cow[pasture] collection inspector and Grass Height from the Pasture entity,
we see that Pasteurized Pastures gained a cow immediately and then all pastures were able to sustain 2, 3 or 4 cows, though that wouldn't last long term since all grass heights were declining. Green Gables declined fastest, starting with 4 cows, and around day 40 those cows found themselves below their threshold and expired, leaving the grass in Green Gables pasture to recover in peace.
In this exercise, we looked at how to use Create and Delete actions to add and remove entities conditionally from the simulation. Create and Delete actions can also do what command actions can do, moving things among stocks and changing attribute values. Thus with actions it is possible to conditionally execute rather complicated transactions among entities, even at the moment they enter or leave the simulation.
|