"Exception caught" error - unable to determine cause

Question

question

Sumanth Raja asked Aug 18, '17 Sumanth Raja commented Aug 24, '17

"Exception caught" error - unable to determine cause

My model (attached) appears to run fine for about 64 days (91377 minutes), at which point it gives me the following error:

time: 91377.046506 exception: Exception caught in TreeNode::receivemessage()
time: 91377.046506 exception: Exception caught in executive::processeventinlist(). Throwing.
time: 91377.046506 exception: Exception caught in executive::steptotime(). Throwing.
time: 91377.046506 exception: Exception caught in executive::tick(). Throwing.
time: 91377.046506 exception: int runthemessageloop() #4
exception: core->theexecutive.tick();
time: 91377.046506 exception: int runthemessageloop() #6

I do not encounter this error any time before, but it occurs quite frequently after this point. I am having difficulty identifying the source of the problem. Any help would be much appreciated. Thank you!

-Sumanth

@jim.montgomery

@lou.keller

@cliff.king

new-admit-protocol-model-8182017.fsm

Software Version:

FlexSim HC 5.1.0

error message exceptions

new-admit-protocol-model-8182017.fsm (141.2 KiB)

Answer 1 · 2017-08-23T18:28:54Z

Cliff King answered Aug 23, '17

Sumanth,

I keep trying to find a couple hours to look into your model in detail (because I'm anticipating it will take me some time to dig in and figure things out enough to build you an example model of how I would approach the model), but I haven't been able to find the time. However, I have read through your excellent description of the specific problem outlined above, and I at least know why your Activity 30 is being triggered to start again. If you take a closer look at the Activity Start Condition for that activity, you'll notice that in the bottom field titled "If the condition is not true, check again in... (use a zero to indicate no recheck)" you have specified to recheck every 30 minutes. If you set it to 0, it will only be check once, and that may solve all (hopefully) your problems! Let me know how it goes!

Answer 2 · 2017-08-23T19:16:31Z

Sumanth Raja answered Aug 23, '17 Sumanth Raja commented Aug 24, '17

Hello Cliff,

The reason I had the re-check turned on is to periodically check to see if Activity 31 is still required. Activity 32 is only triggered when the Queue length exceeds a certain value. If that does not happen, and if capacity becomes available, I would still require activity 30 and 31 to start and continue the patient flow.

I am wondering if there is a way I can have activity 30 choose between activity 31 and 32 based on if their respective "Start conditions" are met. Whichever activity first satisfies the start condition first should be triggered. I am not sue on how to accomplish this.

· 3

Sumanth Raja commented · Aug 23, 2017 at 07:20 PM

This would, again, require a re-check periodically.

0 ·

Cliff King Sumanth Raja commented · Aug 24, 2017 at 12:15 AM

Sumanth,

I studied your current model and the process flow chart you sent earlier this afternoon and have begun revising the model. As I got into the track development, I realized I still have some unanswered questions. I think the best thing to do at this point, is get together on a web meeting and work through some of this together. I've attached my revised model, so you can familiarize yourself with the approach I'm working on before we meet tomorrow (LOC, SOURCE and PCI are global macros I've defined in the model).

Send me an email when you'd like to meet. Any time after 10am MDT would work for me.

new-admission-protocol-08222017-update-ck2.fsm

0 ·

new-admission-protocol-08222017-update-ck2.fsm (124.4 KiB)

Sumanth Raja Cliff King commented · Aug 24, 2017 at 04:01 PM

Hello Cliff,

I had sent you an email, just checking if you received it. Thank you!

0 ·

Answer 3 · 2017-08-21T21:35:16Z

Cliff King answered Aug 21, '17 Sumanth Raja commented Aug 22, '17

Sumanth,

If I had a process flow diagram I could reference to better understand the patient flow logic, I would be more than happy to help you piece together a patient track (or tracks) that address all the different situations you're need to account for. You don't happen to have something you could share with me do you?

· 3

Sumanth Raja commented · Aug 21, 2017 at 09:38 PM

Hello Cliff,

I will draw up a flow diagram and share it ASAP. Thank you!

-Sumanth

0 ·

Sumanth Raja commented · Aug 22, 2017 at 02:35 PM

Hello Cliff,

This is the process flow I am trying to model. Thank you!

- Sumanth

admission-protocol-process-flow.png

0 ·

admission-protocol-process-flow.png (80.3 KiB)

Sumanth Raja commented · Aug 22, 2017 at 11:19 PM

Hello Cliff,

I re-built the model (sample model attached) step-by-step to identify the source of the error, and noticed this.

I realized that the "On Entry trigger" for the "ED_Queue" works fine. What happens is, after activity 32 is done executing it triggers activity 60. While activity 60 is being executed, however, I believe for some reason, activity 30 is triggered to start again. I do not understand why it would go back and try to execute activities after initially skipping them when they did not meet activity start condition.

Patient waiting in Queue because Start condition for Activity 30 was not satisfied.

Activity 32 is triggered from the "ED_Queue" on entry trigger as required (skipped activity 30 and 31).

Activity 60 started on completion of Activity 32 as required.

Activity 30 is started during the execution of Activity 60 (not completed).

I am not sure if this is causing the error mentioned earlier in the post, but this is something I noticed while trying to debug. I really appreciate your assistance with this! Thank you!

Best,

Sumanth

new-admission-protocol-08222017-update.fsm

0 ·

new-admission-protocol-08222017-update.fsm (128.1 KiB)

pic-1.png (161.9 KiB)

pic-2.png (182.2 KiB)

pic-3.png (183.1 KiB)

pic-3.png (132.1 KiB)

pic-4.png (173.1 KiB)

Answer 4 · 2017-08-18T21:37:46Z

Cliff King answered Aug 18, '17 Sumanth Raja commented Aug 18, '17

I don't even get the luxury of an error message, the software just up and crashes after running 20+ days or so. I think it may have something to do with the fact that you send some patients out the door when the queues are high. This normally wouldn't be a problem, but in your case, you both send patients out the door and start new activities on them based on the fact that subsequent activities are kicked off due to the fact that activity 11 will still fire as a result of its predecessor activity 10 finishing (which happens to be the activity that will also send the patient out the door. I suggest you create a separate decision point activity called earlier that decides whether to send the patient out the door or continue with the patient's care path.

· 1

Sumanth Raja commented · Aug 18, 2017 at 10:03 PM

Hello Cliff,

Thank you for the quick response. Upon further investigation, I found that by removing the "On entry trigger" for the ED_Queue object, I no longer get any errors. I am trying to figure out how to trigger activity 22 for the patient who is first in line in the queue when the length of the queue exceeds a certain number. The way have that set up currently, gives me that error.

0 ·

question