Cheapest insertion in OptaPlanner for a PDPTW?

Question

I have configured OptaPlanner for a pickup and delivery problem with time windows (PDPTW). My configuration uses a chained planning variable quite similar to the VRPTW example. The FIRST_FIT_DECREASING construction heuristic works, as well as most local search algorithms. However, when I try the CHEAPEST_INSERTION construction heuristic, I get the following exception:

Exception in thread "main" java.lang.IllegalArgumentException: The valueSelectorConfig (ValueSelectorConfig(previousVisit)) with resolvedCacheType (PHASE) and resolvedSelectionOrder (SORTED) needs to be based on a EntityIndependentValueSelector (Initialized(FromSolutionPropertyValueSelector(previousVisit))). Check your @ValueRangeProvider annotations.

The problem is that I don't really understand the error message. I've checked my @ValueRangeProvider annotations and everything seems to be correct. This question seems to raise a similar issue, here, a work around is suggested to manually sort each entity's value range list. To me it is not clear whether this workaround also applies to my case or how to apply it.

I'm using OptaPlanner 6.3.0.Final.

To instantiate the planner I'm using the following configuration:

<?xml version="1.0" encoding="UTF-8"?>
<solver>
    <environmentMode>REPRODUCIBLE</environmentMode>
    <randomType>MERSENNE_TWISTER</randomType>
    <solutionClass>com.github.rinde.logistics.pdptw.solver.optaplanner.PDPSolution</solutionClass>
    <entityClass>com.github.rinde.logistics.pdptw.solver.optaplanner.ParcelVisit</entityClass>
    <entityClass>com.github.rinde.logistics.pdptw.solver.optaplanner.Visit</entityClass>

    <scoreDirectorFactory>
        <scoreDefinitionType>HARD_SOFT_LONG</scoreDefinitionType>
        <incrementalScoreCalculatorClass>com.github.rinde.logistics.pdptw.solver.optaplanner.ScoreCalculator</incrementalScoreCalculatorClass>
        <initializingScoreTrend>ONLY_DOWN</initializingScoreTrend>
    </scoreDirectorFactory>

    <termination>
        <unimprovedMillisecondsSpentLimit>180000</unimprovedMillisecondsSpentLimit>
    </termination>

    <constructionHeuristic>
        <constructionHeuristicType>CHEAPEST_INSERTION</constructionHeuristicType>
    </constructionHeuristic>

    <localSearch>
        <unionMoveSelector>
            <moveIteratorFactory>
                <moveIteratorFactoryClass>com.github.rinde.logistics.pdptw.solver.optaplanner.MoveItFactory</moveIteratorFactoryClass>
            </moveIteratorFactory>
            <changeMoveSelector>
                <filterClass>com.github.rinde.logistics.pdptw.solver.optaplanner.ChangeFilter</filterClass>
            </changeMoveSelector>
            <changeMoveSelector>
                <entitySelector>
                    <filterClass>com.github.rinde.logistics.pdptw.solver.optaplanner.EntityFilter</filterClass>
                </entitySelector>
            </changeMoveSelector>
        </unionMoveSelector>
    </localSearch>
</solver>

The classes are defined here: https://github.com/rinde/RinLog/tree/develop/src/main/java/com/github/rinde/logistics/pdptw/solver/optaplanner

The reason I'm interested in trying CHEAPEST_INSERTION is that I've found that my own implementation of cheapest insertion outperforms FIRST_FIT_DECREASING together with Simulated Annealing which I find very suspicious. I want to compare my own cheapest insertion with that of OptaPlanner's to verify that my usage of OptaPlanner is correct.

Update: I just tried it with OptaPlanner 7.0.0-SNAPSHOT, the problem seems to be fixed (I had to change some parts of the code due to API changes, and had to change my project to use Java 8).

Looks like a bug. I [created a jira](https://issues.jboss.org/browse/PLANNER-597). — Geoffrey De Smet, Jun 09 '16 at 18:52
Note that cheapest insertion isn't used much because it scales much worse than First Fit variants. — Geoffrey De Smet, Jun 09 '16 at 18:53
**I cannot reproduce with the optaplanner-example VRPTW with cheapest insertion**. Check if you can reproduce it with 6.4.0.Final and add your solver config to the question. If it's a valid config, reopen PLANNER-597. — Geoffrey De Smet, Jun 10 '16 at 14:36

score 0 · Answer 1 · answered Jun 13 '16 at 15:31

0

It's fixed in OptaPlanner in 7.0.0.Beta1.

answered Jun 13 '16 at 15:31

Geoffrey De Smet

26,223
11
73
120

score 0 · Accepted Answer · answered Jun 14 '16 at 11:06

0

It's fixed in OptaPlanner 6.4.0.Final (and thus also in OptaPlanner 7.X).

It turns out that there was a bug in my configuration, I was using 6.3.0.Final contrary to 6.4.0.Final.

answered Jun 14 '16 at 11:06

rinde

1,181
1
8
20

Cheapest insertion in OptaPlanner for a PDPTW?

2 Answers2