Using statistical distributions in "values by case"

Question

question

Joel SL asked May 24, '17 Joel SL commented Jun 1, '17

Using statistical distributions in "values by case"

Hi everyone,

if I try to enter a statistical distribution as a value for the "values by case"-function on the process times of a combiner, it gives me the following exception:

time: 4627.752464 exception: Exception Caught in FixedResource::getItemInfo(treenode flowitem)

time: 4627.752464 exception: Exception Caught in FixedResource::setItemState(treenode flowitem, int state)

time: 4627.752464 exception: Exception Caught in FixedResource::releaseItem(treenode item) object: /Montageinsel1

time: 4627.752464 exception: Exception Caught in Combiner::onTimerEvent(treenode involved, int code, char *datastr) object: /Montageinsel1

time: 4627.752464 exception: Exception Caught in ObjectFunction251__project_library_FlexSimObject_behaviour_eventfunctions_OnTimerEvent object: /Montageinsel1 class: /Montageinsel1

time: 4627.752464 exception: Exception caught in TreeNode::receivemessage()

time: 4627.752464 exception: Exception caught in Executive::processeventinlist(). Throwing.

time: 4627.752464 exception: Exception caught in Executive::steptotime(). Throwing.

time: 4627.752464 exception: Exception caught in Executive::tick(). Throwing.

time: 4627.752464 exception: int runthemessageloop() #4

exception: Executive::instance.tick();

time: 4627.752464 exception: int runthemessageloop() #6

It doesn't occur every time, but definetely depends on whether I'm using the statistical distribution or just type in an integer. Isn't it allowed to use statistical distributions there or am I doing it the wrong way?

Best regards

Software Version:

FlexSim 17.1.0

values by case statistical distributions

· 4

5 |100000

Attachments: Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Steven Hamoen commented · May 24, 2017 at 03:22 PM

@Joel SL Could you please share the code you are entering?

0 ·

Joel SL Steven Hamoen commented · May 29, 2017 at 08:22 AM

Sure, the code for the processing times on the combiner is as follows:

Object current = ownerobject(c);

Object item = param(1);


　

int case_val = item.type;


switch (case_val) {


	case 1: return 409;

	case 2: return 467;

	case 3: return 542;

	case 4: return 449;

	case 5: return 485;

	case 99: return exponential(1025, 10.0, 0); 

	default: return 1;

}


return 0;

0 ·

Sam Stubbs ♦ Joel SL commented · May 30, 2017 at 02:09 PM

It could be that your statistical distribution is returning negative numbers, which could be causing problems. If you nest the distribution in a maxof(distribution,minimumNum) command, and make sure the minimumNum is 0 or greater, does that fix the error? Otherwise we may need to see the model itself.

0 ·

Show more comments

Answer 1 · 2017-05-31T23:02:05Z

Matt Long answered May 31, '17 Joel SL commented Jun 1, '17

Your exceptions have nothing to do with your distributions. Well, not directly. If you run to time 12900 and run slowly, you'll see that the flow item in Montageinsel3 gets picked up by Operator3. But the combiner isn't supposed to finish processing the item until 12945. The exception is thrown because the combiner is expecting the item it was processing to still be there.

The issue is that the combiner is treating each flow item that enters it as a flow item it needs to process, including the container flow item. Unfortunately this is due to the default logic of how the combiner works. Without any objects connected to the combiner, when items enter it, they are processed. So the first item enters and starts a processing time, then the second one enters and also starts a processing time. The second item is packed into the first and when the first processing finishes, the operator removes it from the combiner. Later, the second processing finishes, but no items are in the combiner.

The fix is kind of a hack. We should look into getting this fixed so it just works. But all you need to do is create a dummy queue and then connect it to all of your combiner objects twice. So each combiner will now have two input ports. Do this will all 8 combiners.

I didn't test this, but it is possible that using the Custom Task activity and defining the ports that the items enter the combiner may fix the issue as well. Containers should go through port 1 and all other items should go through a port > 1.

· 1

5 |100000

Attachments: Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Joel SL commented · Jun 01, 2017 at 08:23 AM

Ok, that makes sense. I chose the solution with the queue and it works like a charme. Maybe I'm going to test your other solution later on. Thanks a lot for your help,I appreciate it!

0 ·

question