OptaPlanner VRPTW для крупных клиентов с установкой Pickup and Drop

Я пытаюсь создать план маршрута для набора данных о клиентах размером около 20000. На одном маршруте транспортному средству может потребоваться забрать или доставить заказы клиентам. Следовательно, жесткое ограничение нормального размера не работает для этой проблемы.

Я создал теневую переменную для хранения загрузки автомобиля в каждом месте поездки. Когда транспортное средство покидает депо, нагрузка представляет собой сумму всех элементов, которые необходимо сбросить, и в каждом месте я постоянно обновляю нагрузку в зависимости от типа услуги (забор/выдача).

Проблема заключается в том, что после добавления теневой переменной и прослушивателя изменения переменной производительность ухудшилась. Расчет в секунду сократился примерно до 400. Это в основном потому, что для расчета загрузки транспортного средства в депо у меня есть цикл по цепочке. Есть ли другой эффективный способ достижения функциональности?


optaplanner
person hkdash    schedule 08.08.2014    source источник
comment
Сколько у вас в среднем цепочек? Каков был ваш расчет в секунду до этих изменений?   -  person Geoffrey De Smet    schedule 12.08.2014
comment
Я бы реализовал его таким же образом, но меня немного удивляет, что влияние на производительность заключается в том, что для VRP с временным окном я использую тот же механизм.   -  person Geoffrey De Smet    schedule 12.08.2014
comment
Расчет в секунду до этого изменения составлял около 3500. С текущим набором данных я тестирую средний размер цепочки 400.   -  person hkdash    schedule 14.08.2014
comment
Сколько у вас в среднем цепочек? (Так сколько у вас якорей?)   -  person Geoffrey De Smet    schedule 15.08.2014
comment
Там 100 якорей.   -  person hkdash    schedule 15.08.2014

Ответы (1)


arrow_upward
0
arrow_downward

Я бы реализовал так же. И я не знаю, как реализовать это лучше. Весь хвост цепи необходимо отрегулировать, а модифицированный узел цепи необходимо проверить на правильную пропускную способность.

Если производительность становится серьезной проблемой, а ваши ограничения не будут часто меняться (= небольшое обслуживание), рассмотрите возможность написания JavaIncrementalScoreCalculator: они быстрее, но их намного сложнее поддерживать... В примере VRP закомментируйте элемент scoreDRL. и прокомментируйте элемент incrementalScoreCalculator, чтобы понять, насколько он быстрее.

person Geoffrey De Smet    schedule 12.08.2014
comment
Мои ограничения будут часто меняться, и ожидается, что бизнес-пользователи изменят ограничения. Я планировал использовать таблицы решений для того же самого. - person hkdash; 14.08.2014
comment
Хорошая идея использовать таблицы принятия решений, см. пример рассадки на званом ужине. Гибкость бизнеса важнее, чем получение последней частички скорости. - person Geoffrey De Smet; 15.08.2014
comment
Эвристика построения занимает много времени (около 2 часов) и инициализирует решение в 20000. Я использую FIRST_FIT_DECREASING и инициализируюScoreTrend как ONLY_DOWN, как указано в примере VRPTW. - person hkdash; 15.08.2014