The Scheduler API allows you to model scheduling problems without any assumptions on the way a solver will produce a solution. Scheduler is used to build a problem definition; modeling objects are extracted from the problem definition to the solver; and the solver uses the extracted objects to solve all or part of the problem. When used with Solver, the extraction of the modeling classes first creates corresponding instances of classes in another layer; this layer is Scheduler Engine. Scheduler Engine is specific to Solver solution techniques. The Scheduler extractor is the object that interprets the problem definition objects and creates the Schedule Engine objects for solving the problem. As with the Scheduler Engine, the Scheduler extractor is specific to Solver solution techniques.

At extraction time, the Scheduler Engine instances are created and initialized given the data in the parameters of the Scheduler instances. If a model element is changed, and if a Scheduler Engine object is concerned by this change, a re-extraction will occur before the next Solver search phase. The incorporation of changes to the model, during search, follows the same protocol as Solver: unless otherwise stated, no model changes will be taken into account until the next Solver search phase. See the IBM ILOG Solver Reference Manual for more details.

A benefit of the modeling concept and parameter framework of Scheduler is that it allows users to manage large scheduling problems with light memory usage. Scheduler classes have a lighter memory usage than the corresponding classes in Scheduler Engine.

The following table indicates the correspondence between Scheduler classes and Scheduler Engine classes. The Scheduler classes listed are extracted to the corresponding Scheduler Engine classes.

Class Correspondence Between Scheduler and Scheduler Engine

There are some Scheduler Engine classes that do not have counterparts in Scheduler because the Scheduler Engine API is very specific to Solver techniques. Examples include the break lists (instances of the class IlcBreakList), and the timetable (instance of subclass of IlcIntTimetable and IlcAnyTimetable). These classes are actually Solver objects involved in the global constraints and whose contents represent functions defined over the time axis.

The time axis is represented in Scheduler with a numerical integer type, a data of type IloNum or instances of class IloNumVar. The break list and timetables are modeled in Scheduler with a set of parameters on the resources whose content is a function on the integer time axis.

The following Scheduler classes are used in modeling break lists and timetables. Note that IloNumToAnySetStepFunction, IloNumToNumStepFunction, IloNumToNumSegmentFunction, and IloIntervalList are documented in the extensions section of the IBM ILOG Concert Technology Reference Manual.

IloIntervalList : Breaks list, definition interval of the set of timetables on a resource, must-be-in-use constraint on a state resource.

IloNumToAnySetStepFunction : Maximal set of states of the timetables of an instance of IlcStateResource.

IloNumToNumStepFunction : Maximal and minimal capacity, initial content of a capacity resource.

IloNumToNumSegmentFunction : Maximal and minimal capacity, initial content of a continuous reservoir.

The function type definitions, enumerations, and some classes of Scheduler Engine are designed only for writing search goals or constraint propagation functions. Examples include the following:

• IlcResourceIterator, IlcActivityDeltaIterator and any type of iterators on the Solver object involved in the problem.
• IlcActivityIteratorFilter and all other enumerations used by iterators.
• IlcResourceSelectorObject and any selector, evaluator, or predicate object used in the Solver search procedure.
• Any instance of a subclass of IlcDemon.

Since these classes are not related to modeling, they do not have any counterpart in Scheduler.

Pure Scheduler classes are classes or enumerations designed for the parameterization of the basic model objects. These classes are only taken into consideration at extraction time in order to create the related constrained data structure. Changing this object will lead to a re-extraction if required.

Examples include IloActivityBreakParam, IloNumToNumStepFunction (see IBM ILOG Concert Technology Reference Manual), and IloEnforcementLevel.

In order to implement the propagation of global constraints, to write heuristic selectors and goals, and to let the user define constraints, the Scheduler Engine object may automatically create Solver variables or data structures. As these constrained objects are useless in the initial model, they are not created in the Scheduler model, but only at the beginning of the search.

The Solver variables created, and their corresponding Scheduler Engine classes, are shown in the following table.

Solver Variables and their Corresponding Scheduler Engine Class

The data structures used in the global constraint of the resource are the timetables and the precedence graphs.

Global constraints are algorithms that enforce the conditions on the set of resource constraints declared on a resource. Different global constraints can be selected to enforce the same constraint. For example, the maximum capacity limitation on a unary resource can be enforced by the timetable constraint, the disjunctive constraint, or the edge finder algorithm.

This notion is very specific to constraint programing techniques, therefore there is no direct way to explicitly declare which Solver global constraint to use at the Scheduler model level.

There are two ways for the Scheduler Engine extractor to determine which global constraint to add to the algorithm. These two methods are described in Adding Global Resource Constraints from the Scheduler Model.

The Scheduler Engine and Scheduler APIs are very similar. For example, the read accessors on objects are the same, but the argument types and return values are different. Compare the following:

IloNumVar IloActivity::getStartVariable() const;
IlcIntVar IlcActivity::getStartVariable() const;
IloBool IloActivity::isBreakable() const;
IlcBool IlcActivity::isBreakable() const;

The main difference lies in the fact that Scheduler is a pure modeling API, with no restrictions on editing capabilities; whereas Scheduler Engine must respect the properties of Solver. That is the reason that only monotonic accessors are allowed during the search.

void IloActivity::setBreakable(IloBool breakable) const;
void IloActivityBasicParam::setBreakable
                            (IloBool breakable) const;
void IlcActivity::setBreakable(IlcBool breakable);

The last function always applies before entering the search. During Solver search it is forbidden to set an activity to be breakable. The same type of arguments holds for the following:

void IloResourceConstraint::setNext
                    (const IloResourceConstraint& next) const;
void IloResourceConstraint::unsetNext() const;
void IlcResourceConstraint::setNext
                    (IlcResourceConstraint next);
void IlcResourceConstraint::unsetNext() const;

The last function is not valid during the search because it is non-monotonic.

Some API elements may have the same purpose, and apply to corresponding classes, but have a slightly different semantics in Scheduler and Scheduler Engine. For example:

void IloResource::keepOpen(IloBool open);
void IlcResource::close();

The first function (with an argument of IloTrue) specifies that not all the resource constraints are declared in the model and that therefore, the solver should allow the addition of new resource constraints during search. The second function specifies that the IlcResource is closed; that is, that it is not kept open during the search.

Nevertheless, the second function is such that the instance of IlcResource cannot be reopened, even when outside the search. When the function IloResource::keepOpen is called on the model resource, a re-extraction of the resource is required and the resource will not be closed during the next search.

A parameter object in Scheduler can be used to model data for multiple Scheduler Engine classes. For example, IloIntervalList is used to store data for both IlcBreakList and IlcIntTimetable. The IloIntervalList API has a natural correspondence to the API of the Scheduler Engine objects. For example, if the instance of IloIntervalList is used to define the break list of a resource, the following API:

void IloIntervalList::addInterval(IloNum start, IloNum end,
                                  IloNum type = 0) const;
void IloIntervalList::removeInterval
                              (IloNum start, IloNum end) const;

corresponds to:

void IlcBreakList::addBreak(IlcInt start, IlcInt end,
                            IlcInt type = 0);
void IlcBreakList::removeBreak(IlcInt start, IlcInt end);

on the corresponding instance of IlcBreakList.

If the instance of IloIntervalList is used to define the set of timetables on a resource, these accessors will set up the definition of the timetable constraints. That determines the time interval definition of the instance of IlcIntTimetable managed by the global capacity resource constraint.

IloIntervalList is documented in the extensions section of the IBM ILOG Concert Technology Reference Manual.

As Solver is based on constraint programing, the interpretation of the Scheduler model is quite natural. However, some functions of Solver cannot be easily accessed by Scheduler. This is mainly related to writing code dependent upon the current state of the data in the Solver. So, to access these functions of Solver, the user must use Scheduler Engine to implement the code. Examples of this include extending or creating constraints and demons, or extending or creating search goals. Examples of some of the Scheduler Engine functions offered for this purpose are shown in the following table.

Accessing Certain Solver Functions