listmodelingoptaplannertimefold

Modelling an arbitrary (but fixed) number of independent planning varibales in Timefold?


I'm assigning rooms to lessons in my schedule generator. My current model looks like this:

@PlanningEntity
class Lesson {
    ...
    @PlanningVariable(allowsUnassigned = true)
    Room room;

    Set<String> requiredRoomAttributes;
    ...
}

class Room {
    Set<String> attributes;
}

However, I need to change it so that each lesson can have an arbitrary (but fixed) number of rooms. (In the user interface the user can specify that a lesson needs three rooms with three different set of required attributes.)

(A @PlanningListVariable does not seem suitable here since each room can be assigned to multiple lessons as long as the lessons don't collide in time.)

A natural way to model this would be something like:

@PlanningEntity
class Lesson {
    ...
    Set<RoomAssignment> roomAssignments;
    ...
}

class RoomAssignment {
    ...
    Room room; // null until room has been assigned
    Set<String> requiredRoomAttributes;
    ...
}
    
class Room {
    Set<String> attributes;
}

I'm puzzled though because I'm not sure where to put the @PlanningVariable annotation. I assume it must be on the entity, but it's only the room (not the requiredRoomAttributes that is the actual variable).

This leads me to believe that this is a better modelling:

@PlanningEntity
class Lesson {
    ...
    @PlanningVariable
    List<Room> rooms;

    // The i:th set represents the requirements for the i:th room
    List<Set<String>> requiredAttributes;
    ...
}

class Room {
    Set<String> attributes;
}

Question 1: Is this the recommended way to model this problem, or is there a better way?

Question 2: Is there any chance any built in move selector could be used to update individual elements in List<Room> rooms, or should I go ahead and write custom move selectors?

Question 3: Correct me if I'm wrong, but I feel like Timefold internally probably could handle an arbitrary (but fixed) list of independent variables. Has this ever been considered? For example something like:

@PlanningEntity
class Lesson {
    @PlanningVariableArray
    Room[] rooms = new Room[10];
}

Solution

  • Question 1: Since "each lesson can have an arbitrary (but fixed) number of rooms", I would model it like this

    class Lesson {
        Set<RoomAssignment> roomAssignments;
    }
    
    @PlanningEntity
    class RoomAssignment {
        ...
        @PlanningVariable
        Room room; // null until room has been assigned
        Set<String> requiredRoomAttributes;
        ...
    }
        
    class Room {
        Set<String> attributes;
    }
    

    so the planning entity is now room assignment instead of the lesson.

    Question 2: With the model I used in my answer to Question 1, all built-in move selectors will work.

    Question 3: Generally speaking, arbitrary (but fixed) variables are handled with the "element is entity" strategy that is used in my answer to Question 1. This strategy has the additional benefit of making it easier to write incremental constraints (since you don't need to iterate a collection or array to check the planning value of an entity).