Explicit chunk for non fractional values produce errors

[bwentl]

Describe the bug
A clear and concise description of what the bug is.

TransLink would like to be able to set explicit_chunk values that are whole numbers to make it easier for us to control memory usage of our model. Currently, we have a working implementation of our model using fractional values of explicit_chunk, but when we increase the size of our synthetic population, we can encountered out of memory issues. Therefore, we wish to limit the memory use of high-memory-use sub models such as workplace location, mandatory tour scheduling model, etc, by using whole number explicit_chunk values.

When we tried to use whole numbers (>1) for explicit_chunk, we encountered the following error in workplace location (but this can happen in any module with chunking on where the chunk size is larger than number of chooser rows):

16/10/2025 19:43:18 - NOTIFY - activitysim.core.workflow.runner -  time to execute run.workplace_location UNTIL ERROR : 13.842 seconds
16/10/2025 19:43:18 - WARNING - activitysim.core.mp_tasks - AssertionError exception running workplace_location model: 
16/10/2025 19:43:18 - ERROR - activitysim.core.mp_tasks - mp_tasks - mp_households_16 - AssertionError exception caught in mp_run_simulation: 
16/10/2025 19:43:18 - ERROR - activitysim.core.mp_tasks - 
---
Traceback (most recent call last):
  File "/home/ubuntu/.uv/activitysim/tlpytools/.venv/lib/python3.10/site-packages/activitysim/core/mp_tasks.py", line 1098, in mp_run_simulation
    run_simulation(state, queue, step_info, resume_after, shared_data_buffer)
  File "/home/ubuntu/.uv/activitysim/tlpytools/.venv/lib/python3.10/site-packages/activitysim/core/mp_tasks.py", line 1048, in run_simulation
    raise e
  File "/home/ubuntu/.uv/activitysim/tlpytools/.venv/lib/python3.10/site-packages/activitysim/core/mp_tasks.py", line 1043, in run_simulation
    state.run.by_name(model)
  File "/home/ubuntu/.uv/activitysim/tlpytools/.venv/lib/python3.10/site-packages/activitysim/core/workflow/runner.py", line 347, in by_name
    self._obj._context = run_named_step(
  File "/home/ubuntu/.uv/activitysim/tlpytools/.venv/lib/python3.10/site-packages/activitysim/core/workflow/steps.py", line 83, in run_named_step
    step_func(context, **kwargs)
  File "/home/ubuntu/.uv/activitysim/tlpytools/.venv/lib/python3.10/site-packages/activitysim/core/workflow/steps.py", line 367, in run_step
    outcome = error_logging(wrapped_func)(state, *args, **kwargs)
  File "/home/ubuntu/.uv/activitysim/tlpytools/.venv/lib/python3.10/site-packages/activitysim/core/workflow/steps.py", line 46, in wrapper
    return func(*args, **kwargs)
  File "/home/ubuntu/.uv/activitysim/tlpytools/.venv/lib/python3.10/site-packages/activitysim/abm/models/location_choice.py", line 1223, in workplace_location
    iterate_location_choice(
  File "/home/ubuntu/.uv/activitysim/tlpytools/.venv/lib/python3.10/site-packages/activitysim/abm/models/location_choice.py", line 1066, in iterate_location_choice
    choices_df_, save_sample_df = run_location_choice(
  File "/home/ubuntu/.uv/activitysim/tlpytools/.venv/lib/python3.10/site-packages/activitysim/abm/models/location_choice.py", line 860, in run_location_choice
    choices_df = run_location_simulate(
  File "/home/ubuntu/.uv/activitysim/tlpytools/.venv/lib/python3.10/site-packages/activitysim/abm/models/location_choice.py", line 727, in run_location_simulate
    choices = interaction_sample_simulate(
  File "/home/ubuntu/.uv/activitysim/tlpytools/.venv/lib/python3.10/site-packages/activitysim/core/interaction_sample_simulate.py", line 482, in interaction_sample_simulate
    for (
  File "/home/ubuntu/.uv/activitysim/tlpytools/.venv/lib/python3.10/site-packages/activitysim/core/chunk.py", line 1392, in adaptive_chunked_choosers_and_alts
    assert (rows_per_chunk > 0) and (rows_per_chunk <= num_choosers)
AssertionError
---

To Reproduce
Steps to reproduce the behavior:

1. use a number for explicit chunk that is larger than chooser size
2. turn multiprocessing on
3. calculation for rows_per_chunk will be wrong and throws an error.

Expected behavior
A clear and concise description of what you expected to happen.

If chunk_size specified is larger than number of rows, the model should run without error on chunkless. If multiprocessing is used and chunk size is larger than the row being processed within a specific process, the model should run without error on chunkless.

Screenshots
If applicable, add screenshots to help explain your problem.

NA

Additional context
Add any other context about the problem here.

I suspect the calculation for chunk size is wrong in chunk.py, but need help in further diagnosis:

    def initial_rows_per_chunk(self):
        if self.chunk_training_mode == MODE_EXPLICIT:
            if self.rows_per_chunk:
                number_of_chunks = self.num_choosers // self.rows_per_chunk + (
                    1 if self.num_choosers % self.rows_per_chunk else 0
                )
            else:
                number_of_chunks = 1
            return self.rows_per_chunk, number_of_chunks

If self.num_choosers > self.rows_per_chunk, number_of_chunks would produce 0, which is not valid.

I suspect there could be more issues affecting chunking calculations, but not sure what the best places to look are.

[i-am-sijia]

Hi @bwentl , I encountered the same issue last week when trying to implement explicit_chunk for TfNSW as integer values, i.e., number of choosers. I implemented some fixes in PR #1003, which worked for TfNSW. If you'd like, please give it a try and let me know if you get other issues or have any comments.

The fixes include:

• When the specified explicit_chunk is larger than the number of choosers, the model runs in one chunk, equivalent to chunkless. [1]

• When running multiprocess, the model divides explicit_chunk by num_processes, so users don't need to change explicit_chunk when they change num_processes. In this case, the value of explicit_chunk represents the total number of choosers running concurrently across all processes, within a machine's memory limit. [2][3]

[jpn--]

Fixed by #1003