Hi Dear
Hello!
I have a few basic questions relating to rate and level variable. One of expert comment that rate can not determine another rate. Is it true? Then what is the precondition or how many ways we can form rate variable towards level variable?
for level variable, should it be necessary to put drain out? or can I put it without drain out rate to see total integration?
If I take so many link from level towards other variable, does it mean one outgoing variable is evacuating the values it belong to? Say, one level has 100 unit. Three connector goes to three different variable. If one take 20, doe it mean level contain 80 now, or it will be the same whatever picked by a variable?
Last but not least, Still I do not know the technique of understanding whether flow start before time for a variable? how do I know that figures are trying to flow before simulation starts?
Thanks
Condition of forming rate and level variable
Condition of forming rate and level variable
M Shamsuddoha
Curtin University, Australia
Curtin University, Australia
Re: Condition of forming rate and level variable
Hi Doha
Technically you can do anything, as long as it works. But it is too better to build models that are easy to understand.
I avoid making a rate depond on another tate, because you have then a rate that has two functions. One is to be integrated in a level and a second to influence another rate.
If you need it absolutely, there is a high risk of a flaw in your logic.
I prefer to use a flow for input and another for the output. But if there are many different flows for the same level, it maybe better to put together the inflow and the outflow into one single flow.
The rule for me is ease of reading and understanding the model. As :ong as you respect this rule, you can do anything that works technically.
Regards.
JJ
Technically you can do anything, as long as it works. But it is too better to build models that are easy to understand.
I avoid making a rate depond on another tate, because you have then a rate that has two functions. One is to be integrated in a level and a second to influence another rate.
If you need it absolutely, there is a high risk of a flaw in your logic.
I prefer to use a flow for input and another for the output. But if there are many different flows for the same level, it maybe better to put together the inflow and the outflow into one single flow.
The rule for me is ease of reading and understanding the model. As :ong as you respect this rule, you can do anything that works technically.
Regards.
JJ
Re: Condition of forming rate and level variable
Hi JJ
Thanks for your reply.
Regarding you comment " But if there are many different flows for the same level, it maybe better to put together the inflow and the outflow into one single flow", I would like to know little more.
Say, A parent chicken is giving 4 eggs in a week. Parent Chicken is a level followed by Eggs and Hatchery Level. They are interconnected by rate. Now, Parent chickens have normal death, disease caused death, culled due to unproductive, culled due to aged. So, there are four different reasons of get outflow. The most important outflow is Eggs as next level is eggs. In this situation, how would you like to handle the model?
Thanks
Thanks for your reply.
Regarding you comment " But if there are many different flows for the same level, it maybe better to put together the inflow and the outflow into one single flow", I would like to know little more.
Say, A parent chicken is giving 4 eggs in a week. Parent Chicken is a level followed by Eggs and Hatchery Level. They are interconnected by rate. Now, Parent chickens have normal death, disease caused death, culled due to unproductive, culled due to aged. So, there are four different reasons of get outflow. The most important outflow is Eggs as next level is eggs. In this situation, how would you like to handle the model?
Thanks
LAUJJL wrote:Hi Doha
Technically you can do anything, as long as it works. But it is too better to build models that are easy to understand.
I avoid making a rate depond on another tate, because you have then a rate that has two functions. One is to be integrated in a level and a second to influence another rate.
If you need it absolutely, there is a high risk of a flaw in your logic.
I prefer to use a flow for input and another for the output. But if there are many different flows for the same level, it maybe better to put together the inflow and the outflow into one single flow.
The rule for me is ease of reading and understanding the model. As :ong as you respect this rule, you can do anything that works technically.
Regards.
JJ
M Shamsuddoha
Curtin University, Australia
Curtin University, Australia
Re: Condition of forming rate and level variable
Looking at parent chickens, you might write:
where maturing, age culling, etc. are inflows and outflows. This would appear on the diagram as a separate flow pipe for each process.
If that gets too complicated, you could write,
or
where maturing, net loss rate and net change in chickens are flows, but culling and other losses are auxiliaries that are summed in a summary flow.
Code: Select all
parent chickens = INTEG( maturing - age culling - disease death rate - productivity culling, initial chickens)
If that gets too complicated, you could write,
Code: Select all
parent chickens = INTEG( maturing - net loss rate, initial chickens) ~ chickens
net loss rate = age culling + disease death rate + productivity culling, initial chickens) ~ chickens/week
Code: Select all
parent chickens = INTEG( net change in chickens, initial chickens) ~ chickens
net change in chickens = maturing - age culling - disease death rate - productivity culling ~ chickens/week
/*
Advice to posters (it really helps us to help you)
http://www.ventanasystems.co.uk/forum/v ... f=2&t=4391
Blog: http://blog.metasd.com
Model library: http://models.metasd.com
Bookmarks: http://delicious.com/tomfid/SystemDynamics
*/
Advice to posters (it really helps us to help you)
http://www.ventanasystems.co.uk/forum/v ... f=2&t=4391
Blog: http://blog.metasd.com
Model library: http://models.metasd.com
Bookmarks: http://delicious.com/tomfid/SystemDynamics
*/
Re: Condition of forming rate and level variable
However, eggs are not an outflow from the stock of chickens (though of course, in a literal sense, eggs do flow out from chickens). This is because laying of eggs does not reduce the stock of chickens (at least if chickens are measured numerically).
Normally, you'd have a stock of parent chickens, with whatever processes increase/decrease their measure. The flow of eggs is influenced by the parent chicken stock, but is not an outflow from the stock - it's part of a separate stock/flow chain, denominated in eggs rather than chickens.
If you want to get very operational, you might model in vitro eggs that are still within chickens. In that case, culling removes not only chickens, but eggs, which might justify a rate-to-rate connection.
The primary reason for avoiding rate to rate connections is to avoid representing a situation in which decisions are made with knowledge that's not actually available. For example, the rate of shipping items to a store can't literally depend on the rate of sales in the store, because the sales rate is noisy and inevitably involves some integration (smoothing) in measurement.
Normally, you'd have a stock of parent chickens, with whatever processes increase/decrease their measure. The flow of eggs is influenced by the parent chicken stock, but is not an outflow from the stock - it's part of a separate stock/flow chain, denominated in eggs rather than chickens.
If you want to get very operational, you might model in vitro eggs that are still within chickens. In that case, culling removes not only chickens, but eggs, which might justify a rate-to-rate connection.
The primary reason for avoiding rate to rate connections is to avoid representing a situation in which decisions are made with knowledge that's not actually available. For example, the rate of shipping items to a store can't literally depend on the rate of sales in the store, because the sales rate is noisy and inevitably involves some integration (smoothing) in measurement.
/*
Advice to posters (it really helps us to help you)
http://www.ventanasystems.co.uk/forum/v ... f=2&t=4391
Blog: http://blog.metasd.com
Model library: http://models.metasd.com
Bookmarks: http://delicious.com/tomfid/SystemDynamics
*/
Advice to posters (it really helps us to help you)
http://www.ventanasystems.co.uk/forum/v ... f=2&t=4391
Blog: http://blog.metasd.com
Model library: http://models.metasd.com
Bookmarks: http://delicious.com/tomfid/SystemDynamics
*/