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)