MikeKk

Have a look at using selection weights on links, use an expression that checks if "ModelEntity.Priority" (or the state you save priority to) matches the destination of the link.

The Facility view of the model has a random seed number which you can change from the Run Tab, under Advanced Options>Randomness>Replication Number. This number corresponds to a scenario's replication number in the experimenter. If you export the "Details" csv From the response results tab of the experiment you can inspect each replications returned value for any of your responses As long as no changes have been made to the model, and the properties from the scenario are input identically, using this replication number, you should be able to have have the facility view of the model return the same value as the experiment allowing you to inspect particular experiment runs in the 3D view.

If you want to model nurses completing tasks of their own volition you should have your nurses seize and move themselves for the duration of their own tasks, this way resource states and capacity utilization by will be handled by Simio. You should take care though when you consider your nurses "Idle" and ready to complete their own tasks. Having them seize themselves effectively removes them from the available nurses for the duration of their own tasks, and if new urgent tasks arrive during this time, they will be ignored until nurses have finished their tasks.

Hi, The execute step you use to run your car's acceleration increment process is not a "continue" process so the token that enters the execute step in the "EntryRoundaboutOrStop" process waits for the executed process to complete (ie. your acceleration to reach its maximum) before continuing. Because this is done on the "OnEntered" it causes your vehicle to wait at the node for all the processes run by the OnEntered add-on process to complete. This differs from using the "OnExited" add-on process which doesn't wait for it's processes to complete (due to the literal departure from the node onto a path/station being required to execute the "OnExited" add on process). I suspect having used the OnExited instead of the OnEntered in your previous model is what caused the acceleration to work properly. I hope this helps. Michael

Hi, See if you can replicate it in an empty model and link it here. Without seeing the problem first hand, I think your issue may be .DesiredSpeed, which is more like the speed the entities "want" to be going if they aren't limited by paths/nodes or blocked by other entities. The actual movement rate state the entity is using is Entity.Movement.Rate which as a state you can alter during a run, as long as the entity isn't blocked/waiting/seizing/in a station/etc.

There may be a few different issues going on here- Firstly Ensure you have input and output buffers, there is occasionally some issues with removing buffers from combiners. Secondly you weren't very clear on what you use your Random.Uniform(1, 4) on. If this is how your calculating your priority on each entity, the issue may be that this distribution is returning real numbers (as opposed to integers) and the decimals differences invalidate your matching condition on your combiner. You may want to Math. Floor, Math.Ceiling, Math.Round this distribution to ensure it gives you whole numbers. Your best bet may be to build a simple model explaining what your trying to accomplish and post it here.

How would you want it logged? The easiest would probably to write to a csv file would be by placing a write step on the process executed by the timer's event. The second issue is what would you be logging a x, y, z coordinate, a link name? a station? There would be issues with each of them, being comprehensive may require a quite detailed log.

Information on entities are read-in in batches of 300 after an initial read in of 600 from csv file when the queue within the model falls to a certain amount (150) to lower the number of simultaneous read-in cycles. The rate at which this Queue depopulates is a key property in the model though and may vary greatly, as is the order in which they are processed. There are several of searches of this entity queue. Searching for both match criteria and ordering by search expression. These searches are conducted frequently but are offset by small periods to prevent them from occurring simultaneously. Searches that fail to find appropriate candidates wait for queue entered events (which are also offset after the triggering event) before re-searching the queue. A large queue is necessary as matching criteria may vary and without a large population within the model many searches will return without results.

Hi, I'm currently building a model which involves a very large queue of entities to be read into the model and dynamically searched. I've attempted to limit the number in the model through different techniques such as reading in only relevant entities in at one time (from csv), Limiting the search ranges to distinct queues (as opposed to searching entire entity populations) and offsetting the reading and searching intervals (so they don't fall within the same time-stamps and slow the model). Despite this the model still runs rather slowly and (depending on variability) may still breach the 20,000 entities in system mark. I'm curious to find out how anyone else has handled large numbers of entities in the past? Is there a way to disable this 20k entities in system warning? Are there more efficient ways of generating and searching entities? Any feedback would be great. Michael

Does anyone else get the significant lag as you create and change properties to experiment responses? It makes a simple task of populating an experiment with outputs a significantly longer process and appears to almost crash the model when changes are made. What exactly is going on to cause this to happen?