

Operating
Policy Optimisation

Optimised
System Operating Policy

Interactive
Model Construction

Mimic
Diagram Display of Results

User
Friendly Data Input
(ii) For systems or operating policies of any complexity, 'manual optimisation' based on repetitive simulation is unrealistic due to the number of interdependent variables involved; some form of mathematical programming algorithm is normally required in order to obtain the 'optimal' solution.
(iii) The optimisation method employed should reflect the nature of the problem to be solved, rather than tailoring the problem to comply with the limitations imposed by a particular method.
(ii) For systems of any complexity, the effects of spatial and temporal stream flow variations can only be adequately modelled by employing a simulation model with an appropriately short time step.
(iii) Availability of a detailed simulation model is a pre-requisite for properly evaluating the performance of any 'optimised' operating policy or planned system configuration.
(iv) Such simulation models must be capable of representing the behaviour of the system to the satisfaction of those with practical knowledge of its characteristics, and of simulating both existing and alternative operating policies.
(v) While many practitioners have advocated the combined use of simulation and optimisation models, it is also necessary to specify how they should be linked together.
(ii) Given the uncertainties associated with the economic derivation and justification of penalty functions applied to unsatisfied demands, it is preferable to measure supply security in terms of the imposition of supply restrictions of quantified severity and acceptable socio-economic effect.
(ii) The Simulation Model should preferably enable the user to investigate the use of different time steps, so as to evaluate the relationship between increased accuracy and execution times.
(iii) The time step used in the Optimisation Model should reflect the practicalities of operating policy implementation as well as hydrological and cost variations.
Time Step |
Reservoir Contents |
Relative |
||
Cost |
Reliability |
Speed |
||
Daily |
![]() |
100 |
95 |
100 |
Weekly |
![]() |
90 |
98 |
30 |
Monthly |
![]() |
80 |
100 |
10 |
(ii) Such transparency requires the detailed monitoring of program inputs, intermediate and final results in annotated file form for presentation and archiving purposes.
(iii) Understanding of results and simulated system performance is greatly aided by the graphical display of results, either in plot or 'mimic' diagram form.

(ii) Many systems exhibit 'unique' features which must be adequately modelled if an adequate representation of the system is to be obtained. It is thus inevitable that the capabilities of 'generalised' programs may, from time to time, need to be enhanced.
(ii) The true value of computer programs lies in the integrity of the underlying concepts and calculations, rather than its cosmetic appearance.
(ii) Advances in programming languages should be exploited in the interests of improved execution performance and user friendliness.
(iii) Program architecture and the choice of methodology incorporated should reflect advances in computer performance, in terms of both processor and data storage capabilities.
(ii) Due to the nature of the systems being analysed, no guarantees can be given regarding 'fitness of purpose' or against consequential losses arising from program applications.