5.3 Approximate model solution approach
5.3.2 Simulated annealing implementation
This section contains a description of the particular implementation of the SA algorithm em- ployed in this dissertation to obtain high-quality solutions to instances of the GMS models of §4.3. The section includes a discussion on the method of determination of initial solutions and the choice of an initial temperature for the algorithm, the cooling and reheating schedules employed, the constraint handling technique adopted, the epoch management protocol implemented, the neighbourhood move operator used and the termination criteria selected.
The initial solution
An initial solution is required in order to initialise the SA algorithm. The implementation of the SA algorithm employed in this dissertation randomly generates an initial solution. This is achieved by generating a random feasible maintenance commencement date, based on a uniform distribution, for each PGU within the maintenance window of that PGU.
The choice of initial temperature
In 1987, van Laarhoven et al. [211] presented a method for calculating an appropriate value for the initial temperature T0, called the average increase method. The value of the initial
temperature may be determined from the so-called initial acceptance ratio χ0 = exp −∆E T0 , (5.22)
where ∆E is the average deterioration in objective function values (i.e. change in energy) of the system and where χ0 is the acceptance ratio during a pre-solution random walk through
the solution space, starting from the randomly generated initial solution. This yields the initial temperature as
T0 = −
∆E ln(χ0)
. (5.23)
The initial acceptance ratio χ0 in (5.23) is the number of accepted solutions which exhibit a
deterioration in objective function value divided by the number of attempted solutions which exhibit a deterioration in the objective function value during the pre-solution random walk. This ratio is typically set to a value between 0.5 and 0.8, as suggested by Busetti [38]. The length (number of iterations) of the pre-solution random walk is selected as 1 000 in this dissertation, using the initial solution as the starting point of the random walk. A pseudo-code description of the procedure for determining the initial temperature is given in Algorithm 5.1.
Algorithm 5.1: Determining initial temperature
Input : The initial solution matrix, the initial objective function value, the length of the pre-solution random walk, the acceptance percentage and a full data set
specifying an instance of one of the models of§4.3.
Output: The initial temperature calculated using the average increase method. counter ← 0; 1 CurrentObjValue ← InitialObjValue; 2 for i ← to WalkLength do 3 PreviousObjValue ← CurrentObjValue; 4 xxx ← EjectionChain (xxx); 5 CurrentObjValue ← ObjValue (xxx); 6
ChangeInEnergy ← PreviousObjValue − CurrentObjValue;
7
if ChangeInEnergy > 0 then
8
counter ← counter +1;
9
Increases [counter ] ← ChangeInEnergy;
10
ObjValueArray [counter ] ← CurrentObjValue;
11
InitialTemperature ← −mean(Increases)/log(AcceptPercentage);
12
return InitialTemperature
13
The method of constraint handling
The constraints included in the GMS models of §4.3 are either implemented as hard or soft constraints in the SA algorithm. More specifically, the maintenance window constraints and the maintenance duration constraints are implemented as hard constraints. Therefore, solutions
which violate any of these constraints are considered to be infeasible, and are therefore not acceptable during the search. The remaining constraints (the demand constraints, the resource availability constraints, the exclusion constraints and the precedence constraints) are all imple- mented as soft constraints. A solution which violates one of these constraints is considered to be feasible, but the objective function value of such a solution is penalised by a certain value so as to allow the SA search to pass through infeasible areas of the solution space, but discouraging it from remaining there.
A multiplicative penalty function approach is adopted in this dissertation to accommodate soft constraints of the GMS models. This approach involves penalisation of the objective function for a violation of a soft constraint by the magnitude of the violation via multiplication [190]. Consider, for example, a soft constraint set of the form
gi(xxx) ≤ Gi, i = 1, . . . , s,
where Gi is a constant limiting value, which is strictly positive, for the i-th soft constraint and
s is the number of soft constraints [190]. A total scaled constraint violation value G(xxx) = s X i=1 max 0,gi(xxx) − Gi Gi
may be calculated for the set of constraints. The scheduling criterion which seeks to minimise the probability of unit failure, presented in §4.3.2, involves minimisation. The objective function in (4.6) is furthermore always positive. Therefore, the multiplicative penalty function for a minimisation problem
φ−(xxx) = exp [γ(G(xxx))]
is adopted in the case of the linear GMS model of §4.3, where γ is a severity factor which is typically determined empirically. The penalised objective function for the minimisation problem may then be calculated as
Z(XXX) × φ−(xxx), (5.24)
where Z(XXX) is as defined in (4.6). The product in (5.24) is minimised in an attempt to find the best feasible solution during the SA search.
The alternative scheduling criterion which seeks to maximise the expected energy production, also presented in §4.3.2, involves maximisation. Moreover, the objective function in (4.12) is also always positive. Therefore, the multiplicative penalty function for a maximisation problem
φ+(xxx) = 2 − exp [γ(G(xxx))]
is adopted in the case of the nonlinear GMS model of§4.3. The penalised objective function for the maximisation problem may then be calculated as
Z0(XXX) × φ+(xxx), (5.25)
where Z0(XXX) is as defined in (4.12). The product in (5.25) is maximised in an attempt to find the best feasible solution during the SA search.
The epoch management protocol
Busetti [38] argued that the number of iterations spent in a single SA epoch k should be problem- dependent, rather than being a function of k. A Markov chain3 of length Lk may of course be
3
A sequence of possible events described by a stochastic model in which the probability of an event occurring only depends on the state attained during the previous event [218].
used to determine the number of iterations during epoch k. Ideally, however, one would rather prefer to specify a minimum number Aminof move acceptances during any epoch before lowering
the temperature and moving on to the next epoch. A problem with this approach is that as the temperature Tkapproaches zero, the probability of accepting non-improving solutions decreases
which, in turn, increases the expected number of iterations required to achieve the required Amin
move acceptances per epoch. Therefore, an epoch is terminated once a certain number L of moves have been attempted, by reheating the temperature of the system to the initial temperature or according to some reheating schedule, or alternatively by decreasing the temperature according to a cooling schedule once Amin moves have been accepted, where Amin and L are pre-specified
parameters satisfying Amin < L. Dreo et al. [62] proposed that Amin = 12N and L = 100N ,
where N is a measure of the number of degrees of freedom in the problem instance, taken here as the number of PGUs in the system (i.e. N = n).
In order to determine the most effective length of an epoch for a given GMS problem instance, an epoch parameter is additionally introduced here. The epoch parameter is incorporated into the above epoch termination criteria by instead taking Amin = 12n/ψ and L = 100L/ψ in this
dissertation. The epoch parameter is determined by an extensive parameter evaluation for each instance of the GMS problem. The ratio of Amin to L is, however, taken as proposed by Dreo
et al. [62].
The cooling and reheating schedules
The geometric cooling schedule in (2.48) is implemented within the SA algorithmic implementa- tion in this dissertation. This cooling schedule has proved to be very successful in solving various GMS problem instances in the literature [2, 127, 188, 189]. The geometric cooling schedule is also very easy to implement and converges to good solutions within a reasonable amount of computation time. The value of the cooling parameter α which appears in this schedule is de- termined during an extensive parameter evaluation for each of the problem instances considered later in this dissertation.
The reheating schedule adopted in the SA algorithmic implementation of this dissertation is based on a similar approach to that followed in the geometric schedule. Once L moves have been attempted during a single epoch without reaching the required Amin accepted moves, the
temperature of the system is reheated. In such a case, the temperature is reheated according to the schedule
Tk+1 =
Tk
ξ , k = 0, 1, 2, . . . , (5.26)
where ξ is the reheating parameter, which is also determined by an extensive parameter evalua- tion for each instance of the GMS problem considered.
The neighbourhood move operator
The neighbourhood move operator implemented within the SA algorithmic implementation of this dissertation is the well-known ejection chain move operator [188, 189], which involves gen- erating a list of PGUs whose maintenance period commencement times are altered randomly in succession within their allowable maintenance windows. More specifically, a PGU is selected randomly after which its maintenance commencement time is moved randomly without violating the maintenance window constraint of that PGU. Another PGU, whose planned maintenance is scheduled to start during the newly allocated maintenance time of the initially selected PGU is next selected randomly and its maintenance commencement time is moved to a random time
within the maintenance window of that PGU. This process is repeated until either of the follow- ing stopping criteria is met: no maintenance of a PGU is scheduled to start during the newly allocated maintenance time of the latest selected PGU in the sequence or chain, or a PGU in the chain has a maintenance starting time that corresponds to the initial starting time of the PGU that was initially selected to initiate the ejection chain. A graphical representation of the ejec- tion chain neighbourhood move operator is shown in Figure 5.6, with Figure 5.6(a) containing an indication of the state of the schedule before the ejection chain is applied and Figure 5.6(b) containing an indication of the state of the schedule after the ejection chain has been applied. This neighbourhood move operator is affected by the implementation of Algorithm 5.2.
1 2 3 4 5 6 7 8 9 10 11 12 Time period 1 2 3 4 5 PGU (start)
(a) Maintenance schedule before applying the ejection chain move operator
1 2 3 4 5 6 7 8 9 10 11 12 Time period 1 2 3 4 5 PGU (start)
(b) Maintenance schedule after having applied the ejection chain move operator
Figure 5.6: Graphical representation of a small, hypothetical GMS before and after applying the ejection chain move operator to the corresponding decision matrix.
In other implementations of the method of SA within the context of GMS, a more basic move operator, often referred to as the classical move operator, has been implemented, which involves merely selecting a PGU randomly (according to a uniform distribution) and randomly moving the maintenance commencement time of the selected PGU to a new point in time within the
Algorithm 5.2: Ejection chain move operator
Input : The current solution matrix, the number of PGUs in the system, as well as earliest and latest starting times for the maintenance of each PGU.
Output: A new solution vector after having applied the ejection chain neighbourhood move operator to the current solution matrix.
ListOfMoves ← ∅; 1 MovingUnit ← rand(NumberOfUnits); 2 ListOfMoves [1] ← MovingUnit; 3 while i ← 1 to ( NumberOfUnits- 1) do 4 TempUnitList ← ∅; 5
SolutionVector [MovingUnit ] ← randBetween(EarliestStartTime, LatestStartTime);
6
TempNewTime ← SolutionVector [MovingUnit ];
7
for counter ← 1 to NumberOfUnits do
8
if TempNewTime == SolutionVector [i] then
9
TempUnitList [counter ] ← i;
10
counter ← counter + 1;
11
TempUnitList ← TempUnitList [!TempUnitList %in% MovingUnit ];
12 Len ← length(TempUnitList); 13 if Len == 0 then 14 Break 15
MovingUnit ← TempUnitList [randBetween(1,counter- 1)];
16
i ← i + 1;
17
ListOfMoves [i] ← MovingUnit;
18
return SolutionVector
19
maintenance window of that PGU [188, 189]. Due to the localised nature of the classical move operator, its use may pose difficulties for the algorithm in terms of escaping from local optima. Comparisons of the classical move operator with the ejection chain operator described above have shown that the ejection chain operator outperforms the classical move operator in most GMS problem instances [188] and therefore the ejection chain move operator is the only move operator implemented within the SA implementation of this dissertation.
End-of-search termination criteria
The implementation of the SA algorithm adopted here is subject to two termination criteria. The primary termination criterion corresponds to when the system is said to be in a frozen state. Once three consecutive reheats have occurred, the system is considered frozen, as Amin
accepted solution could not be found for three consecutive epochs during the search. A sec- ondary termination criterion is implemented only to ensure that the algorithm does not exceed a computation time of eight hours. The reason for choosing an 8-hour timeout period is that the calculations may thus be completed overnight. This timeout period was verified as sensible by Mr Bhongo Mdunge [157], a production assurance manager of the national power utility of South Africa, Eskom, through personal communication.
Once the SA algorithm has terminated, the best solution encountered during the entire search is returned for the given instance of one of the GMS models of §4.3, along with a graphical representation of the corresponding maintenance schedule.