Unrealistic Rates for Realistic Level Behavior

[Monte]

Dear Administrator,

How to create the behavior of Task Force level as shown in Att.?

Dynamic hypothesis:
All people arrive the base at the same time, say an army of 200 troops, so they should have no delay startup behavior.

Regards,
MT

[Administrator]

Will PULSE do what you want?
http://www.vensim.com/documentation/ind ... _pulse.htm

You've drawn some "Vensim behaviour". If you upload the model we can take a look. Vensim will only behave like that unless the model is designed to ramp up.

[Monte]

Thank you. I will attach the file soon as I cannot access the Internet via PC for a while.
But let me give you the equation and desired level behavior images:

I can produce more reasonable level behavior, but must set a very high value of the rate.

Indeed, the level doesn't reach 200. Integration error? I use the lowest TIME STEP, and the minimum constant is 1/30 month (1 day).

[Monte]

This is the rate behavior, which is very high. I want to make sure that the 1 day run (around 4 TIME STEPS) can formulate 200 men of army force. Not quite successful. It seems unrealistic.

[Monte]

Done. I found the cause of the problem and solution.
Vensim use 4 steps to represent 1 day in month, a bit less than 1/30 month, which causes the error.

[Monte]

Now I got the behavior I want. Thanks.
(I did a lot of mental simulations before getting this result)

[Monte]

The question is...Have you ever seen an unrealistic rate behavior used
for generating a reasonable level behavior like this?
Is it a good modeling practice?

In my opinion, if the rates are not used elsewhere in the model, this practice might be okay.

[Administrator]

I don't understand what you are asking.

I would say that the "formulation" parameter is too complex, it's impossible to work out what is actually happening in it.

[Monte]

Thank you for your answer. I am going to split and simplify the rate equation, to find a new structure with real world equivalents. The original equation is somewhat analytical and hard to explain clearly as you pointed out.

[Monte]

I have revised the rate equation as attached. The task force is formed quickly after they are ordered (one time step).
I extract the PULSE function out, to be a new variable called Task Force Formation Policy. The rate represents the policy to start a task force formation and the target task force. These equations are less sensitive to TIME STEP than the previous versions. What did you think?

[tomfid]

When you want an effectively instantaneous event, the magnitude of the rate needed to accomplish a given change in a level varies with the TIME STEP. You can see why by looking at the Euler step for a level:

level(t) = level(t-dt) + rate*dt

As dt gets smaller, the rate has to get bigger to compensate. That's why it's common to write something like:

inflow rate = inflow volume * PULSE( when, TIME STEP ) / TIME STEP ~ widgets/week
inflow volume = ... ~ widgets

If this causes problems downstream with some variable that uses the rate, then there's probably a logical problem, because it's surely the average rate, smoothed over some perception time, that really matters.

[Monte]

Dear Tom,

Thank you very much for your time and effort.
The rate is not used elsewhere in the model,
but I feel unhappy when seeing the unrealistic behavior (necessarily high rate) in my model
although it already serves the model purpose.

Best regards,
MK

[tomfid]

I wouldn't call it "unrealistic" - if the event really is discrete, then the flow is (asymptotically) infinite. It does look weird though, and can be tricky for an unfamiliar viewer to interpret.

An alternative would be to spread the event out over some duration > TIME STEP:

inflow rate = inflow volume * PULSE( when, duration ) / duration ~ widgets/week
inflow volume = ... ~ widgets
duration = ... ~ weeks

However, that may introduce a different problem: the stock will ramp up somewhat gradually, and the delta from the initial to final level may be a little less than the total inflow volume, due to dynamics that happen in the interim (e.g., an outflow).

[Monte]

Thank you so much.
I am reluctant to extend the duration greater than DT, i.e. DT + days.
Vensim doesn't treat 1 day as 1/30 month. I don't know the logic behind that.
A week would be much longer than the real event's delay.
The outflow is of DELAY FIXED.

I will study from your suggestion.
Thanks again.

[tomfid]

Time in Vensim is essentially abstract, so the day/month treatment is a modeler choice. A time step of 1/30 (or 1/30/4) months could pose problems with roundoff error - my guess is that's why the modeler chose 1/32/4. Not sure why they didn't just use a time unit of days with a time step of .25 - that would greatly mitigate the apparent flow amplification in the pulse.

[Monte]

The 1/(2*2*2*2*2*2*2) tine step is exactly used in my model, and the smallest time step offered by Vensim. To change the model unit from Month to Day, and use the 0.25 Time Step would be the only choice to avoid the error although the senior officer and model users may be more familiar with Monthly report.

Thank you so much for your in-depth analysis. Very helpful.

[tomfid]

I think that's the limit of the menu, but you should be able to enter a smaller value via the equation editor if desired.

[Monte]

Thank you.