0

I am working on a variation of the Task scheduling problem. Here are the rules:

  • Each Task has a start time to be chosen by the optimizer
  • Each Task requires multiple types of resources (Crew Members) who work in parallel to complete the task. i.e the task can start only when all required types of crew members are available.
  • There are multiple crew members of a certain type and the optimizer has to choose the crew member of each type for a task. Eg Task A requires an Electrician and a Plumber. There are many electricians and plumbers to choose from.

Here is my domain. I have created a planning entity called TaskAssignment with 2 planning variables CrewMember and Starttime. So, if a Task requires 3 types of crew members, then 3 TaskAssignment entities would be associated with it.

I placed a hard constraint to force the Starttime planning variable to be same for all the TaskAssignments corresponding to a particular task.

This works perfectly when I do not add any soft constraints (For example to reduce the total cost of using the resources). But when I add the soft constraint, there seems to be a violation of 1 hard constraint.

My guess if that this is due to a score trap because the starttimes are not changing as a set.

Note: I have tried to avoid using the PlanningList variable. Can anyone suggest a way to solve this issue ?

1 Answers1

0

Your issue appears to be that your scoring function expects all employees on a given task to move simultaneously, but the solver actually moves them one by one. This is a problem in your domain model - it allows this situation to happen, because you only ever assign one employee at a time.

There are two ways of fixing this problem:

  1. Fix your model, so that this is not allowed. For example, if you know that each task requires two people, let there be two variables on the entity, one for each employee. If there is a certain maximum of people per task, have a variable for each, and make them nullable, so that unassigned slots are not an issue. If you don't have a fixed amount of employees per task and you can not get to a reasonable maximum, then this approach will likely not work for you. In that case...

  2. Write coarse-grained custom moves which always move all the employees together.

Lukáš Petrovický
  • 3,945
  • 1
  • 11
  • 20