Limiting signal / trap to one recipient

[Ralph Asher]

I have a simulation of blood distribution (see previous post) where both patients (needing blood) and blood units (from donations) are modeled as arrivals with generators.

When a patient arrives and needs blood, they send a signal with what type of blood they can accept. This signal goes out to all blood units. The blood units that are of an acceptable blood type, trap this signal and send a return signal indicating that the patient can use it. Both patient and blood then exit the system.

So far, so good. However, I'm finding that I can't do a 1-to-1 pairing between patient and blood unit this way.  

Sometimes, there may be 5 blood units waiting in the system with no patients.  A patient arrives, sends a signal, and all 5 blood units trap the signal; this results in the patient getting all 5 units. (Not desired!)

Other times, there can be 3 patients all waiting for blood but not is available. With all 3 patients sending signals, if a blood unit becomes available, then the blood unit traps signals from all 3 patients and the model acts as if all 3 patients received the same blood. (Not OK!)

What I'm looking for is a way to basically code:

1) once a blood unit has trapped a patient's signal, no other blood units can trap the patient's signal

2) once a blood unit has trapped a patient's signal, it can't trap any other patient's signal

To make it more complex, right now I'm modeling as if each patient needs one unit of blood. In actuality there's a distribution of patient needs (1,2,3,4, or 5 units) and I've assigned that as an attribute to patient. So ideally I'd code it so that the patient keeps sending signals, and blood units trapping that signal, until their attribute of units_needed goes to zero.

, which then send out their own signal 

[Ralph Asher]

Ignore the very last line of that post, poor editing on my part.

[Philemon Cyclone]

My concern about the dynamic signal-trap approach with many conditions is that it could become unwieldy and hard to maintain with simmer logic. Another alternative to the large dataframe approach could be to treat blood as an actual resource that is set up as follows:

1. Define all possible blood types and initialize with some starting capacity (e.g., zero or whatever the blood bank actually has in stock at the time). 
2. Use an arrivals generator to dynamically add capacity and use one rollback after a timeout(shelf_life) per blood arrival to reduce capacity upon expiration.

You can then rely more on simmer internals to handle patients queueing for, and consuming blood. You would still need a custom function to select() the best available blood for each type (I've written exactly this sort of custom functionality for one of my use cases and could provide a code snippet if you like).

[Ralph Asher]

I'm not following how you would track lot-specific expiration dates with blood as a resource, though. I get how I could use an arrivals generator to add capacity to an individual blood type; but not how to track lot-level aging.

--
You received this message because you are subscribed to a topic in the Google Groups "simmer-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/simmer-devel/7Pbqoa2XKQw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to simmer-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/simmer-devel/faff4245-471c-45b6-8251-b242b3385463n%40googlegroups.com.

[Philemon Cyclone]

If you assume that the oldest lots are always consumed first, I think you could derive the age at consumption after the simulation has run by comparing the get_mon_arrivals() dataframe, containing blood and patient arrival times, to the get_mon_resources() dataframe, which has timestamps for when blood is consumed and which you could augment to track the age of unexpired lots.

[Ralph Asher]

I moved to the "big external dataframe of blood resources" approach and yes, it made it much easier. Basically I use a  set_attribute function to modify the external dataframe, and let simmer know if the patient found an acceptable unit of blood or not. If so, then I just modify the "units needed" attribute down by 1 unit. If units_needed goes to 0, exit the simulation via a branch.  If not, roll back to checking available blood. If you don't get enough blood by the expiry date (I put as 6 hours after entering the hospital), exit simulation via a branch representing insufficient blood found in time.

The "big dataframe" approach also made preference much simpler.  A couple things i need to iron out on warming up the simulation, but that's a small issue.  Thanks for all the help!

[Philemon Cyclone]

Glad to hear it's working out, and happy to have been able to help! 

[Iñaki Ucar]

On Sat, 13 Jan 2024 at 14:49, Philemon Cyclone <phil.m.f...@gmail.com> wrote:

My concern about the dynamic signal-trap approach with many conditions is that it could become unwieldy and hard to maintain with simmer logic. Another alternative to the large dataframe approach could be to treat blood as an actual resource that is set up as follows:

1. Define all possible blood types and initialize with some starting capacity (e.g., zero or whatever the blood bank actually has in stock at the time). 
2. Use an arrivals generator to dynamically add capacity and use one rollback after a timeout(shelf_life) per blood arrival to reduce capacity upon expiration.

You can then rely more on simmer internals to handle patients queueing for, and consuming blood. You would still need a custom function to select() the best available blood for each type (I've written exactly this sort of custom functionality for one of my use cases and could provide a code snippet if you like).

I would definitely go for this option and forget about signals if you don't mind losing track of individual donations. If you don't want to "merge" donations into the same resource, then see my previous post in the other thread.

Iñaki

 

On Saturday, January 13, 2024 at 8:21:20 AM UTC-5 ralph....@gmail.com wrote:

I have a simulation of blood distribution (see previous post) where both patients (needing blood) and blood units (from donations) are modeled as arrivals with generators.

When a patient arrives and needs blood, they send a signal with what type of blood they can accept. This signal goes out to all blood units. The blood units that are of an acceptable blood type, trap this signal and send a return signal indicating that the patient can use it. Both patient and blood then exit the system.

So far, so good. However, I'm finding that I can't do a 1-to-1 pairing between patient and blood unit this way.  

Sometimes, there may be 5 blood units waiting in the system with no patients.  A patient arrives, sends a signal, and all 5 blood units trap the signal; this results in the patient getting all 5 units. (Not desired!)

Other times, there can be 3 patients all waiting for blood but not is available. With all 3 patients sending signals, if a blood unit becomes available, then the blood unit traps signals from all 3 patients and the model acts as if all 3 patients received the same blood. (Not OK!)

What I'm looking for is a way to basically code:

1) once a blood unit has trapped a patient's signal, no other blood units can trap the patient's signal

2) once a blood unit has trapped a patient's signal, it can't trap any other patient's signal

To make it more complex, right now I'm modeling as if each patient needs one unit of blood. In actuality there's a distribution of patient needs (1,2,3,4, or 5 units) and I've assigned that as an attribute to patient. So ideally I'd code it so that the patient keeps sending signals, and blood units trapping that signal, until their attribute of units_needed goes to zero.

, which then send out their own signal 

--
You received this message because you are subscribed to the Google Groups "simmer-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simmer-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/simmer-devel/faff4245-471c-45b6-8251-b242b3385463n%40googlegroups.com.

--

Iñaki Úcar