parallel modeling

[yinzhaobing]

What language and solver does this apply to?
Python, CP-SAT,

Describe the problem you are trying to solve.
Sometimes, modeling takes a few minutes, while solving may only take one minute.
At present, there seem to be multiple small models that cannot be merged.
Describe the solution you'd like
Hope to have the technology of merging models.
Describe alternatives you've considered
It is necessary to use multi-threaded technology for parallel modeling - multiple small models, and finally merge them.
Additional context
Add any other context or screenshots about the feature request here.

[sschnug]

Personal opinions (no ortools dev):

• (Fine-grained) Parallel modelling APIs are probably very dev-costly, but seldomly offer "more"
  • (Coarse-grained) is maybe a DIY topic: just wrap every ortools-touching types/data behind a mutex/lock
• Apart from corner-cases like:
  • type CCA: heavy custom preprocessing/presolving
  • type CCB: native solver language is bad intermediate language
    -> this only happens to interpreted/slow modelling-languages (e.g. Python)
    -> Argument is simple: if C++ solver is able to work with "some model" in X time, you should be easily able to produce "some model"< X time using the same tools (C++)
  • Drop Python; use C++: often this solves the issue at hand
• CCB is maybe a real problem, but does not happen that often in would claim
  • Sometimes a different model helps (e.g. compact vs. non-compact models)
    • e.g. don't produce all "n over 3" conflict-clauses a-priori
• CCA should be handled without any need to change ortools
  • Do the preprocessing on your own types/data; do it in parallel; merge results (less work than "compute") into ortools types/data
    • No need for thread-safety (or more) in ortools at all
• Even if ortools modelling-layer would be thread-safe
  • The how to exploit this in Python is probably not that simple as:
    • Multithreading as is won't help
    • Multithreading without GIL might be a bit too modern / moving target (i'm a bit out of touch with current development-state)
    • Multiprocessing is of very very coarse granularity
      • If that works, the approach of handling CCA should also help

Or to phrase it differently: If your modelling-time dominates solving-time, there are tons of (better!) options NOT related to solver-provided parallel-modelling tooling. (Maybe you want to share your use-case in ortools' github discussions for further opinions)

[npfp]

In my opinion, having the ability to define and merge sub-models is not just a question of performance but also a matter of design.

For example, in our cases we got 2 different families of submodels, let's call them A and B. Each of them have some private and public variables (by private I mean variables that only used in the submodel and by public variable I mean variables that can be linked to a variable in the other class of submodel through an equality operation for example).

From a design perspective, it could be nice to be able to build them separately and then "merge" them to get the full problem. This would allow to solve elegantly some problems like the one where you solve repeatedly A+B with always the same A but different versions/implementations of B.

I guess we could for for solutions where we would pre-build the problem as vectors or as builders and then construct the or-tools model at each call, but it looks a bit redundant with the purpose of or-tools in a way as I get the feeling we'd need to "duplicate" the variables, constraints and objectives abstractions.

[lperron]

2 options:

• the variables are independent, so why merge ?
• the variables are not independent. How do to reindex every variables appearing in the models, which ones to merge ? which ones to keep separate?

It may be nice conceptually, but even the specs are not trivial

[npfp]

Thx for the answer. My naive thought would be to have a mapping between some variables from the model A and some from the model B and use this to create equalities.

Something like:

new_problem = merge(left_problem, right_problem, left_equal_right_mapping={"left_var_x": "right_var_y", ...}

[lperron]

but time(create_a) + time(create_b) + time(merge_b into a) will not be much smaller that time(create_a) + time(append_b into a) Since 9.15, all python models is actually done in C++, the proto is only in C++, all constraint building is done in C++. To me, most of the time will be looping in python. I would use pandas for that. The rest would be reasonably fast, with not too big overhead over C++ speed. Laurent Perron | Operations Research | ***@***.*** | (33) 1 42 68 53 00 Le mer. 8 avr. 2026 à 17:51, Nicolas ***@***.***> a écrit :

…

Thx for the answer. My naive thought would be to have a mapping between some variables from the model A and some from the model B and use this to create equalities. Something like: new_problem = merge(left_problem, right_problem, left_equal_right_mapping={"left_var_x": "right_var_y", ...} — Reply to this email directly, view it on GitHub <#4614 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUPL3PRQL7PU3QEAII6SDL4UZYQLAVCNFSM6AAAAACXB47Z62VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNBZGEZTSOA> . You are receiving this because you commented.Message ID: ***@***.***>