Token in pull activity not released after condition met with SELECT quantifier

Question

question

David Besson asked May 26, '20 Jordan Johnson commented May 28, '20

Token in pull activity not released after condition met with SELECT quantifier

Dear all,

I do not understand why at time 206765, the token in the pull activity is not released although it pulled the required quantity according to the SELECT quantifier (option enabled in the list general properties).

Could you help me figure out the cause please ?

Thanks in advance,

David

20200526_selectNotWorking_4.fsm

Software Version:

FlexSim 20.1.2

flexsim 20.1.2 pull from list

capture.png (16.7 KiB)

20200526-selectnotworking-4.fsm (29.3 KiB)

Answer 1 · 2020-05-27T19:56:09Z

Jordan Johnson answered May 27, '20 Jordan Johnson commented May 28, '20

This is a precision issue, which is likely a bug in our code. If you put your model precision up to 20, you can see the following:

See how the fulfilled value is less than the required value.

To see how this can happen, I took the first pullQantity from the Scheduled source, and ran the following code:

double blah = 0.04133656669932109229;
return string.fromNum(blah);
// returns 0.0413365666993211, not the same as the input

In order to work around this, I would use an acceptable error range around my request and require numbers. If you set up a global variable called epsilon, with a tiny value like 1e-9, you could use that to guard your request and require numbers, to account for precision issues:

selectworking-withepsilon.fsm

1590608271150.png (5.0 KiB)

1590609335238.png (9.1 KiB)

selectworking-withepsilon.fsm (29.7 KiB)

· 2

David Besson commented · May 28, 2020 at 05:53 AM

Thanks @Jordan Johnson!

For information, I tried to do it in a similar way, by rounding off the pulled quantities in my source to a sufficient precision for my purpose (ie 3).

But unfortunately it seems the rounded values are not exactly the values I expected: Here are the rounded values, showed with a precision 20:

Is it an expected behavior?

0 ·

capture.png (2.4 KiB)

Jordan Johnson ♦♦ David Besson commented · May 28, 2020 at 03:56 PM

Yes, that seems expected. To zero out those last digits, you need to round, but to a value that is exactly representable in binary. You could use code like this:

double divisor = 1 / 131072.0;
double count = Math.floor(0.04133656669932109229 / divisor);
double rounded = count * divisor;
return string.fromNum(rounded, 20); //0.04133605957031250000

As long as the divisor is equal to 1 / 2^n, you will get values that you maybe expect.

0 ·

Answer 2 · 2020-05-26T22:12:22Z

Benjamin W2 answered May 26, '20 David Besson edited May 27, '20

It looks like the SELECT quantifier is only evaluating when the token enters the "Pull From List" activity. One work around would be to use the Max Wait Timer on the pull from list, then send the token to a "Wait for Event" which listens to the "On Entry" of the "Push to List".

@Jordan Johnson, @phil.bobo, please chime in if there is a better way.

20200526-selectnotworking-4.fsm

1590531076158.png (112.1 KiB)

20200526-selectnotworking-4.fsm (32.3 KiB)

· 1

David Besson commented · May 27, 2020 at 11:04 AM

Thanks for your answer.

The behavior seems inconsistent:

The situation at time 97745 is exactly the same as at time 206765.

But at time 97745, the token in the pull activity is released as expected when a new token is pushed on the list.

1 ·

question