Today I wanted to start constructing an Entry component. I created a very simple on that generates modeled entities are regular, defined intervals over the duration of the simulation run. Here’s the relevant code.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
//time to end the entire simulation var endSimTime = 1440.0; //time increments in minutes, run for 24 hours //collection of all entities in the system var setOfEntities = new Array(); //Entry component function entryComponent(arrivalsPerHour) { //initially assume it just generates entity1s that disappear after a single cycle this.entityID = getNewID(); this.initialTime = 0.0; this.incrementTime = 60.0 / arrivalsPerHour; this.endTime = endSimTime; this.nextState = "increment"; feq.newItem(globalSimClock,this); //assume all components created at time zero this.generateNewEntity = function() { var newEntity = new entity1(globalSimClock,2.0,globalSimClock+1.0); setOfEntities.push(newEntity); } this.activate = function() { if (this.nextState == "increment") { this.generateNewEntity(); //<<<< this one line does all the meaningful work <<<< displayProgressText("Entry component "+this.entityID+" generates new entity at time "+globalSimClock+"<br />"); if (globalSimClock + this.incrementTime >= this.endTime) { this.nextState = "destroy"; } advance(this.incrementTime); } else if (this.nextState == "destroy") { displayProgressText("Entry component "+this.entityID+" terminated at time "+globalSimClock+"<br />"); } else { alert("Entry component "+this.entityID+" went into undefined state"); displayProgressText("entity "+this.entityID+" in undefined state at time "+globalSimClock+"<br />"); } } }; //entryComponent var entry1 = new entryComponent(2.0); |
This generates the following output.
1440.000000 minutes
entity 2 created at time 0
Entry component 1 generates new entity at time 0
entity 2 updated at time 0
entity 2 terminated at time 2
entity 3 created at time 30
Entry component 1 generates new entity at time 30
entity 3 updated at time 30
entity 3 terminated at time 32
entity 4 created at time 60
Entry component 1 generates new entity at time 60
entity 4 updated at time 60
entity 4 terminated at time 62
entity 5 created at time 90
Entry component 1 generates new entity at time 90
entity 5 updated at time 90
entity 5 terminated at time 92
...
entity 48 created at time 1380
Entry component 1 generates new entity at time 1380
entity 48 updated at time 1380
entity 48 terminated at time 1382
entity 49 created at time 1410
Entry component 1 generates new entity at time 1410
entity 49 updated at time 1410
entity 49 terminated at time 1412
We didn’t have to add the newly created entities to the setOfEntities array, since in theory they should all be actively processed using the relevant discrete-event methods. However, there are times when it’s necessary to access groups of elements that share some characteristic. They could be in a given state, in a given location, awaiting a given condition, or be of a certain type. Having an external handle for groups of items allows common types of processing, including set operations. The SLX language, which inspired this project, implemented set containers and operations for these purposes.
We could also probably have set the entities to move forward in time right from when they were created, rather than having them be processed once at zero seconds after creation and again at two seconds after. That would have made this process a little cleaner.
You may notice that this code looks very much like that for the entity objects themselves, and there’s a reason for that. Any element that does anything (and in this example we’re putting intelligence into both the entities processed by the system and the components used to do the processing) will require the same discrete-event mechanics. This means that processing will stop and wait to continue after a defined period of time has elapsed or a defined condition has been met. The question is about the specific behaviors to implement.
In this case we’re creating entities that exist for a moment and then extinguish themselves. This isn’t very interesting, but the goal here is simply to create entities. We’ve created a really mindless way of doing this, but let’s think of some that are more interesting. Here are some ideas.
A schedule could be created which governs the creation of entities. It would have to incorporate information about time periods, entity characteristics, and so on. All of the entities could be created at the beginning of the simulation and be activated on their individual arrival times. The Entry component could create a separate event loop (using a separate puck), that generates the entities for the next scheduled period. Assuming that a schedule defines arrivals by half-hour block, one loop could run every half hour while another loop generates the arriving entities during the course of that half-hour. It may also be possible to just generate all the arriving entities on the half-hour, but have them wait to activate at different times over that interval. Care would have to be taken to ensure that display and record-keeping for the new arrivals only begins when it logically should.
As I’ve discussed previously, an element can have a number of things going on at any given time. It could simultaneously be waiting for time to elapse, a condition to be met, or be affected by some outside process based on its state, location, or group membership. As long as the code keeps everything straight the sky’s the limit.
To that end I’m thinking that the activation mechanism I’ve been using could stand a little clarification and standardization, if possible. The relevant bits of code tend to get lost when buried in the series of cascading if statements, so it might be a good idea to modularize this somehow. If that structure could be standardized and externalized it could make the objects’ code much clearer. It may also allow us to hide the flag for going into an unidentified state. What we’d want is to be able to declare the various activities as methods within each object, each of which is triggered by a certain state identifier, while ensuring that each object defines a new state (unless the object is to be extinguished). There would have to be a way to associate an element’s states with its method calls in an external function or object (method). I think that will be tomorrow’s project, and when that’s done we can return to implementing more interesting ways to have an Entry component generate entities.