Why does the final score of Partition Search drop badly

Question

I am new to Optaplanner. I'm trying to achieve a good score through the partitioning strategy. This is my very basic solver configuration:

<solutionClass>com.my.package.SolutionClass</solutionClass>
  <entityClass>com.my.package.EntityClass</entityClass>
  <scoreDirectorFactory>
    <constraintProviderClass>com.my.package.ConstraintsClass</constraintProviderClass>
  </scoreDirectorFactory>

  <partitionedSearch>
    <solutionPartitionerClass>com.my.package.PartitionerClass</solutionPartitionerClass>
    <localSearch>
      <termination>
        <secondsSpentLimit>60</secondsSpentLimit>
      </termination>
    </localSearch>
  </partitionedSearch>
</solver>

To test it out I partitioned my problem in two sub-problems. When I look at the best scores achieved by the single partitions they are not bad (-3hard/10soft, -2hard/15soft). However, the general "reduced" score seems to be the following:

[org.opt.cor.imp.par.DefaultPartitionedSearchPhase] (executor-thread-0) Partitioned Search phase (0) ended: time spent (60104), best score (-29hard/15soft), score calculation speed (7735/sec), step total (29), partCount (2), runnablePartThreadLimit (6).

Why is that? Am I missing something?

score 1 · Accepted Answer · answered Nov 23 '21 at 16:04

1

That is the nature of partitioned search. Each partition will be optimized individually, and these individual partitions will therefore have decent scores. However, these two partitions then need to be combined, merged into the final solution. This step is not optimized, and therefore this is where some extra inefficiencies will come from.

You may want to try running a non-partitioned solver on the final solution and see where that gets you. But if you could do that, you probably wouldn't have been using partitioned search in the first place.

See OptaPlanner documentation on Partitioned Search for a discussion of where the inefficiency comes from.

answered Nov 23 '21 at 16:04

Lukáš Petrovický

3,945
1
11
20

Ok thank you, I get it. How do I get the partitioned solutions in Java? solver.solve(problem) only returns the merged bad solution. – Giulia Fois Nov 23 '21 at 16:43
As far as I know, there is no public API to do that. – Lukáš Petrovický Nov 23 '21 at 20:56
You could partition them before giving them to the solver and just use n solvers to solve them individually (or let a single SolverManager do it in parallel for you, each partition being a job). – Geoffrey De Smet Nov 24 '21 at 12:22

score 1 · Answer 2 · answered Nov 24 '21 at 12:27

[Addition to Lukas's fine answer]

Partitioned Search only works if your partitioning is compatible with your constraints. In your case, I believe your Partitioner is not.

For example in employee rostering, presume there is hard constraint to assign at most 10 shifts per employee. Now, if you partitioned 8000 shifts in partitioned of 1000 shifts, but don't partition the 300 employees - each partition gets all 300 employees (which is the mistake). Then partition 1 could assign 9 shifts to Ann, without breaking hard constraints (0hard). Similarly, partition 2 could assign 8 shifts to Ann, without breaking hard constraints (0hard). Merged however, there will be 17 shifts assigned to Ann for a hard score of -7hard.

I think that's what you're seeing with your -3hard/10soft + -2hard/15soft = -29hard/15soft

Thank you so much, this answer made me realize where I was wrong! — Giulia Fois, Nov 29 '21 at 13:04

Why does the final score of Partition Search drop badly

2 Answers2