A few options come to mind for batched servicing.

Option 1: Multiple servers

In a sense what batch processing means is that there are multiple abstract servers, which may at times mean multiple servers in Ciw being used to represent a single thing in real life that can complete multiple jobs simultaneously. This allows having multiple jobs being completed simultaneously. In Ciw this can be done by passing an argument to the number_of_servers in the ciw.create_network

Option 2: Sequential distribution

The first approach involves using ciw.dists.Sequential. The idea here is to precompute the service times ahead of time in sequence.

A sequence of seq = [1, 0, 0, 0, 3, 0] would mean that 4 messages are serviced at t=1, then 2 jobs are processed at t=4. This will cycle, so if you do not want any cycling to occur then you must make the sequence longer in time than the simulation time.

Option 3: Custom distribution

If you need something like option 2 but you would rather sample the service times during the simulation than precompute them, then you can design your own custom distribution as per the docs.

from ciw.

I might have to think more service lingering time.

One simple option is to include the lingering time into the Ciw node's service time. That would be fine if you're trying to get the rate of flow of messages right, but wouldn't help if you wanted to estimate something like the difference between the service time and lingering time.

Otherwise I think you'll have to look at patching where you set the server to be off duty for some amount of time right after the completion of a service.

from ciw.

Hi @ZacAttack I think you can do this with custom service disciplines.

Please see the test case test_custom_service_discipline on line 1243 of the file Ciw/ciw/tests/test_simulation.py
for an example of this: https://github.com/CiwPython/Ciw/blob/22536cc200ed80d97c0e7b6d3e231ea3996eb144/ciw/tests/test_simulation.py#L1243C9-L1243C39

It should be simply to add another check that says, if number of customers above a threshold, just take the customer at the head of the queue, regardless of their current waiting time.

One drawback of this method is that customers are only chosen when the choose_next_customer methods is called. So this is really a "linger for at least" methods. e.g. "linger for at least 3 time units, and next time choose_next_customer is called, take the first customer who has waited for at least 3 time units". So some people might wait longer than that. The choose_next_customer methods is called when a customer arrives, leaves, or a shift change occurs.

from ciw.