Scheduling problems arise in many applications and are commonly solved with automated reasoning and constraint-based methods. We study a variant of the so-called resource-constrained cumulative scheduling problem, with a flavor of flow allocation, in which a set of workers must send workloads to a shared processing facility. The goal is to schedule the workload sent from each worker at each time step without exceeding the facility's maximum processing capacity or the storage capacities of the workers. In a central instantiation of the problem, the workers are industrial sources that produce wastewater that needs to be transferred to a treatment plant. The problem of computing a feasible schedule in a similar setting has previously been studied under the name of the wastewater treatment plant problem. More precisely, we study the applicability of optimization modulo theories (OMT) and mixed integer programming (MIP) to solving real-world benchmarks of this scheduling problem. As our main contributions, we: i) extend a previously proposed constraint model for computing feasible schedules by e.g., allowing more flexible scheduling of the released water, ii) extend the model with several diferent optimization criteria, including optimizing for evenness of the workload arriving at the facility, and minimizing the makespan of the schedule, and iii) collect a new open-source dataset based on real-world wastewater flow quantities. We evaluate our model on two diferently-sized time spans of the new dataset as well as on previously used benchmarks using state-of-the-art solvers in both paradigms. Our evaluation demonstrates that optimization criteria related to makespan minimization do not need to slow down the run time of the solvers. In contrast, the criteria on workload evenness are, in general, more dificult to handle.
The resource-constrained scheduling problem (RCSP) [
More precisely, we study a problem setting in which a set of workers must access the limited resources
of a shared processing facility. At each time step, all workers release separate tasks that each require
some amount of the facility’s processing capacity. Each worker can then send a part of the task’s
total workload directly to the facility, and temporarily store the remainder. The goal is to schedule the
workload sent from each worker at each timestep without exceeding either the maximum intake capacity
of the facility or the storage capacities of individual workers. The general formulation highlights that
our model could be applicable in many settings; the processing facility could be a storage facility or
a vaccination center that needs to vaccinate parts of the population. In our experiments, we focus
on a central concrete instantiation of the problem called the wastewater treatment problem in which
the workers are pumping stations [
More precisely, as the main contribution of this paper, we develop a constraint model for computing
schedules to the general formulation of the wastewater treatment problem. Our model is designed based
on consultation from the Helsinki Region Environmental Services Authority (HSY). Specifically, we
allow each worker to send only part of the new workload for processing at a time. Our model also allows
a time delay between a worker releasing workload and that workload arriving at the facility. We study
the computational feasibility of finding both feasible and optimal schedules under a number of diferent
optimization criteria. We show how to minimize the makespan of the schedule and how to compute
schedules in which the amount of workload (e.g. wastewater) arriving at the processing facility is as even
as possible. Especially the latter criterion is motivated by the discussions with HSY; high wastewater
influx rates are undesirable as they necessitate feeding the input faster through the limited-capacity
treatment process, leading to worse output water quality. We detail an optimization modulo theories
(OMT) [
As an additional contribution, we collect real-world wastewater data from HSY and use it to form a
new benchmark set containing altogether 624 OMT and 624 MIP benchmarks. We report on an extensive
evaluation of state-of-the-art solvers in these two constraint paradigms on this problem. In addition
to the new benchmarks that we collected, we also evaluate solvers on the data used in [
The rest of the paper is structured as follows: in Section 2, we detail our problem setting and the constraint paradigms of interest. In Section 3, we describe the constraint model for computing optimal schedules in this setting under diferent optimization criteria. In Section 4, we describe the new open-source benchmarks we collected as part of this work, and in Section 5, we report on the experimental evaluation of these state-of-the-art solvers in all paradigms on these and previously established benchmarks. The paper is concluded in Section 6.
We detail preliminaries on the variant of preemptive cumulative scheduling that we study, as well as the constraint paradigms in which we model the problem.
We study a variant of the resource-constrained cumulative scheduling problem in which each worker
can subdivide and temporarily store their tasks. For some intuition on our problem setting, consider a
set of pumping stations that pump wastewater to a treating facility that can process a limited amount
of wastewater at each time step. Each pumping station receives new wastewater at each time step and
needs to decide how much to pump forward for treatment and how much to store in its temporary
storage with a limited capacity. The task is to schedule the amount of water pumped forward at
each timestep while ensuring that neither the treating facility’s processing capacity, nor any pumping
station’s storage capacity is exceeded. Additionally, each pumping station has an upper limit on the
amount of water that can be pumped per timestep, and it takes some time for the water to arrive from
a pumping station to the facility. A similar problem was studied under the name of the wastewater
treatment plant problem in [
More abstractly, a problem instance in our setting specifies a finite and discretized time horizon over #t timesteps under which #w diferent workers need the limited resources of a single shared facility that can receive a total workload of maxCapacity on each time step. The input instance specifies for each worker and timestep the new incoming resource requirement task, that will need from the facility within the time horizon. Since the facility can receive a limited quantity of workload per timestep, each worker can temporarily store up to storageCapacity of workload. The total quantity of storage capacity at each worker is constant for all time steps; the quantity stored at time takes from the remaining storage space available at subsequent timesteps until the workload is sent to the facility. Finally, we assume that the sent workload takes d timesteps to arrive from at the facility and that the maximal rate of workload output to the facility for each worker is limited by maxOutput.
The goal in our setting is to schedule the amount of workload sent from each worker at each timestep to the facility. More precisely, a schedule specifies for each worker a storage output Sout(, ) as the amount of the currently stored workload to send for processing at timestep , and the part P(, ) of task, released at timestep to immediately send for processing. The rest of the task released at then needs to be temporarily stored. A schedule is feasible if neither the maximum capacity of the facility nor the maximum storage or output capacities of any worker are exceeded at any timestep.
In preemptive scheduling, the processing of each task can be paused and continued later. Since a worker in our setting can subdivide its task in a way that momentarily sends zero workload for processing, our problem formulation captures a preemptive setting as long as the storage capacities of the individual workers are high enough to enable this. As we focus on an optimization setting, we also only consider instances in which the time horizon, the maxCapacity of the facility, and the maxOutput and storageCapacity values of the workers are large enough for feasible schedules to exist.
To summarize, we say that a schedule is feasible if the total workload from all workers combined arriving at the facility at any timestep does not not exceed maxCapacity, and the following three statements hold for each timestep and worker : (i) the workload temporarily stored at does not exceed storageCapacity, (ii) the total quantity of workload released from , Sout(, ) + P(, ) does not exceed the maximum output rate maxOutput, (iii) all workloads arrive at the facility within the time horizon.
For a concrete example, Table 1 details a feasible schedule for a problem instance where the shared facility is a wastewater treatment plant (wwtp), and there are two pumping stations with flexible forward-pumping capacities up to maxOutput1 = 6000 m3/h, and maxOutput2 = 10000 m3/h, both located 0 hours away from the facility (i.e. d1 = d2 = 0). The maximum capacity of the facility is maxCapacity = 15 000 m3 incoming wastewater per hour, and the workers have individual storage capacities of storageCapacity1 = 6000 m3 and storageCapacity2 = 10000 m3, respectively. The displayed schedule is for task1,1 = 4000, task1,2 = 5000, task2,1 = 2000 and task2,2 = 5000 m3 and assuming initial storage levels of startLevel1 = Storage(1, 0) = 3000 and startLevel2 = Storage(2, 0) = 5000 m3.
In addition to the problem of computing feasible schedules, we consider several diferent optimization
extensions. The first three are motivated by a desire to find schedules that reduce exceptionally high or
low levels in the hourly processing requirements placed on the facility. In the context of wastewater
treatment, the motivation for computing schedules that have an even flow of wastewater arriving at the
treatment plant is motivated by the treatment processes and discussions we had with HSY [
In more detail, we focus on three separate optimization criteria related to minimizing fluctuations in
the quantity of workload that arrives at the facility. In the following, let Total() be the total workload
arriving at the facility at timestep . The MAXMIN objective maximizes MinWorkload, i.e., maximizes
the minimum workload arriving at the facility over all timesteps. Analogously, the MINMAX objective
minimizes the maximum Total() over all timesteps, resulting in the smallest possible maximum
workload MaxWorkload received at the facility during the time horizon. Finally, the MINDIFF objective
minimizes the diference MaxWorkload − MinWorkload, essentially preferring schedules with more
even incoming hourly workloads. Under this objective, the problem can be seen as an example of a
resource leveling problem [
Additionally, we present results on two objectives that align more closely with previous work on scheduling problems. The MAKESPAN objective minimizes the makespan of the schedule, i.e. the last timestep at which the facility receives any workload. Finally, the MSTORAGE objective minimizes the total sum of storage levels over all workers and all timesteps . As an interesting side remark, we note that the schedules optimal under MSTORAGE are also optimal under the MAKESPAN objective. Because a decrement of Storage(, ) by a quantity of Sout(, ) > 0 also decreases the sum of Storage(, + 1) + Storage(, + 2) + · · · + Storage(, #t), MSTORAGE leads to emptying of all storages at the earliest possible timestep, which is the objective of MAKESPAN.
To end this section, we note that our problem setting is closely related to the well-studied network
lfow allocation problems [
A term T is a sum or diference of integer or real variables. A theory atom is a comparison (T1 < T2) or T1 = T2 between terms. A literal ℓ is either a {0, 1}-variable , a theory atom , or their negation ¬ and ¬. A clause is a disjunction (∨) of literals, and a formula is a conjunction (∧) of clauses. When convenient, we view a clause as a set of its literals and a formula as a set of its clauses.
An assignment maps variables to their domains. A theory atom is assigned to 1 by (i.e. () = 1) if assigning the variables in the terms results in a true comparison. The semantics of assignments are extended to literals, clauses and formulas in the standard way: (¬ℓ) = 1 − (ℓ),
Description number of workers number of timesteps maximum workload the facility can receive at each time step total workload of the task released at worker at time maximum workload storage capacity of workload stored at worker at the beginning of timestep 1 number of timesteps for workload from to arrive at the facility maximum workload a worker can send for processing at any timestep
Description workload released at at time immediately sent to the facility workload sent from storage of at timestep to the facility workload in the temporary storage of at the end of timestep total workload arriving at the facility at () = max{ (ℓ) | ℓ ∈ }, and ( ) = min{ () | ∈ }. We say that an assignment for which ( ) = 1 is a solution to . The satisfiability modulo linear integer and rational arithmetic problem is to decide the existence of a solution to a given formula. An OMT instance (over the same theory) (, T) consists of a formula and a term T. The task is to compute a solution of that minimizes T. If one wishes to maximize T, this is achieved by minimizing − T.
In addition to OMT, we consider mixed integer programming (MIP) where the goal is to minimize an objective ≡ ∑︀ + ∑︀ where are integer variables, are real variables, and are real constants, subject to a set of linear inequalities.
In this section, we detail our constraint models for the scheduling problem. In Section 3.1, we detail
the OMT model and how it relates to the model for computing feasible schedules proposed in [
notational convenience, we let P(, ) = Sout(, ) = 0 whenever ≤ 0. Storage(, ) is the amount of workload in the temporary storage of at the end of timestep . Finally, Total() is the total workload arriving at the facility at time , from all workers combined.
Note that while the timesteps, , range from 1 to #t, we denote startLevel for all workers by Storage(, 0).
The first constraints define the domains of the main variables. The amount of workload immediately sent for processing by worker is at least 0 and at most task,; the constraint
(0 ≤ P(, )) ∧ (P(, ) ≤ task,) is included for all timesteps in the range of 1 to #t − d. Note that for any feasible schedules to exist task, = 0 has to hold for the last d timesteps.
For some intuition on the domains of Sout(, ) and storageCapacity, note that in any feasible schedule, the storage of worker needs to be emptied at the latest at the timestep #t − d and not increased after it so that all of the workload from can arrive at the facility by the timestep #t. In our model, the Sout(, ) variable is only included for ∈ [1, #t − d] during which its domain is set to be between 0 and storageCapacity; the constraint
(0 ≤ Sout(, )) ∧ (Sout(, ) ≤ Storage(, − 1)) is added for all timesteps ∈ [1, #t − d]. Our setting also requires that the total quantity of workload sent from at each time step is at most maxOutput; the constraint
(Sout(, ) + P(, ) ≤ maxOutput) is included for all workers and timesteps in the range of 1 to #t − d. The domain of Storage(, ) is set between 0 and storageCapacity for all timesteps in the range of 0 to #t − d − 1 and to equal 0 for the final d + 1 timesteps (note that Storage(, ) denotes the storage level at the end of timestep , after possible emptying or filling at ); the constraint
(0 ≤ Storage(, )) ∧ (Storage(, ) ≤ storageCapacity) is included for ∈ [0, #t − d − 1], and (Storage(, ) = 0) for ∈ [#t − d, #t].
Finally, the total workload arriving for processing at is the sum of storage-derived and immediately sent workloads arriving from each worker at ; the constraint
Total() = ∑︀#w=1Sout(, − d) + P(, − d) is added for all timesteps and all defined Sout(, ) values. With these variables, the constraint that enforces that the maximum capacity of the facility is not exceeded is
(Total() ≤ maxCapacity) which is added for all timesteps ∈ [1, #t].
The final sets of constraints encode the semantics of Storage(, ) and link the workload immediately sent for processing with the changes in the amounts stored. For some intuition on these, note that the amount of new workload stored at worker on time is task, − P(, ). With this intuition, the amount of workload stored at worker is increased on each iteration by task, − P(, ) and decreased by Sout(, ). Stated as a constraint, this is (1) (2) (3) (4) (5) (6) Storage(, ) = Storage(, − 1) − Sout(, ) + task, − P(, ) (7) which is added for all ∈ [1, #w] and ∈ [1, #t − d].
The last constraints link the changes in the amount of workload stored with the amount of workload immediately sent for processing. In essence, the constraints state that the amount of new workload task, is equal to the amount of workload immediately sent for processing and any positive change in the amount stored at . If the change in the amount stored is negative (or zero), indicating that some workload (or none) was also sent from the storage, then the workload equal to task, should be sent for processing immediately. As constraints, with ΔS(, ) = Storage(, ) − Storage(, − 1) as notational shorthand, this is: ¬(0 < ΔS(, )) ∨ (task, = P(, ) + ΔS(, )) ¬(ΔS(, ) ≤ 0) ∨ (task, = P(, )) (8) (9) i.e. 0 < ΔS(, ) =⇒ task, = P(, ) + ΔS(, ) and ΔS(, ) ≤ 0 =⇒ task, = P(, ). The constraints 8 and 9 are added for all ∈ [1, #w], ∈ [1, #t − d], for which task, > 0.
We summarize the model for computing feasible schedules as follows. Let schedule be an SMT formula consisting of Constraints 1-9 as specified in this section. Then any solution of schedule sets the P(, ), Sout(, ), and Storage(, ) variables in a way that corresponds to a feasible schedule.
To extend the constraint model from feasibility to optimization, we next describe how to encode each of the five optimization criteria discussed in Section 2.1.1 as a term T such that the optimal solutions to the OMT instance ( schedule, T) correspond to optimal schedules under . Here schedule is an SMT formula consisting of the Constraints 1-9 detailed in 3.1.1.
To encode the MAXMIN and MINMAX optimization criteria we add the real variables MinWorkload and MaxWorkload to the instance as well as the constraints (MinWorkload ≤ Total()) ∧ (Total() ≤ MaxWorkload) for all ∈ [1, #t] to define them. Then maximizing MinWorkload over the solutions that satisfy the schedule results in a schedule that maximizes the minimum workload arriving at the facility at each time step (i.e. the MAXMIN criteria). Analogously, minimizing MaxWorkload obtains a schedule that minimizes the maximum workload (i.e., the MINMAX criteria). Finally, minimizing MaxWorkload − MinWorkload obtains a schedule in which the largest absolute diference in arriving workload is as small as possible across all timesteps, i.e. the MINDIFF optimization criteria. The bounds for MinWorkload and MaxWorkload are initialized to 0 and maxCapacity.
The MSTORAGE objective is encoded by minimizing the sum of all Storage(, ) variables. Finally, the MAKESPAN objective is encoded by minimizing the integer LastWorkIn variable defined to equal the last time step on which the facility receives any workload. This definition is enforced with the constraints ¬(Total() > 0) ∨ ( ≤ LastWorkIn) added for each timestep.
We briefly detail the main diferences between our OMT model for cumulative scheduling presented
in Section 3.1.1, and the SMT approach to computing feasible schedules for the wastewater treatment
plant problem proposed by Bofill, Muñoz and Murillo in [
Our constraint model extends the problem of computing feasible schedules to optimization and allows more flexible workload sending from workers. Our model allows, e.g., for sending all of the new workload task, at together with a part of the workload in storage. Constraint 3 in our model limits the total quantity of workload sent from each worker rather than just the quantity released from the storage of each worker; this decision was made based on discussion with the local wastewater agency HSY where we confirmed that all wastewater at a given station is pumped forward using the same pumps regardless of possible prior temporary storing.
The MIP model we propose uses all constants and variables listed in Tables 2 and 3 as well as a {0, 1}-variable SMinus(, ) for each worker and timestep . SMinus(, ) is an indicator for emptying (some of) its storage at timestep . In other words, a solution to the MIP model that assigns SMinus(, ) = 1 corresponds to a schedule in which Sout(, ) > 0.
Our MIP model includes the Constraints 1-7 detailed in Section 3.1.1 as well as a "Big-M" encoding of the implications in Constraints 8-9. The constant M was set as the maximum task, + maxOutput over all timesteps and workers, and was set to 10− 14, which is the smallest possible positive storage decrement for any worker and timestep.
ΔS(, ) ≤ − · SMinus(, ) + M · (1 − SMinus(, )) ΔS(, ) ≥ −
M · SMinus(, ) P(, ) ≥ task, − M · (1 − SMinus(, ))
P(, ) ≤ task, + M · (1 − SMinus(, )) P(, ) + ΔS(, ) ≥ task, − M · SMinus(, ) P(, ) + ΔS(, ) ≤ task, + M · SMinus(, ) (10) (11) (12) (13) (14) (15) where ΔS(, ) = Storage(, ) − Storage(, − 1). Constraint 10 requires that a non-negative ΔS(, ) results in SMinus(, ) = 0. Constraint 11 requires that a negative ΔS(, ) results in SMinus(, ) = 1. Thus, SMinus(, ) is 1 if the storage of worker is decremented at timestep , and 0 otherwise. Constraints 12-13 ensure that if the storage of at timestep is being partially emptied, the entire task task, is directly sent to the processing facility. If instead there is no storage decrement, then constraints 14-15 split the workload as task, = P(, ) + ΔS(, ).
For the MIP model, the MAXMIN, MINMAX, MINDIFF and MSTORAGE objectives were encoded precisely as described in Section 3.1.2. In order to encode MAKESPAN, we introduce for each a binary variable TotalPositive() as an indicator for the total workload arriving at the facility being greater than zero. With this variable, the implication Total() > 0 =⇒ LastWorkIn ≥ that defines the LastWorkIn to be minimized for the MAKESPAN objective is encoded with the following constraints: Total() ≤ maxCapacity · TotalPositive(), and LastWorkIn ≥ · TotalPositive(). These ensure that if TotalPositive() = 0 then Total() = 0 and if Total() > 0 then TotalPositive() = 1.
Before presenting the results of our experimental evaluation, we briefly detail the new open-source benchmark set for OMT and MIP that we collected for this work.
We obtained hourly real-world data on the quantities of wastewater pumped and wastewater surface levels in 2023 and 2024 at two pumping stations maintained by HSY. The two pumping stations have maximum outputs of maxOutput1 = 30000 m3/h and maxOutput2 = 5543 m3/h, respectively. The maximum capacity of the treatment plant is maxCapacity = 29166 m3/h. The storage capacities of the workers were estimated from the data. For the first station, we knew the theoretical total volume of the storage. However, in consultation with HSY, we learned that storing water amounts even close to the maximum volume would risk flooding of associated underground structures and be highly undesirable. Thus, we instead set storageCapacity1 = 168241 m3 based on the maximum water level realized in 2023 and 2024. For the second station, we did not know the maximum volume of the storage. Instead, we assumed that the largest drops in surface level correspond to situations with maximal output of the pumps coinciding with comparatively negligible volume of incoming water. We averaged 10 largest drops in surface levels during 2023 and 2024 to get an estimate for the ratio of surface level change (in cm) to output water volume, and based on the highest observed storage surface level in this two-year period then set the maximum storage volume as storageCapacity2 = 20468 m3. The maximum output maxOutput1 = 30000 m3/h for the first station was obtained from the agency, while maxOutput2 was set to 5542 m3/h based on the maximum value in the data. The default delay d1 and d2 of both stations is 0 hours.
With these values for the constants, we create two sets of benchmarks: the 24-hour local set and
the 1104-hour local set. The 24-hour set is based on the timespan from 2024-11-16 00:00 to 2024-11-16
23:00, and the 1104-hour set on 2024-11-16 00:00 to 2024-12-31 23:00. This specific timeframe for our
evaluation was chosen due to the convenience of the data not containing any missing values in these
ranges. With the starting point of the timespan decided, the starting storage levels for the two stations
could be read directly from the dataset as startLevel1 = 58182 m3 and startLevel2 = 379 m3,
respectively. In line with [
We report on an experimental evaluation of the constraint models described in Section 3. After detailing
the setup of the experiments in Section 5.1, we present results on the relative hardness of computing
optimal schedules under diferent optimization criteria, as well as the efect of enforcing the workloads
to be integer and having delays between the workers and the facility in Section 5.2.
We describe the benchmarks, solvers and the hardware we use. The open-source benchmarks (including
the script for generating them) are available online [
In addition to the local benchmark sets described in Section 4 we use the dataset called real (which we
call B24) from [
In our experiments, we study the efect of two variations of the benchmarks being solved. The first is whether all variables in the models are restricted to real values or integral values. The motivation for studying the integer variants is two-fold. On the one hand, the abstract problem setting could be applicable in settings where the workload cannot be divided, e.g., storing discrete wares or treating people. On the other, some solvers do not support floating-point values, and those that do can sufer from rounding errors when dealing with them.
The second variation of benchmarks we study is whether there is a delay between the workers and the facility. The default delays for all workers in the local data is 0 based on the physical locations of the stations and the processing facility. The BMM dataset does not specify delays for the industrial facilities. Thus, we consider the default values of the workers in the BMM set to be 0 as well. To demonstrate the efect that delays have on the overall solving time, we consider a variant of the benchmarks with synthetic delay values. For the local sets, the synthetic variant puts the delay of the second worker to 2. For B24, we randomly assigned delay values 2, 2, 5, 2, 6, 5, 3, and 4 for the eight facilities, respectively.
Table 4 summarizes the feasibility benchmarks we use in our evaluation. The number of constraints and variables reported are for the OMT variants of the benchmarks. The total number of benchmarks reported is obtained as the number of diferent maximum capacity values considered, plus the four configurations following from the two variants (delays and integer variables) that we just described. For example, for the 24-hour local dataset with 11 diferent maxCapacity values, this translates to 44 benchmarks of feasibility problems. The total number of unique combinations over all the datasets is thus 44+60+48=152 for OMT and MIP models, encompassing all combinations of maxCapacity, choice of integer vs. real-valued workload, and all-zero or non-zero delay values. Combined with the 5 optimization criteria and runs without optimization we end up with 912 runs for each OMT and MIP solver (6 · (44 + 60) = 624 runs with the local sets, and 288 with B24 data).
As OMT solvers, we consider OptiMathSAT (OMath) version 1.7.3 [
The OMT benchmarks in SMT-LIBv2-format were produced using the Python API of Z3 [
fact, all Gurobi runs finished within 32 seconds. For Z3, we observe that enforcing the MSTORAGE optimization criteria leads, in general, to higher running times and fewer solved instances compared to enforcing MAKESPAN. We also observe that Z3 generally solves the integer-restricted benchmarks more eficiently, and that optimizing the evenness of the flow to the processing plant is in general, more challenging than only minimizing the makespan of the schedule, as witnessed by the lower number of instances solved and higher running times of Z3 under MINMAX, MAXMIN and MINDIFF when compared to MAKESPAN. For a more fine-grained view of the results for the OMT solvers, we note that OptiMathSAT solved all feasibility benchmarks, but was not able to solve any optimization benchmarks from the L1104 dataset within the time limit, while Z3 solved all feasibility instances and 58.3 % of the optimization instances from L1104.
As an interesting side note, we observe that when enforcing the constraint (P(, ) = 0) ∨ (P(, ) =
task,) for all workers and timesteps that was used in the previous model of a similar problem [
Table 6 demonstrates the efect of non-zero delays on the overall solving time of MIP and OMT solvers. We observe that delays between the workers and the processing facility do not, in general, influence the running time of any solvers significantly.
B24
L24
L1104 300
We studied a variant of cumulative scheduling under diferent optimization criteria, focusing on a concrete instantiation in which a set of wastewater sources schedule pumping the water for treatment while not overloading the facility’s max capacity or their individual (temporary storage) capacities. We presented the first constraint model for computing optimal schedules for this problem, collected a new real-world dataset, and used it to evaluate the performance of state-of-the-art solvers in MIP and OMT in this setting. Our results demonstrate the efectiveness of MIP for the setting and the feasibility of OMT. Interesting future work includes extending the model to settings where not all workers are directly connected to the processing facility; multiple workers may link together prior to the facility, as is common for wastewater treatment infrastructure.
The authors have not employed any Generative AI tools.
The work is supported by the Research Council of Finland under the grant 362987. The authors wish to thank the Finnish Computing Competence Infrastructure (FCCI) for computational and data storage resources, and Helsinki Region Environmental Services Authority (HSY) for the Finnish wastewater treatment data.