0

I successfully amended the nice CloudBalancing example to include the fact that I may only have a limited number of computers open at any given time (thanx optaplanner team - easy to do). I believe this is referred to as a bounded-space problem. It works dandy.

The processes come in groupwise, say 20 processes in a given order per group. I would like to amend the example to have optaplanner also change the order of these groups (not the processes within one group). I have therefore added a class ProcessGroup in the domain with a member List<Process>, the instances of ProcessGroup being stored in a List<ProcessGroup>. The desired optimisation would shuffle the members of this List, causing the instances of ProcessGroup to be placed at different indices of the List List<ProcessGroup>. The index of ProcessGroup should be ProcessGroup.index.

The documentation states that "if in doubt, the planning entity is the many side of the many-to-one relationsship." This would mean that ProcessGroup is the planning entity, the member index being a planning variable, getting assigned to (hopefully) different integers. After every new assignment of indices, I would have to resort the list List<ProcessGroup in ascending order of ProcessGroup.index. This seems very odd and cumbersome. Any better ideas?

Thank you in advance!

Philip.

UML class diagramm of domain

Philip Harding
  • 392
  • 1
  • 10
  • Would you mind including an napkin UML drawing of your class diagram in the question? In reading text that second paragraph is hard to grok. – Geoffrey De Smet Jan 21 '15 at 12:32
  • @Geoffrey: I have put the intended UML class drawing in https://imageshack.com/i/ex3lg4p5j. Basically, all I want to do is to amend the sequence of processes as they are stored in a list 'processList = List'- just not by process, but by groups of processes. – Philip Harding Jan 23 '15 at 08:34
  • Thanks. Please explain the purpose of the ProcessGroup constraint more tangibly in the question (see my guessing answer below). – Geoffrey De Smet Jan 26 '15 at 08:52
  • I have now explained the constraint more clearly (I hope). – Philip Harding Jan 28 '15 at 08:37

1 Answers1

0

The current design has a few disadvantages:

  • It requires 2 (genuine) entity classes (each with 1 planning variable): probably increases search space (= longer to solve, more difficult to find a good or even feasible solution) + it increases configuration complexity. Don't use multiple genuine entity classes if you can avoid it reasonably.
  • That Integer variable of GroupProcess need to be all different and somehow sequential. That smelled like a chained planning variable (see docs about chained variables and Vehicle Routing example), in which case the entire problem could be represented as a simple VRP with just 1 variable, but does that really apply here?

Train of thought: there's something off in this model:

  • ProcessGroup has in Integer variable: What does that Integer represent? Shouldn't that Integer variable be on Process instead? Are you ordering Processes or ProcessGroups? If it should be on Process instead, then both Process's variables can be replaced by a chained variable (like VRP) which will be far more efficient.
  • ProcessGroup has a list of Processes, but that a problem property: which means it doesn't change during planning. I suspect that's correct for your use case, but do assert it.

If none of the reasoning above applies (which would surprise me) than the original model might be valid nonetheless :)

Geoffrey De Smet
  • 26,223
  • 11
  • 73
  • 120
  • Yes, the current design certainly has these disadvantages. The problem does indeed smell like chain spirit... It is a great idea to substitute this awkward 'Integer index' solution with a chained variable approach, I hadn't thought of that. The only disadvantage of the chained approach is that I would have to chose an anchor (like 'Domicile'), which is a bit quirky. I will try implementing the problem as one genuine entity class 'Process' and one normal class 'ProcessGroup', the former having the PlanningVariable 'Computer', the latter having a chained variable a la 'previousStandstill'. Thx – Philip Harding Jan 28 '15 at 08:55