question

One of our initial ideas was to add a realtime button that set the speed to the factor of model units that gives you 1 sim second / 1 real second.

The trouble with that idea comes when you want to then slightly adjust the slider to go faster or slower than real time. In a model with large model units, the value is very small and the slider then only has a few pixels of precision near the values you are trying to adjust.

So instead, we adjusted the calculation of the speed to always be based on simulation seconds per real second, so that you have more control over the speed near realtime. 1.0 always means real time.

Based on this discussion, it sounds like we should add a checkbox to model settings so that you can change it back to scaling on model units per real second. That way, if you are building a model in hours or days where seconds and realtime aren't important, it is easier to get more precision around your model units per real second speed instead of realtime speed.

@phil.bobo

I have had issues with this as well. In the past the slider was always model units per second and now it is not. I understand that this is helpful for some models that use larger time units but still are simulating a shorter time period and want to see things move in real time. For models that have very slow movements, events with long time periods, or long run times this really created a problem as it removed the ability to have any fine adjustment with the slider. I do understand why it was changed but there is also a very good argument for why it was the way it was for so long. I think a win-win would be to implement an option that would change it back, it could be placed in the model settings so that it would only need to be a change made once per model.

I don't know is this was the first person to complain about the problem or not but I do know that it wasn't the first person to have this problem. I think that some of this discrepancy is due to the reception that many of these complaints get. I know that it is easy to get defensive of positions that have been hammered out (sometimes enthusiastically) on the development side of things. But it is important that we don't get dismissive of complaints from people that weren't there for the initial debate. Even if we've heard their side of things before, we should remember that weren't in on that conversation and may have something new to add that wasn't considered yet.

After reading @Serge A thread, I understand his point but, in my view, when you set the model units to some order, let's say days, that means both that your process tasks' and operations' durations are mostly of that order and that you want time to advance faster that normal, so you no longer care about events that last seconds or minutes.

In his case, he had to set his model units to minutes for purposes that actually don't concern the model functioning itself, but the client's information. Therefore, I think that this fact turns out to be some kind of misconception from the modelling perspective, since it's a workaround to facilitate other issue which is external to the model. To my mind, the right methodology would be to convert those data to the proper units managed by the model.

In addition, in a more general sense, by defining the speed value as the ratio between simulated time and real time, we are actually putting the spotlight on ourselves rather than on the model, what is what should rule here. And of course, if your model units have been set to minutes, it's not counter-intuitive thinking that 1 minute in the model corresponds to one second in the reality.

Overall, since I also understand that in the Serge's case, setting the ratio in the traditional way may mean a laborious work of converting data units, I guess the best option would be letting the user decide by herself by some kind of checkbox that switches it (I know that also means some coding matters...)

It will be nice to have an option to get back the previous behaviour. Currently if the model built are in units other than seconds, we often need to change the Run Speed every time we run the model (like in HealthCare model). This is worse when the model units are in hours, which just mean every time we run the model the Run Speed has to be changed.

@phil.bobo Not sure if my trouble ticket from few months ago on similar experience matches this one or not but our model created in 19,2 version with model time units set to seconds and is a long running model (in terms of simulated days being a whole calendar year of 365 days), suddenly started to crawl when we upgraded to 20.0 version. Nothing was modified in the base model during or after upgrade. So we abandoned this move and reverted back to running in 19.2 which was giving us much quicker model completion times.