optaplanner недвижимые объекты планирования

Question

Я работаю с Optaplanner для решения проблемы, аналогичной примеру планирования приема пациентов.

У меня возникли две проблемы.

Во-первых, когда кто-то из объектов планирования (аналогично bedDesignation примера) позиционируется кем-то (а не optaplanner), этот объект планирования оценивается как другие. Объект планирования, созданный вручную, становится неподвижным объектом планирования, но он по-прежнему считается подвижным объектом планирования. И из-за этого он нарушает некоторые жесткие ограничения.

Во-вторых, если один из объектов планирования (аналогичный bedDesignation) расположен кем-то (а не optaplanner), этот объект планирования перемещается во время фазы локального поиска. Локальный поиск фазы сконфигурирован так (такой же конфигурации, чем, например):

класс

<localSearch> 
    <unionMoveSelector> 
     <moveListFactory> 
     <moveListFactoryClass>org.optaplanner.examples.pas.solver.move.factory.BedDesignationPillarPartSwapMoveFactory</moveListFactoryClass> 
     </moveListFactory> 
    </unionMoveSelector> 
    <acceptor> 
     <entityTabuSize>7</entityTabuSize> 
    </acceptor> 
    <forager> 
     <acceptedCountLimit>1000</acceptedCountLimit> 
    </forager> 
    </localSearch> 

BedDesignationPillarPartSwapMoveFactory не отличается от примера. Я прочитал в документации, что для неподвижных объектов планирования мы должны убедиться, что пользовательский moveListFactory не перемещает неподвижные объекты. Но как ? В файле конфигурации xml или в самом классе?

Благодарим за помощь.

Answer 1

Отрегулируйте BedDesignationPillarPartSwapMoveFactory, чтобы пропустить объекты (BedDesignations), которые не могут перемещаться (например, если они isLocked() == true).

Или еще лучше: не используйте BedDesignationPillarPartSwapMoveFactory вообще, просто используйте общие переключатели перемещения: changeMove, swapMove, pillarChangeMove и pillarSwapMove. Столбец теперь выбирает субпанели в 6.2, но я еще не тестировал, если это дает лучшие результаты на этом примере (я полагаю, это будет), что может привести к тому, что пользовательский перенос фабрики станет устаревшим.