Search code examples
partitioningquarkusoptaplannerplanning

Why does the final score of Partition Search drop badly


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?


Solution

  • 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.