Breakdown Repeatability Error

Question

question

Leo L6 asked Aug 7, '23 Jason Lightfoot commented Aug 10, '23

Breakdown Repeatability Error

Hi,

There is a station in my model which doesn't break down the same amount of time on the same replication #. For example in replication 1, the station breaks down 0.88% in the state bar chart, but on the same replication for a different unrelated parameter value (flow item count), the station breaks down 0.46%. This doesn't seem logical since flow item count shouldn't effect station breakdown % and my understanding is that the random stream is identical per replication and so breakdown % should be the same. Also, this error only happens for one station in the model (Station 2).

Replication 1 with item count = 10

Replication 1 flow item count = 12

As shown for station 2 the breakdown % values are substantially different

Here is the model file: FlexSimMTTRError2.fsm

Thanks in advance

Software Version:

FlexSim 22.0.16

mtbf mttr breakdown random streams

1691446399600.png (28.5 KiB)

1691446574695.png (26.3 KiB)

flexsimmttrerror2.fsm (318.3 KiB)

· 2

Jason Lightfoot ♦ commented · Aug 07, 2023 at 11:21 PM

Yes - there's something wrong with the stream initialization for the first scenario with item count of 10 - all subsequent scenarios follow the same sampling sequence, as you'd expect.

0 ·

Leo L6 Jason Lightfoot ♦ commented · Aug 08, 2023 at 04:06 PM

But item count scenarios of 12 and 14 also have different breakdown % values. It's only scenarios 16, 18 and 20 where it seems to converge.

0 ·

Answer 1 · 2023-08-09T16:53:24Z

Jason Lightfoot answered Aug 9, '23 Jason Lightfoot commented Aug 10, '23

Yes - you're sampling from the same stream in the OnArrival trigger of the station so the more arrivals you have will affect the sampling sequence. If you change involved to current in the MTBF/MTTR it will fix this - but of course then the addition/removal of machines to the MTBF/MTTR will affect the sampling. If your model has a fixed number of machine/stations then it won't matter.

I've sent in a suggestion to have getstream accept a variant so that the expression for the stream used in MTBF/MTTR samples could be something like

getstream([current,involved])

which will solve this an many other cases like those of instanced activities where the stream can then be

getstream([current,activity])

· 1

Jason Lightfoot ♦ commented · Aug 10, 2023 at 11:39 AM

Attached is a version of your model with a user command to override getstream() such that it accepts variants as the stream 'key', as I described above. The user command code is just:

/**Custom Code*/
var key=param(1);
Map streamMap;
treenode mapnode=c.subnodes.assert("streamMap",streamMap);
streamMap=mapnode.value;
int result=streamMap[key];
if (result==0){
    result=streamMap.keys.length;
    streamMap[key]=result;
    mapnode.value=streamMap.clone();
}
return result;

flexsimmttrerror2-jl2_getstream_override.fsm

1 ·

flexsimmttrerror2-jl2-getstream-override.fsm (266.7 KiB)

question