Well, I understand how DEV models work but I have no clue as to the following...

a) which models in the library can even be changed into DEV?? None of them seem remotely applicable to breaking down by events.

b) What is the purpose of doing this? It seems as though if we were going to create a new model we would make the choice to make it DEV or not. If we are taking something that already works efficiently without DEV what is the point of reducing its functionality to a DEV model? 

Instead of making one of the models from the library can we just design a new DEV model? For example I was thinking of making a factory line model that keeps track of inventory as product is being made. 

cpham24 wrote:

So... this is from my understanding:

1. DEV specifies that models that have agents that can interact with the environment without interacting with each other (key point) can potentially be broken down into discrete events. So... I'd say look for models like those. For instance, the "Forest Fire" model is a pretty good example: you start out with a bunch of trees (environment) and then you ignite all of the trees on the left-most side using "fires" (the agents). Each of the fire(s) agent spreads by looking at the environment, and they don't interact with each other (meaning... how one spreads does not have an influence on another -> how they propagate is not "procedural" but more "discrete") so therefore, each one is a discrete event. I thought about using this one for my model as well, but I'll go with the "Percolation" (oil) model instead. <- so please don't choose that one! :) They're pretty similar though...

2. I guess practice makes perfect? I think Dr. Abbott would be able to answer this question better than I can.

But for the model he gave us in class it was just one event being added to the queue at a time... Wouldn't all of these individual fire agents in the example you are giving me have to execute their events at the same time?? Wouldn't each event in this case just be the same as a tick?

It's a bit late to start talking about this, but with the forest-fire model consider a burning tree igniting a neighboring tree.    There is a distribution that expresses the time it takes for a tree to go from initial ignition to enflamed enough to ignite a neighbor and a distribution that expresses the time that it takes a neighboring tree to ignite given a fully enflamed neighbor. Times drawn from each of those distributions can be scheduled on the event queue. 

(This doesn't get to the point of the model, which is that the density of the trees matter. But you don't need either model to tell whether the fire will reach the other side. It's a matter of whether there is a green path from left to right. The model as written does a parallel search for such paths. But that's another issue.)

The model as written effectively schedules every event one time unit in the future. To make it a bit more realistic, you might define the heating influence of one tree on another be a function of distance between the trees.  (So trees can affect more than their neighbor4 neighbors.)   Schedule an event for a tree that indicates when it is hot enough (after initially igniting) to affect other trees. When that event occurs, add the effect of that tree's heat to the neighbors that it affects. If a tree has enough close burning neighbors to pass a threshold, schedule it to catch fire. Also schedule a tree to stop projecting heat after a certain (probabilistic) time. In other words, don't make things happen just because a tick occurred as in the current model.