"Share" entity between multiple planning variables

[luxaritas]

I have a problem where I have the following situation:

class Configuration:
  cpus: Annotated[int, PlanningVariable]
  memory: Annotated[int, PlanningVariable]

class Job:
    configuration: Annotated[Configuration, PlanningVariable]

I'm allocating a set of jobs and optimizing the resources requested for each job. However, I want to limit the number of distinct resource configurations. However in the above, a configuration cannot be assigned to more than one job (as far as I know, timefold does not allow for planning entities to be shared/reused/assigned to multiple planning variables). I can imagine doing this a couple ways:

1. Use a limited number of Configuration instances, and instead of configuration: Annotated[Configuration, PlanningVariable], assign each configuration an ID and use configuration: Annotated[int, PlanningVariable] such that it chooses an ID. This seems hacky.
2. Use one configuration instance for each job (or merge into job itself), and implement a constraint that counts how many unique configurations are present. I'm concerned that due to the large potential range of something like memory (in addition to a potentially relatively high number of jobs vs configurations), that this would incur poor performance or otherwise cause poor optimization.

Any recommendations for how best to approach this? Thanks!

[triceo]

Hello @luxaritas,

Problems with multiple variables are generally more difficult to solve with Timefold Solver. They require non-trivial configuration, and sometimes produce optimization challenges for the solver. Preferrably, they should be avoided.

To that end, I do not understand why the Configuration needs to be an entity. Typically, in problems with just basic planning variables, we do not assign entities to other entities. If you make your configuration a planning fact and provide a range of suitable Configurations, many of your problems will go away. Including some which you may not know that you have yet. :-)

This would be most similar to your approach 1, but you don't need the ID at all. You can just return a list of configurations as a value range, and the solver will use those directly.

(As a side note: There should be no problem with one entity being assigned to multiple variables. List variable doesn't allow it, because the semantics there are that all values need to be assigned exactly once. But basic variable doesn't have this restriction.)

[luxaritas]

I could provide a set of configurations, but that doesn't solve my problem in this case. To get more detailed: I'm submitting jobs to a compute cluster where I can granularly request CPU, RAM, max timeout, etc and then assign multiple tasks I need to run to each job submitted with this configured set of resources.

Thinking out loud here... if there is 0 - 128 GB of RAM, with a step of 2 GB, that makes 64 values. Not too many. If you do the same for CPU, timeouts etc., that will make for tens or hundreds of thousands of combinations. With entity-based value ranges, that can even be filtered - if a job requires 8 GB of RAM at a minimum, we can eliminate 2 and 4 before they even reach the solver. If you generate those collections ahead of time and return them as a constant, it will take a bit of extra memory, but it won't affect solver performance.

Most importantly - the resulting configuration will still be a single variable. And that will make configuring the solver significantly easier. The unlimited granularity which you'd be able to achieve with the original approach may seem desirable at first, but it often proves unnecessary.