Releasing resources seized inside clones after synchronize

[Philemon Cyclone]

In my simulation I have a step in which multiple resources are seized simultaneously using cloned trajectories. For example, clone 1 seizes resource A and clone 2 seizes resource B. In the code, the seize for A is written before B, but in wall-clock time, both A and B are seized simultaneously. The clones finish simultaneously since they have the same timeout. 

The next step requires that A and B both be released after the clones are synchronized, because A and B are interleaved with a downstream resource C. However, after the clones synchronize, it seems that only resource B stays seized by the arrival and resource A loses its "seized" status despite still "serving". Is this a bug?

I believe I can get around this issue by manually selecting and releasing both resources after the synchronization (or at least by forcing resource A to capacity 0 and back to 1, thereby presumably resetting out the "serving" bit). The manual selection I can do by referencing an attribute I set prior to the clones that indicates which resources should be selected within the clones. However, I was wondering about a more natural/seamless way of doing this within simmer.

Thank you!

[Iñaki Ucar]

On Thu, 7 Dec 2023 at 18:21, Philemon Cyclone <phil.m.f...@gmail.com> wrote:

In my simulation I have a step in which multiple resources are seized simultaneously using cloned trajectories. For example, clone 1 seizes resource A and clone 2 seizes resource B. In the code, the seize for A is written before B, but in wall-clock time, both A and B are seized simultaneously. The clones finish simultaneously since they have the same timeout. 

The next step requires that A and B both be released after the clones are synchronized, because A and B are interleaved with a downstream resource C. However, after the clones synchronize, it seems that only resource B stays seized by the arrival and resource A loses its "seized" status despite still "serving". Is this a bug?

Not a bug, but a current limitation. See https://github.com/r-simmer/simmer/issues/207

 

I believe I can get around this issue by manually selecting and releasing both resources after the synchronization (or at least by forcing resource A to capacity 0 and back to 1, thereby presumably resetting out the "serving" bit). The manual selection I can do by referencing an attribute I set prior to the clones that indicates which resources should be selected within the clones. However, I was wondering about a more natural/seamless way of doing this within simmer.

Yes, you need the workaround for now. You can see that the issue above has been around for some time now, and I don't have a clear roadmap for it yet.

Iñaki

 

Thank you!

--
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/ab42f34f-5d95-4d96-bca5-55f528f37ae5n%40googlegroups.com.

--

Iñaki Úcar