Level input

[thrillz84]

Dear admin,
Am not very familiar yet with the software so bare with me. I run this simulation and I expect the output at time step 1 to be seen across all the variables in the model. However, I notice that each succeeding level in my model introduces a delay of time step 1 before the value from he previous level is fed into it. e.g in time step 1, "to do"= 20 and "done" remains 0 until time step 2 when it has a value of 12. ideally, the value 12 would be given to "done" in time step 1.Please what am I doing wrong?

[Administrator]

You are doing nothing wrong.

Think of how things would work in real life. If you had the level reacting immediately, then as soon as you make a decision, it is actioned. In real life there is always a delay even if it is a very small one.

In your model, "to do"= 20 at t=1, but if there was no delay, "done" would also be 20 at t=1. So which is correct, "to do" = 20 or "done" = 20?

I hope this makes sense.

PS. It is also a really good idea to put units in your model.

[tomfid]

Right. Things that respond instantaneously are not levels.

You might try working through something like the roadmaps series if this doesn't make sense.
http://clexchange.org/curriculum/roadmaps.asp

[thrillz84]

thanks for the reply, I get your point. SO does that mean that there is always a 1 timestep delay between interlinking levels? I am basically trying to collate results for when input "to do" produces output "release candidates" iteratively - and found it odd the input at time 1 will be the corresponding output "release candidates" at time 4!, meaning the output doesn't have any value till time 4; this doesn't potray the real life output of the scenario of my use. Thanks

[tomfid]

It seems that what you're implying is that all of the steps can be completed in zero time, in which case it's not clear conceptually why you need any stocks.

The missing component of this model is the time required to complete each step. For example, you have

Code: Select all

automated acceptance testing rate=
	integrated tasks
Units: tasks/iteration

integrated tasks is a stock and automated acceptance testing rate is a flow, so these should have units of tasks and tasks/time, respectively. As written, your equation is dimensionally inconsistent - it would have to be something like testing rate = integrated tasks/time to test to be correct. It seems that you are handling this more like a flow diagram, where multiple stages happen within an iteration, so the SD paradigm isn't really helping you.

One way to handle this would be to use rate-to-rate connections, which are theoretically taboo, but sometimes useful for capturing behavior below TIME STEP resolution. For example, you could write,

Code: Select all

automated acceptance testing rate=
	integrated tasks/time to integrate+actual rate of commit
Units: tasks/iteration

time to integrate = TIME STEP = 1
Units: iteration

Here, testing handles tasks as fast as they are committed if possible, plus in addition handling any contents of integrated tasks immediately. The units of time corresponding with this would be iteration, so all your stocks would have task units and all your flows have tasks/iteration units.

Defining and balancing units really does help avoid problems.

[thrillz84]

I get it well,thanks