Resources needed to run the solver

What the solver does during a calculation

When you start the calculation of a monthly roster, Planopti builds a model for Google OR-Tools' CP-SAT solver: one Boolean variable per possible combination "this person, this day, this shift" (assign[e, d, s]), hard rules as constraints, soft rules as penalties to minimise. For 75 people, 31 days and 55 shift types, that is up to 128,000 variables before the solver removes those that qualifications make impossible.

The solver then explores the space of possible rosters. It does not try everything: it propagates the consequences of each decision, prunes branches that can no longer beat the best known solution, and runs several search strategies in parallel that share their findings. That work, and nothing else, is what consumes the machine's resources. The rest of the application (data entry, display, exports) costs about as much as an open spreadsheet.

Processor: the main cost

CP-SAT is a multi-threaded solver. Its num_workers parameter sets the number of searches run in parallel, and the OR-Tools documentation defines it without ambiguity: "the number of parallel workers (i.e. threads) to use during search", to keep below the number of processors in the machine. Planopti leaves this parameter at zero, which means "use every available core". During the calculation, every core is therefore busy at one hundred percent.

Three practical consequences:

• Physical cores count, not logical ones. Hyperthreading exposes two threads per core, but two CP-SAT workers on the same physical core share the same cache and execution units. An "8 cores, 16 threads" processor behaves like 8 useful workers, not 16.
• Returns diminish. Going from 1 to 4 workers changes a lot, from 4 to 8 still clearly, from 8 to 16 around 10 to 20% on the quality reached in the same time. Our article on multi-threaded search details these measurements.
• Clock speed matters less than core count. A 2.5 GHz server processor with 8 cores beats a 4 GHz laptop processor with 4 cores, because portfolio search benefits from the diversity of strategies, not the speed of a single one.

Recommendation: 4 cores minimum, 8 physical cores for a team under 300 people. Beyond 16 cores, the gain no longer justifies the cost for a calculation that runs a few minutes a month.

Why no graphics card

The question comes up often, because "heavy computation" now brings GPUs to mind. A GPU shines when thousands of identical operations apply to regular data: multiplying matrices, processing pixels, training a neural network. Constraint programming does the opposite. Each worker follows a decision tree where every branch depends on the previous one, propagates constraints over irregular structures, and takes different decisions from its neighbour. That work is sequential by nature inside a worker, and useful parallelism is counted in tens of workers, not thousands.

OR-Tools contains no GPU code at all: the word appears nowhere in its parameters. A graphics card installed in the scheduling server would sit idle from the start of the calculation to the end.

Memory: proportional to the model

Memory consumption depends on the size of the model (number of variables and constraints) and on the number of workers, because each worker keeps its own search structures. As an order of magnitude: a model of 100,000 Boolean variables with 8 workers fits comfortably in a few gigabytes. OR-Tools protects itself with the max_memory_in_mb parameter, 10,000 MB by default: if a calculation exceeds 10 GB, the solver stops cleanly and returns the best solution found rather than bringing the machine to its knees.

Recommendation: 8 GB of memory minimum, 16 GB to be comfortable up to 300 people with 8 workers. Beyond that, or with 16 workers, plan for 32 GB. Remember that the operating system, the database and the browser take their share too.

Calculation time: a setting

CP-SAT is an "anytime" solver: at any moment it holds the best solution found so far, and the time limit is a parameter you set. Stopping earlier gives a slightly worse roster, never an invalid one. In practice, a few minutes are enough for a team of 50 to 150 people, ten to twenty minutes for 300. Planopti shows the score evolving during the calculation, which lets you see when it hardly moves any more.

This changes how you size the machine: the server works flat out for a few minutes a month, or a few times a month when you rerun after a change, then does almost nothing. It does not need to be dedicated. A server that already hosts other services is fine, as long as its cores are free at calculation time.

Disk, network, system

• Disk: the SQLite database, roster history and exports take a few gigabytes at most. A standard disk is enough; the calculation happens entirely in memory.
• Network: during the calculation, nothing leaves the machine. The engine is embedded, no external service is called. In local mode, the server can be cut off from the internet.
• System: Windows 10 or 11, Windows Server, Linux or macOS, with Python 3.12, which we install. Planners only need a recent browser, on any computer.

Three reference configurations

These three profiles cover the regulated industries we target: a hospital department, an airport station, a security or logistics team. For larger headcounts or very many rules, we measure the calculation time on your data before recommending a configuration.

Checklist

• How many physical cores, and are they free at calculation time?
• At least 8 GB of memory available, 16 GB recommended.
• A few gigabytes of disk for the database and exports.
• A supported system (Windows, Linux, macOS) and an account for the installation.
• A calculation time limit agreed with the planners: a few minutes, adjustable later.
• No graphics card to plan for.