1)
The Need For Optimisation and Mathematical Programming
Methods
top
 |
 |
|
|
|
||
 |
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
 |
|
| PWSC's Modelling Philosophy & Application | ||||||||||||||||||||||||||
Development
of PWSC software has been guided by a number of underlying
concepts, beliefs and principles resulting from many
years experience in the analysis of 'real' systems
and the application of mathematical programming techniques.
The main components of this 'modelling philosophy'
are outlined below, together with the ways in which
our software strives to meet these objectives. |
||||||||||||||||||||||||||
(i) Optimisation
is necessary so as to ensure that alternative operating
policies or system development plans are directly comparable
in terms of meeting specified demands with the same
levels of supply security.
(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.
|
||||||||||||||||||||||||||
(i) When
evaluating the operation of existing or proposed water
resource based systems, it is essential that adequate
consideration must be given to the effects of the 'persistence'
exhibited by historic flow series, particularly low
flow sequences.
(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.
|
||||||||||||||||||||||||||
(i) System
performance should be quantified in terms of criteria
that are comprehensible by lay people as well as 'experts'.
Thus, esoteric concepts such as '2% droughts' or 'firm
energy' should be avoided whenever possible.
(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.
|
||||||||||||||||||||||||||
(i) The
time step used in the Simulation Model should be short
enough to ensure that seasonal hydrological and cost
variations are adequately considered.
(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.
|
||||||||||||||||||||||||||
(i) The
workings of complex computer programs should be as
transparent as possible, so as to aid both user understanding
and future development.
(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.
|
||||||||||||||||||||||||||
(i) While
programs should ideally be generalised, i.e. data driven,
rather than 'bespoke', i.e. system specific, the development
of generalised programs is more complex and time consuming.
(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.
|
||||||||||||||||||||||||||
(i) While
a high-level of 'user friendliness' is desirable, it
should not take precedence over providing the flexibility
required to model 'real world' system characteristics
and complexities.
(ii) The true value of computer programs lies in the integrity of the underlying concepts and calculations, rather than its cosmetic appearance.
|
||||||||||||||||||||||||||
(i) New
software developments should seek to fill perceived
needs in the market place and incorporate improved
methodologies in terms of accuracy and optimality.
(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.
|
||||||||||||||||||||||||||
(i) While
every effort should be made to eliminate program 'bugs'
during development it is recognised that, as with all
complex software, malfunctions may from time to time
become apparent.
(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.
|
||||||||||||||||||||||||||
