For discrete resources, discrete energy, and state resources, you can define transition times. Given two activities A1 and A2, the transition time between A1 and A2 is an amount of time that must elapse between the end of A1 and the beginning of A2 when A1 precedes A2.

Transition times are taken into account when the disjunctive constraint, the precedence graph constraint, or the type timetable constraint on a resource are posted. Note however, that the disjunctive constraint does not exist on reservoirs and discrete energy resources.

The precedence graph constraint propagates transition time based on the following precedence relation: If A2 is a successor of A1 on the precedence graph, then the transition time between A1 and A2 is propagated.

Propagation of transition times is not handled the same way for a disjunctive constraint as for a type timetable constraint.

The first difference is the definition of which activities are incompatible. Although both the disjunctive constraint and the type timetable constraint propagate transition times only between activities that are incompatible, the disjunctive constraint defines incompatibility based on the resource demand, and the type timetable constraint defines incompatibility based on the transition types of activities. Therefore care must be taken, especially with discrete and state resources, when choosing which constraint to use. We advise using the type timetable to propagate transition times on discrete resources, because it is very possible that no pair of activities will be incompatible based on their resource demands.

A second difference is that the disjunctive constraint propagates transition times more than the type timetable constraint. Expressing transition times with a type timetable constraint is therefore less CPU-time consuming, especially when the number of activities is large.

Here is an example to illustrate the extra propagation performed by a disjunctive constraint. Suppose two activities A1 and A2 have a duration of 4, A1 is to be executed between 0 and 14 and has type 0, A2 executes between 4 and 21 and has type 1, and they both require the same unary resource. The transition time between these activities is symmetric and is equal to 3. The disjunctive constraint will deduce that A2 must start from at least time 7 since A2 cannot be scheduled before A1. The type timetable constraint will not make that deduction.

If we look at activity A1, we could in principle remove type 1from the interval [lst - 3, ect + 3), where lst stands for latest start time of A1, ect for earliest completion time of A1, and 3 is the transition time. With lst for A1 equal to 10 and ect equal to 4, we see this rule will not result in the actual removal of type 1 from a time interval. Similar reasoning holds for activity A2.

You can define the transition time function of a resource by passing an instance of the class IlcTransitionTimeObject to the constructor of the resource, or by calling the member function IlcResource::setTransitionTimeObject. To have the type timetable constraint propagate the transition times, the instance of IlcTransitionTimeObject must have been built with an instance of the class IlcTransitionTable. When you build the transition time object that way, the propagation of the disjunctive constraint or the type timetable constraint automatically takes transition times into consideration. However, activities with a type not represented in the instance of IlcTransitionTable are not affected by the transition times of other activities.

With the member function IlcResource::getTransitionTime you can inspect the transition time between two activities that require the invoking resource. This member function accepts two resource constraints as arguments and returns the transition time between the two corresponding activities. By default (that is, when transition times are not defined), the member function returns zero (0).

Scheduler Engine associates an integer transition type with each activity. The accessors are the functions IlcActivity::getTransitionType and IlcActivity::setTransitionType. They allow you to define instances of IlcTransitionTimeObject from integer tables where the rows and columns are indexed by the transition types.

There are some restrictions when the transition times are taken into account by the type timetable constraint:

• The type timetable constraint alone does not propagate suspended transition times (See Calendars). Suspended transition times can be propagated by creating a precedence graph constraint or (on a unary or state resource) a disjunctive constraint.
• The instance of IlcTransitionTimeObject that defines the transition time for the resource must have been built with an instance of IlcTransitionTable.
• Only resource constraints with a time extent equal to IlcTimeExtent::IlcFromStartToEnd are taken into account. Resource constraints having a time extent different from IlcTimeExtent::IlcFromStartToEnd are ignored.
• The resource cannot be durable.

See Also

IlcDiscreteEnergy, IlcDiscreteResource, IlcMakeTransitionTime, IlcStateResource, IlcTransitionTable, IlcTransitionTime, IlcTransitionTimeObject, IlcUnaryResource, Disjunctive Constraint, Type Timetable Constraint, Precedence Graph Constraints