UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Real-time fuzzy logic control of combined sewer flows Tamaki, Robert Dean 1994

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata


831-ubc_1994-0142.pdf [ 6.46MB ]
JSON: 831-1.0050423.json
JSON-LD: 831-1.0050423-ld.json
RDF/XML (Pretty): 831-1.0050423-rdf.xml
RDF/JSON: 831-1.0050423-rdf.json
Turtle: 831-1.0050423-turtle.txt
N-Triples: 831-1.0050423-rdf-ntriples.txt
Original Record: 831-1.0050423-source.json
Full Text

Full Text

REAL-TIME FUZZY LOGIC CONTROL OF COMBINED SEWER FLOWS by ROBERT DEAN TAMAKI B.A.Sc, The University of British Columbia, 1991 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF APPLIED SCIENCE in THE FACULTY OF GRADUATE STUDIES The Department of Civil Engineering We accept this thesis as conforming to the required standard THE UNIVERSITY OF BRITISH COLUMBIA FEBRUARY 1994 ® Robert Dean Tamaki, 1994 In presenting this thesis in partial fulfilment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. Department of C[\)\L etJfyl*JE£HW&I The University of British Columbia Vancouver, Canada Date Pets, n , / W DE-6 (2/88) Abstract The use of fuzzy logic for the real-time control of flows in a combined sewer system is examined in this thesis. Using a simple computer model, two different combined sewer overflow control scenarios were developed to test the effectiveness of a fuzzy rule base for controlling wet weather flows using off-line storage. The control objective of the first scenario was to capture the more highly contaminated first flush flows from a two sub-catchment drainage basin. A fuzzy controller was developed using heuristic methods that was found to be relatively effective in achieving the desired objective. The control objective of the second scenario was to capture the peak flow issuing from a single catchment. In this case, two different control strategies were employed. The first involved the construction of a fuzzy algorithm from a database of historical flow control data. That data was obtained manuallly by determining an optimal control response for each storm event using multiple repetitions of each simulation. The results of using this method, however, were found to be highly inadequate, due mostly to flawed methodology. The poor results prompted the development of the second method in which a crisp controller output was modified on-line by a fuzzy adjustment algorithm in response to real-time measurements of the state variables. This method yielded improved results over the first method but some inadequacies were still apparent. These inadequacies could be attributed primarily to the complexity of the control problem and the difficulty involved in representing those complexities heuristically so that they could be converted to a fuzzy algorithm. Specifically, the dimensionality of the control problem was found to be too large to be able to produce an effective fuzzy controller. ii Table of Contents Abstract ii Table of Contents iii List of Figures vii List of Tables x Acknowledgments xi 1.0 Introduction 1 1.1 Study approach 3 1.3 Organization of report 4 2.0 Background 5 2.1 History and problems with combined sewers 5 2.2 Storage as a CSO control method 7 2.3 Real-time flow control 10 2.4 Fuzzy inferencing 13 2.5 Literature review 17 2.5.1 Early example of Seattle, Washington 17 2.5.2 Linear programming approaches 20 2.5.3 Dynamic programming approaches 21 2.5.4 Expert systems 22 3.0 Introduction to Fuzzy Logic 27 3.1 Fuzzy set theory 29 i i i 3.1.1 Fuzzy operations 31 3.1.2 Fuzzy relations 32 3.1.3 Composition of fuzzy relations 34 3.1.4 Fuzzy conditional statements 34 3.1.5 Compositional rule of inference 35 3.1.6 Fuzzy decisional algorithm 36 3.2 Inference methods 37 3.3 Defuzzification 39 The Computer Model 41 4.1 Module get_catch_data 42 4.2 Module get_storm 43 4.2.1 Random storm generation 47 4.3 Module get_serial 51 4.4 Module lag_storms 51 4.5 Module Generaterunoff 52 4.5.1 Module make_TA_UH 52 4.5.2 Module route 55 4.5.3 Module Generatejrunoff 57 4.6 Fuzzy logic modules 57 Description of Control Scenarios 60 5.1 First flush capture scenario 61 5.1.1 Description of first flush capture model 62 iv 5.2 Peak capture scenario 65 5.2.1 Description of peak capture model 67 5.3 Modelling assumptions 69 6.0 First Flush Capture Control Strategy 71 6.1 Control strategy development 71 6.2 Description of fuzzy controller 72 6.3 Results 73 6.4 Discussion of results 80 7.0 Peak Capture Control Strategy 82 7.1 Control strategy development: Method A 84 7.1.1 Results 96 Example runoff control simulation results 99 7.1.2 Discussion of results 109 7.2 Control strategy development: Method B 113 7.2.1 Runoff prediction 114 7.2.2 Control strategy development 117 Crisp algorithm development 118 Fuzzy adjustment algorithm 123 7.2.3 Results 130 7.2.4 Discussion of results 146 Problems associated with Controller B 146 v Evaluation of fuzzy techniques for peak flow capture 152 8.0 Conclusions and Recommendations 155 8.1 Fuzzy techniques: strengths and limitations 155 8.2 Applicability of fuzzy techniques to real systems 157 8.3 Recommendations for future study 158 Bibliography 161 Appendix A: Source Code for the Computer Model 165 Appendix B: Fuzzy Inferencing Routine Example C Code 184 VI List of Figures Figure 1 Qualitative assessement of the likelihood of significant CSO impacts on various surface water systems 6 Figure 2 Levels of information and control 11 Figure 3 Example of levels of control 11 Figure 4 Schematic of a fuzzy controller 16 Figure 5 An example storage rule curve 18 Figure 6 Components of an expert system 23 Figure 7 A crisp set 28 Figure 8 Fuzzy representations of "short" and "tall" 28 Figure 9 The fuzzy operations of a) union, b) intersection, and c) complementation 33 Figure 10 Max-dot fuzzy inferencing technique 40 Figure 11 Hierarchical structure of computer simulation program 41 Figure 12 Cumulative rainfall distribution curves (Huff curves) for the B.C. coastal region 45 Figure 13 Intensity-Duration-Frequency curve for Abbotsford, British Columbia -Two year return curve used by model 46 Figure 14 Steps to construct a randomly-generated rainstorm 49 Figure 15 Example rainfall hyetograph created by random storm generator . . . . 50 Figure 16 Time-Area S-curve used by Clark model 53 vii Figure 17 Example unit hydrograph produced by Clark model 56 Figure 18 Example unit hydrograph routed using the Muskingum method with parameters K = 1.2 hours and x = 0.1 58 Figure 19 Site plan of first flush capture model 63 Figure 20 Site plan of the peak capture scenario model 68 Figure 21 Fuzzy regions for first flush capture controller 74 Figure 22 Tuning of the fuzzy controller for Sim # 4620F showing a) initial, b) intermediate, and c) final controller response 76 Figure 23 Sim #7402F - Long duration storm example 78 Figure 24 Determination of optimal set point by trial and error 86 Figure 25 Division of state variables into fuzzy regions - for a) time, b) inflow, c) inflow increment, and d) flow at weir 89 Figure 25 Division of state variables into fuzzy for e) time since end of storm, f) storage, g) rainfall intensity, and h) release rate 90 Figure 26 Sim # 1290A 100 Figure 27 Sim # 9031A 102 Figure 28 Sim # 4407A 105 Figure 29 Sim # 1779A 108 Figure 30 Projection of rainfall intensities into period from time t to t + Tc. . . 116 Figure 31 Peak runoff/optimal release relationship 119 Figure 32 Example control simulation showing effects of using predicted inflow and fuzzy adjustment 121 viii Figure 33 Typical runoff patterns for short, medium and long duration storms . 124 Figure 34 Fuzzy regions for adjustment algorithm 126 Figure 35 Sim # 5515B - Class 1 response 136 Figure 36 Sim # 2227B - Class 1 response 138 Figure 37 Sim # 7070B - Class 2 response 140 Figure 38 Sim # 4227B - Class 3 response 143 Figure 39 Sim # 6496B - Class 3 response 144 Figure 40 Sim # 4407B - Class 3 response 145 IX List of Tables Table 1 Catchment runoff parameters for computer model 42 Table 2 Runoff-routing parameters for subcatchments in first flush capture model 65 Table 3 Fuzzy mapping of the first flush capture controller 73 Table 4 Process variables selected to represent the runoff state during manual control simulations 87 Table 5 Assignment of fuzzy values to numeric inputs for one example database record 92 Table 6 Number of occurrences of fuzzy outputs for each set of inputs in example database 93 Table 7 Fuzzy mapping of Controller A rule base 95 Table 8 Summary of results of Controller A simulations 98 Table 9 Fuzzy mapping of adjustment algorithm 127 Table 10 Results of Controller B simulations (page 1) 131 Table 10 Results of Controller B simulations (page 2) 132 x Ackowledgements I would like to sincerely thank my advisor, Dr. S.O. Russell for his direction and guidance through the preparation of this thesis and through the course of my entire graduate studies. His assistance and encouragment have extended beyond the scope of this work. I would also like to thank Dr. W. Caselton for his review and input into this thesis. I would most of all like to thank and acknowledge the grace and mercy of God in allowing me to undertake and complete a project such as this. He has been my strength and sufficiency throughout this entire process. XI 1.0 Introduction One of the most pressing environmental concerns facing municipal authorities in many older urban centres is pollution of surrounding receiving waters due to discharges of combined sewer overflows (CSOs). As urban regions have grown and as attitudes and regulations toward environmental degradation have changed, the urgency has increased to develop means of mitigating the impact from these overflows. Consequently, in recent years, much attention has focused on methods of reducing these impacts. Many alternative reduction methods, ranging from first level source control to sophisticated real-time flow control, have been suggested and implemented. This work will concentrate on real-time control methods, specifically investigating the use of fuzzy logic in a rule-based inferencing system to control and store flows in a combined sewer system (CSS). Since its introduction by Zadeh (1965), the use of fuzzy logic and fuzzy inferencing has permeated a great number of fields of research, and, more recently, commercial applications. Most prominent among applications has been the development of fuzzy decisional algorithms and fuzzy controllers. Mamdani and Assilian (1975) introduced the concept of fuzzy process control by designing a controller for a laboratory steam engine. Subsequently, fuzzy techniques have been applied to the control of many complex processes, many with high degrees of success. These processes include activated sludge wastewater treatment (Tong et al., 1980), secondary crushing in mineral processing (Harris & Meech, 1987), tuning of a servo-controller (DeSilva, 1991), nuclear 1 reactor control (Bernard, 1988) and reservoir operation (Kojiri et al., 1990) to name just a few. The primary strength of fuzzy control in each of these and many other applications is its capacity for dealing with the imprecision, non-linearity and randomness inherent within most control situations. Rather than relying upon first principle models of complex processes as required by conventional controllers (ie. PID1, PLC2 controllers etc.), fuzzy techniques incorporate an "intuitive" sense that is characteristic of human reasoning. This "intuitive" capacity enables a fuzzy controller to select appropriate control actions even in cases of imprecise, incomplete, or missing data. The task of monitoring and responding to changes in flow conditions in a CSS during a storm event is an extremely complex task. Storm intensities vary both temporally and spatially and internal flow conditions can change when subjected to any of a wide range of possible disturbances. Moreover, measuring devices that provide on-line, real-time indications of the state of the process are often few in number or subject to inaccuracies, imprecision, or breakdown. Some techniques for managing these processes in real-time have been suggested (these are outlined in Section 2.5), but many require gross simplifications of the process and/or significant computational effort to reach a solution. As an alternative to some of these techniques, this work will examine the feasibility of applying fuzzy inferencing to the control of real-time CSS runoff. Proportional, Integral, Derivative. Programmable Logic Controller. 2 1.1 Study approach Usually, the testing of fuzzy techniques is first conducted using computer simulations of the process to be controlled. Therefore, in this case, it was felt that a good first order assessment of the effectiveness of fuzzy inferencing techniques could be rendered using a synthetic computer model of a combined sewer system. A simple computer model was constructed, consisting of a rainstorm generation module plus modules for transforming the rainfall into routed runoff flows. Because modular program construction was employed, the main program could be modified to represent a variety of different sewer systems to be used in different experiments. This work focuses on two different CSO control problems. The first is to use fuzzy techniques to divert to storage the early flows, or first flush, during a runoff event without allowing unnecessary overflows. This problem was framed within a two catchment model with the control point located near the confluence of the flows from each of these catchments. The second CSO control problem was concerned with flood control, or, more precisely, with the minimization of peak flows issuing from a single catchment subject to limited storage capacity at the base of the catchment. These two problems are quite diverse in nature and are therefore good indicators of the breadth of applicability of fuzzy techniques to CSO and flood control situations. For each of these two problems, controllers were developed that employed fuzzy inferencing to achieve the desired results. The assessement of the fuzzy techniques, however, is primarily qualitative because there does not exist a set of results derived 3 from any other method to which these results may be compared. Nevertheless, the results of the fuzzy methods are reviewed in some detail, thus providing a fairly comprehensive analysis of their effectiveness as they relate to the problems outlined. The conclusions of the study are presented in the final chapter as well as recommendations for future work. 1.3 Organization of report This report is divided into eight chapters including this introductory chapter. In Chapter 2, a background of the CSO control problem is presented along with a review of the literature related to real-time CSO control of fuzzy control. Chapter 3 is dedicated to providing the fundamentals of fuzzy logic and fuzzy inferencing and Chapter 4 presents the theoretical aspects of the development of the computer model. In Chapter 5, the two control problems, or scenarios as they're referred to in later sections, are described including discussions about the control objectives for each. Chapter 6 describes the development of the controller for the first control problem plus the results from its use. Chapter 7 does the same for the controllers developed for the second control problem and in Chapter 8, the conclusions and recommendations for future work are presented. 4 2.0 Background To illustrate the background of the problem addressed in this work, the following sections provide a brief overview of the history and problems with CSOs, some discussion of storage methods and real-time control, and an introduction to fuzzy inferencing techniques. The final section is a review of the pertinent literature concerning the real-time control of urban drainage systems. 2.1 History and problems with combined sewers Western cities built prior to the 1900's generally have extensive networks of combined sewer systems. Though initially constructed solely for storm water conveyance, these systems were soon adapted to also carry away sanitary waste after neighbourhoods became repulsive, filthy and unhealthy places to live. This step created more sanitary living conditions but the waste was still being transported directly into the lakes, streams and estuaries surrounding each urban area. As methods of wastewater treatment were developed, cities began to construct interceptors to convey the dry weather flow from the trunk sewers to the treatment plant. Economic constraints and environmental attitudes of the period prevented the construction of interceptors large enough to carry significant wet weather flows and, hence, the higher flows associated with storms were discharged directly to the surrounding bodies of water through fixed overflow structures. It was generally perceived at the time that, due to dilution effects, 5 S U P P A C E W A T S B T Y P E S W A T e O O x r o i N NUTM Q O A u 1 T V i N T ] _ „ . , r o x i C 9 P U B L I C H g A L t H CMi C*»0«i.*t_3 A S S T M g T I C £ C t A d • T T S A M I r * » v STPgAWS STSEP O O O COAOUAL. Q O Q «I VERS LEAST L. t < E L T M O S T L I K6L.V o o S M A L L L A R G E E S T U A R 1 E S : S M A L L L A P G E m Q © O O O © O Q © © 9 © © © O ® # # • O © © © # # • m - A < E S : S H A L L O W D E E P © © o © © © © - ^ © ~ © © • • - • © © • • Figure 1 Qualitative assessement of the likelihood of significant CSO impacts on various surface water systems (source: Freedman & Marr, 1990). the wet weather overflows would have little or no impact in the receiving water environment (WPCF). In recent years, however, it has become quite evident that CSO impacts are significant. Fecal matter, organics, nutrients, sediments, toxics as well as sanitary debris contained in overflowed sewage can result in significant impairment of water courses on the basis of water quality, public health, and aesthetics. A qualitative assessment of the likelihood of significant CSO impacts for different water bodies is illustrated in Figure 1. From this figure, it is evident that some degree of impariment is likely in most fresh or mixed fresh/saltwater environments. In particular, the public health and aesthetic impacts are likely to be very significant. The need to address CSO problems is therefore quite urgent. In most of the older urban centres in Europe and North America where combined sewers are still active, considerable effort is currently being invested in finding ways to deal with these problems and to minimize the impacts. Generally, the most effective method is storage. 2.2 Storage as a CSO control method Many methods have been suggested and implemented as ways to reduce the impact due to CSO discharges. The following categories provide a summary of these methods although many variations and combinations of these exist: 1. Source Control 2. Inflow/Infiltration Control 3. Sewer Separation 4. Treatment 5. Storage The reader is referred to Combined Sewer Overflow Pollution Abatement - Manual of Practice, from the Water Pollution Control Federation (1989) for a detailed discussion of these methods. Each of these methods are used for CSO control. They have varying degrees of effectiveness depending upon the context in which they are implemented. However, 7 because of the high volume and variability associated with CSO, storage is generally considered a necessary control component. Storage is used to capture high flows during the storm runoff period and then release them to treatment when downstream conveyance and treatment capacity becomes available. In effect, storage attenuates peak flows, thus preventing overloading of interceptors and treatment facilities designed to handle dry weather flow conditions. Storage may be classified as either in-line or off-line, the difference between the two being that off-line storage requires pumping to drain the facility whereas in-line storage drains by gravity. Excess flows may be stored in-line either within the existing pipe (in-pipe) or within in-line basins. Off-line storage requires detention facilities such as ponds, near-surface tanks, or deep tunnels. Generally, the first storage measure considered by municipal sewer authorities is in-pipe storage since this capacity already exists and no additional storage facility construction is required. In-pipe storage is accomplished by damming or gating or otherwise restricting flow passage causing sewage to back up into the upstream lines. Since trunk sewers are usually built to handle floods from rain storms with a return period between five years and twenty years, considerable additional capacity is available within the pipe during most storm events. Moreover, due to spatial and temporal variations in rainfall patterns, some parts of the sewer system may be experiencing very high flows while other parts are experiencing only moderate or low flows. Therefore, overflow volumes may be reduced by making use of available storage in the low-flow parts of the system while making additional capacity available to handle the higher flows in other parts. 8 Non-pipe, in-line storage and off-line storage require the construction of additional facilities and are therefore more costly to implement and maintain. They are nevertheless necessary for capturing high-end flows which cannot be stored in the existing pipe. Typically, these facilities are constructed near overflow points or near dry-weather treatment plants but may sometimes be built farther upstream in the catchment. Flows are diverted into these facilities through the use of static or dynamically-controlled regulators and then released when the capacity is available to transport the sewage to treatment. These facilities are usually equipped with overflow weirs to provide relief when the facility fills up. In order to capitalize on available storage, the flows within the sewer must be controlled using in-pipe regulators. A regulator is any device used to change the energy component of the flow. Hence, some control is provided by static regulators such as side weirs, siphon weirs, fixed diameter orifices and similar devices. However, the use of static regulators means that the system performance will remain sub-optimal except under design flow conditions. Further gains in system performance require the implementation of dynamic regulators such as gates, weirs and pumps, which can be adjusted in real-time to respond to changes in the process state. Having provided dynamic regulators within the system, a real-time control strategy is required to yield optimal or near-optimal performance. 9 2.3 Real-time flow control A combined sewer system is being controlled in real time if the flow regulators are being operated in response to process data which is currently being measured in the system. Here, the term "process" refers to part of the system that lies between the input and output variables and where mass transfer is controlled. Real-Time Control (RTC) implies continuous monitoring and operation of the process. In a system where dynamic control of regulators is possible, a control hierarchy, as shown in Figure 2, governs the operation of the system. In essence, the control levels shown in this diagram represent levels of information with an increasing degree of integration and aggregation of information as the hierarchy is ascended. At the lowest level is local control in which the regulator responds to water levels at the location of the regulator itself. This is the simplest form of control requiring the least amount of information. At the unit process level, more than one regulator may exist and control actions are specified based upon the state of the process on a regional level. An example of unit process control is a series of reservoirs with variable release rates that must be adjusted to prevent flooding. Global level, or centralized, control involves the integration of current state and historical information to specify appropriate control set points at each of the system regulators. Here, the intention is to regulate the process so that optimal reductions can be achieved overall rather than on a location by location or region by region basis. The management level pertains more to the socio-economic and political realities surrounding any pollution control program, and though important in real systems, is of no practical interest to this work. Figure 3 illustrates the distinction 10 Management level ' Global level 1 Unit process level ' Local level (Proc ess] ,, Increasing degree of integration and aggregation of information Figure 2 Levels of information and control (source: Schilling, 1989). Area A SP: Setpoint (local) control. UPC: Unit process control. GC: Global (central) control. Figure 3 Example of levels of control (source: Schilling, 1989). 11 between these control levels, though, in practice, it is neither always possible, nor necessary to make a clear distinction between local, unit process or global levels. The task of integrating and aggregating the information at each level and specifying the appropriate control actions may be accomplished via one of three control methods. They are as follows: • Manual control, • Supervisory control, or • Automatic control. In manual control systems the regulators are human-operated and since only limited information is available, operators need a full understanding or 'feeling' of the hydraulic dynamics of both the control and the drainage system. In supervisory control systems the regulators are actuated by automatic controllers but their set points are specified by the operators. In cases of emergency or maintenance the operator may override the controller and switch to manual control. In an automatic control system a computer fully executes the control strategy without human intervention. This option is most desirable since it doesn't require skilled operators to be on-call twenty four hours a day. Several variations exist on these three approaches. The reader is referred to Schilling (1989) for more details. Significant difficulties, however, are associated with automatic, real-time management and control of runoff due to storm events that are characterized by random processes. The stochastic nature of atmospheric events ensures that the rainfall and runoff pattern of each storm is different from every other storm. Therefore, the task of prescribing a control strategy that can adapt to the unique characteristics of each storm is 12 difficult, if not prohibitive. Any automatic controller must be able to specify, through the use of some internal decision-making algorithm, the appropriate time series of set points to be sent to each regulator based upon the state of the system at each time increment. Several methods of automatically defining an optimal control strategy in real-time have been suggested in the literature (these are discussed briefly in Section 2.5). However, most of these methods require significant simplifications or abstractions from reality to reduce computation time below a level that allows for on-line evaluation of optimal set points. Other methods require extensive historical data bases of past system performance to prescribe an appropriate control strategy. Consequently, most automatic, set point decision-making techniques have significant limitations which can only be overcome through faster processors or through costly data collection schemes. 2.4 Fuzzy inferencing This work suggests an alternative method of deriving an on-line strategy suitable for real-time control of combined sewer systems. Much attention has been focused in recent years on the development and use of fuzzy inferencing techniques for real-time process control in a broad spectrum of applications. Based upon the results reported in the literature, there appear to be certain benefits associated with fuzzy rule-based control that could transfer favourably to the control of CSS flows. In the following sections the concept of fuzzy inferencing is introduced and some of its possible benefits to CSS control are discussed. 13 In most real-time, CSO control situations the performance of an experienced human operator will exceed that of a computer controller1. This is because the human operator uses heuristics obtained by interacting with the process to make control decisions. The operator's knowledge of the system is not based upon a mathematical abstraction of the process but, rather, the process is understood symbolically using rules of thumb and linguistic expressions derived from "hands- on" experience. The operator makes control decisions using human reasoning skills and intuition, built up by interacting directly with the system, by specifying certain control actions and then observing the result. For example, within the operator's "knowledge bank", the following rule of thumb may be used to specify a control action: "If the flow is a little high and the rate of change in flow is low then close the gate just a bit" Here, the linguistic expressions, "a little high", "low", and "just a bit" represent symbolic abstractions of the operator's understanding of the process. The operator has the ability to combine these symbols and the symbols from any number of other similar rules to obtain a discrete output value for the adjustment required at the gate. This ability to combine rules and symbols to infer an appropriate response is what allows a human operator to achieve effective control of the process. The linguistic expressions "a little high" and "low" etc. incorporate a certain degree of ambiguity and imprecision which cannot be expressed using conventional 1 This statement appears to be contradicted by the initial results from the Seattle CSO control system which indicate that the reductions in overflow volume under supervisory and automatic control were 68.1% and 96.8% respectively (Leiser, 1974). This apparent discrepancy may be accredited to several factors. Firstly, since these results come shortly after first implementation of the system, the operators were still quite inexperienced at handling flows effectively and, hence, reduction levels were lower than expected. Secondly, automatic control had only been tested during one unusually dry summer period and consequently the reduction levels were higher than might otherwise be expected. 14 mathematical techniques. For example, there may exist some uncertainty whether a flow of, say, 10 m3/s may be considered "high" since, in terms of human thinking, the term "high" can't be strictly defined. Conventional mathematics, however, must adhere to a strict definition of the term, specifying a discrete value, say 12 m3/s, above which a flow is considered "high" and below which the flow is not "high". The ambiguity and imprecision inherent within human thinking, however, is embraced by the concept of fuzzy sets. Fuzzy set theory represents that imprecision mathematically by assigning a degree of membership between zero and one to each element within a set (e.g. the set representing the linguistic variable "high") corresponding to the "belongingness" of each element within the set. The relationships between linguistic variables can then be expressed by an ordered set of if/then rules, known as a fuzzy decisional algorithm, that encompasses the problem domain under consideration. Through a well-developed theory of inferencing, sometimes known as the calculus of fuzzy if/then rules (Zadeh, 1992), discrete solutions can be produced which approximate the response of a human as shown in Figure 4. Since the processes within a sewer system during a storm event are characteristically complex and random, generally requiring human intelligence to assess and prescribe optimal control strategies, the use of fuzzy logic seems a natural control alternative. This study, therefore, addresses this possibility through a computer modelling process. Two representative control scenarios (which are described fully in Chapter 5) are investigated in which portions of a CSS are subjected to randomly generated storm events. For each scenario, a fuzzy decisional algorithm is developed that 15 Input Observations (fuzzy) Inputs from sensors (crisp) x2o-x n ^ X , o -X ^ * 3 ^ Human Controller Output action (crisp) —°Y Fuzzy Rule Base z \ Defuzz-ification Fuzzy Output Y* is an approximation to Y. Figure 4 Schematic of a fuzzy controller (source: Jamshidi, 1992). Output action (crisp) - o Y * meets, as closely as possible, the pre-specified control objectives. The viability of fuzzy methods can then be assessed in terms of how closely these objectives are met. This work represents a very preliminary investigation of fuzzy control methods. As a result, the study approach employs a synthetic model which incorporates some of the randomness associated with real CSS systems but many of the constraints which would apply to a real system have been neglected. Consequently, the results obtained through this work should be indicative of the potential for fuzzy control methods, but further work will be necessary before actual implementation is possible. 16 2.5 Literature review Real-time techniques for controlling CSOs are now used extensively throughout North America and Europe as documented by Schilling (1989). Many different approaches to developing a real-time control strategy have been suggested and reported in the literature. Some of these are introduced in the following sections to provide the basis for examining the use of fuzzy inferencing control methods. 2.5.1 Early example of Seattle, Washington The initial attempts at reducing CSO's using real-time control occurred during the early 1970's. One of the first attempts was in Seattle, Washington, where the in-line storage capacity of the existing CSS was utilized to capture overflows under both supervisory and automatic control conditions (Leiser, 1974). Seattle's centralized global control system, CAT AD (Computer Augmented Treatment and Disposal), was implemented to manage a CSS service area of 5,250 hectares (13,000 acres). Under supervisory control, a human operator was usually able to successfully eliminate overflows for short duration storms of limited geographical coverage. However, as the total geographical, volumetric and chronological impacts of storms increased, so also the required complexity of the control strategy increased, resulting in an extremely stressful working environment for the operators. Optionally, local automatic control of each regulator station could be employed. The automatic control strategy at each station was determined by a pre-specified rule curve that relates storage and time for a given 17 100% i —5s-| 75% - / V / ^ / o • ~ 50% - / 25% y ' 0% -L=^ — Time Figure 5 An example storage rule curve reservoir under different control conditions (Figure 5). Through the use of an off-line optimizing model, the rule curves for each station could be adjusted along the time axis to yield a global control action which most effectively reduced total overflows. The initial results of using automatic control, though based upon a limited experience of one unusually dry summer, proved to be very good, yielding CSO volume reductions over static local control of greater than 90 percent. The Seattle experience illustrates a rudimentary method of optimizing the control strategy in which the rule curves are modified off-line subject to historical rainfall patterns. This method yields an optimized strategy averaged over a period of many storm events. That is, the cumulative volume of overflow summed over many storms is 18 minimized. However, no capacity exists for evaluating a best control strategy on a storm by storm basis under automatic control2. As a result of the need to provide better control on an individual storm basis, several methods have been suggested for defining an appropriate control strategy in real-time. Among these are various optimization methods including linear programming and dynamic programming and their derivatives. Such techniques have become possible because of faster computer processing speeds which bring calculation times close to the horizon necessary for real-time applications. However, significant simplifications are still required in order to create an optimization model which can be implemented in real-time. Some other real-time procedures for defining a control strategy include search techniques, decision matrices and control scenarios (see Schilling, 1989 for a discussion of these methods). More recently, the use of expert systems for real-time control has been suggested by some researchers with some limited work begun in the use of fuzzy inferencing. 2.5.2 Linear programming approaches Linear programming techniques such as those suggested by Schilling (1989) and Neugebauer et al. (1991) are based upon the optimization of an objective function specified to minimize either total overflows or total costs where overflows and flooding In the Seattle system, the supervisory operator can remove each station from automatic control and manually change the rate of storage at that station in real-time. This may yield a better performance during each storm subject, of course, to the operator's skill. 19 are assigned some arbitrary unit cost. These techniques require the definition of system constraints which consist of: 1. Initial state constraints, ie. initial storage, flows and overflow; 2. State capacity constraints, ie, maximum storage, maximum flow; 3. Control constraints, ie. maximum gate release; 4. Final state constraints; 5. Non-negativity constraints; 6. Dynamic constraints, i.e. as governed by the St. Venant equations. Once the objective function and system constraints have been identified, techniques such as the Simplex method may be used to identify the optimal control strategy. Neugebauer et al. define a simplified optimization algorithm similar to linear programming where the objective function is defined as: minj^ f (xt,ue) , t - i where f is a cost function of the decision variables (system state_xt and control variable uj and has to be a minimum over the control horizon of a time steps. However, the method requires that not only are the state constraints, control constraints and dynamic constraints linear but their coefficients are only allowed to be 0, 1, or -1 . This restriction enables the use of fast algorithms that bring the solution time within the range required for real-time control of non-trivial systems. An example presented in their work for a Swiss community of 5000 people consists of 14 sewers, 3 overflow ponds, 2 overflows, 3 diversion nodes, and 9 inflow points. The required computing time for this system on a PC-AT 386/387 was 3 min 31 sec. 20 Though this method may bring computing time within an acceptable horizon, the required simplifications need to be more thoroughly examined to assess their effect on the final control decisions. Moreover, for larger systems consisting of many more components, the computing time would be considerable unless more powerful, and hence, more expensive computing facilities were available. 2.5.3 Dynamic programming approaches Dynamic programming (DP) methods for real-time control of storage systems have also been reported. For example, Beron et al. (1984) employ a dynamic programming approach to a centralized weighted loads control procedure. In essence, this procedure recognizes that the impact of the same pollutant load at different locations varies according to receiving water conditions and the desired uses of the water body. It thereby attempts to minimize the total impact of pollution loads considering locational variation in CSO impacts. A DP algorithm was adopted that evaluated the optimal interception rate from each of a series of regulated trunk sewers emptying into a single interceptor, beginning at the most downstream regulator. The study assessed five different control techniques, including the DP approach mentioned here, to an hypothetical urban area of 5100 hectares and 332,000 people. It concluded that the DP approach yielded approximately the same results as the local automatic control approach. This result, however, must be viewed cautiously in light of the fact that the study was conducted using an hypothetical control scenario. No information was given about required computation times. 21 Schilling describes several difficulties which are common to any optimization technique. These include: 1. Operational objectives of an agency may be non-monetary, intangible, and/or conflicting. It is very difficult to aggregate all objectives into a single objective equation. Multiple objective optimization techniques, however, cannot be fully automatic. They require interaction with a decision maker to find best compromise solutions. 2. If a single objective function has been specified it is usually of a mixed integer/continuous, non-linear, and non-monotone type. Since powerful optimization techniques are not available for this kind of objective the function has to be further simplified. 3. Flow routing has to be simplified to allow application of standard optimization techniques. This involves spatial and temporal aggregation, and linearization. 2.5.4 Expert systems Amongst the most recent developments in real-time CSO control is the use of artificial intelligence techniques and, specifically, expert systems. An expert system (sometimes called a rule-based system or knowledge-based system) is a computer program which is designed to mimic human reasoning in such a way that it appears to think, reason, solve problems, make decisions, retrieve and store information in a fashion similar to a human expert (Meech & Kumar, 1992). 22 An expert system for use in real-time applications is generally comprised of four components as illustrated in Figure 6. The knowledge base is like the memory bank of the expert system. It contains an ordered set of facts, properties, and constraints which describe a selected domain of knowledge. Usually, this information is represented by a series of if-then-else rules that parallel the expert's evaluation of that domain (hence the term rule-based system). The inference engine is the thinking part of the system. It controls how information in the knowledge base is accessed (i.e. search methods), how to conclude on a new set of facts given an established set of facts, and how uncertainty accumulates during inferencing. The user interface allows a human operator to interact with the system by providing information on-line which the system needs to complete the inferencing process. In a real-time application, the expert system receives measurements from remote sites and sends control actions via the process interface. ( -t Process Interface 4 Knowledge Base a I „ \ " ^ ' Inference Engine User Interface ^ ; Figure 6 Components of an expert system 23 Expert systems are well-suited for CSO control because they can be designed to respond as an experienced operator would under different storm conditions. This is accomplished by encoding the expert's (i.e. the operator's) understanding of the system into the knowledge base using the linguistic forms that are used by the expert. Much of the expert's knowledge of the system consists of symbols which can be represented in words and phrases as opposed to numerical knowledge as is required by conventional computer programming techniques. The expert system has the capability of "reasoning" using the both the symbolic expressions of the expert and the mathematical expressions which constrain the process in order to select an appropriate control action. Khelil and Schneider (1991), report the results of the use of an expert system for real-time control of CSOs in Bremen, West Germany. The sewerage system, which consisted of an urban area of 920 Ha, having 40 pump stations and two large retention basins, had been controlled by human operators since the early 1970's. Over this period an elaborate set of control instructions had been developed for managing flows. Two options were considered to systematically analyze and develop control strategies: optimization and expert systems. Given the already established set of instructions, the expert system option was selected. In model studies, the flexibility of the expert system was apparent, allowing the designers to modify the knowledge base to yield a more aggressive control strategy. Consequently, overflows were reduced without increasing the risk of flooding. In essence, a fuzzy decisional algorithm is an expert system. It consists of a series of if-then rules that use fuzzy sets to represent the linguistic expressions of the expert. Much research has been performed in the development of fuzzy rule-bases and 24 controllers for process control in many disciplines (see Berenji, 1992, for an overview). However, limited research has been performed using fuzzy control methods for process control in urban drainage systems. In one paper, Hou and Ricker (1992) describe the development of a fuzzy rule-based algorithm to control flows in a simple model for possible future application to the Seattle real-time control system. The model consisted of three reservoirs representing the available in-line storage of three sewer pipes. The control objective was to make full use of the storage capacities by keeping the relative fullness of the three pipes approximately the same while flow is being stored. That is, Cx C2 c 3 where Vj is the volume currently stored and Q is the total storage capacity of reservoir i. A fuzzy control algorithm was developed that specified the appropriate outflow from each pipe based upon the differences between the fullness of the three pipes. The results indicated that fuzzy control was effective in managing a small portion of a combined sewer system and that further work to apply fuzzy control more broadly was appropriate. In a related application, Honda et al. (1990) employ fuzzy inferencing in a rule-based system to modify a pumping plan for the headworks of a wastewater treatment facility during wet weather periods. During dry weather periods, the inflows can be predicted with reasonable accuracy using statistical methods. The daily pumping plan can therefore be established on the basis of the predicted inflows. However, during wet weather, the actual inflows deviate from the predicted inflow pattern and since the treatment plant operating process is somewhat ill-structured, the pumping plan must be 25 modified by a human operator rather than by numerical methods. In order to address this difficulty, a fuzzy rule base was developed to evaluate the deviation of actual inflow from predicted inflow and use that information to adjust the pumping plan appropriately. In the modelling stage the results of the simulations using fuzzing inferencing were satisfactory and actual implementation was completed in 1989. This concept of using fuzzy inferencing to modify a preset control plan is important to this work as will become apparent in later sections. Often, a complex process can be controlled using a crudely approximate strategy but further improvements require a human operator to make adjustments based upon some knowledge of the subtleties of the process. The use of fuzzy logic to imitate the human reasoning required for such adjustments is promising. 26 3.0 Introduction to Fuzzy Logic Fuzzy Set Theory and Fuzzy Logic were first introduced by Lotfi A. Zadeh, professor of computer science in the department of Electrical Engineering, University of California, Berkeley, in 1965 (Zadeh, 1965). Since its introduction, fuzzy logic has been the subject of much controversy, having been disdained by many academics for its inexactness and imprecision or belittled as nothing more than probability theory (Zadeh, 1984). However, in spite of the criticisms, fuzzy logic has, in recent years, emerged as a powerful tool applicable where conventional mathematical methods fail or are somehow inadequate. Conventional set theory employs two-valued boolean logic to assign membership in a set. Hence, membership is classified as either belonging or not belonging, true or false, one or zero. For example, the set of all integers greater than five is clearly delineated so that the integer six has membership one and four has membership zero. A two-valued set is called a "crisp" set and is illustrated in Figure 7. Though straight-forward and easy to apply in mathematical or computer operations, the concept of a crisp set does not capture the imprecision associated with most human linguistic expressions. The strength of fuzzy set theory lies in its ability to embrace the inherent imprecision and ambiguity in human thinking. The human thought process is characterized by concepts which are not clearly distinguished from one another but rather there is some shading between one concept and another. For example, consider the term "tall". Most people would readily consider a person who is 200 cm in height to be tall. At the same time a person who is 175 cm in height might be considered tall but 27 )ershjp b E E n n u.u TALL 1 1 1 120 140 180 160 Height (cm) 200 220 Figure 7 A crisp set 120 140 180 160 Height (cm) 200 220 Figure 8 Fuzzy representations of "short" and "tall" 28 to a lesser degree. However, a person who is only 150 cm in height would not be considered tall. In cases such as this, there is no discrete value that serves as a boundary between tall and not tall. Rather, in terms of human reasoning, a continuous gradation exists ranging from fully tall to not tall. Using fuzzy sets, the terms "tall" and "short" can be represented by the fuzzy sets shown in Figure 8. A fuzzy set assigns a degree or grade of membership between zero and one to each height between 150 cm and 200 cm corresponding to the degree of "belongingness" of that element in the set. A degree of membership of one denotes full inclusion within the fuzzy set whereas zero denotes non-inclusion. For intermediate heights, a degree of membership somewhere between zero and one denotes partial inclusion in the set. Hence, a person who is 175 cm in height is considered both tall and short with a degree of membership of 0.5. Similarly a 150 cm person is "short" with a degree of membership of 1.0 and "tall" with degree 0.0. 3.1 Fuzzy set theory In a crisp set the membership of an element is described by a membership function nA(x), where: 29 A fuzzy set extends this definition so that elements can take on membership values ranging from 0 to 1: u-A :X-[0,l] (3.2) where X refers to the universe of discourse of the fuzzy space. The universe of discourse is defined as all elements that are eligible to be grouped as identifiable sets or subsets. For example, the universe of discourse of dogs would include the subsets "Poodle", "German Shepherd", and "Cocker Spaniel". If the elements of a universe of discourse are finite and countable, then the following notation may be used to denote a fuzzy subset A: A-f: ^ U i > • (3-3) i - l x i If X is continuous, then a fuzzy set, A, can be denoted by: A-f **{x) . (3.4) J x x where the summation and division symbols do not refer to arithmetic operations, but are used as notation to delineate individual elements and their respective memberships. For example, in A = .3/elementl+ .6/element2, element 1 has membership value .3 and element2 has membership value .6. 30 3.1.1 Fuzzy operations Since fuzzy set theory can be considered a generalization of binary set theory, it follows intuitively that similar operations can be performed on fuzzy sets as on crisp sets. For two fuzzy subsets, A and B, the following operations are possible: Equality: Union: Two fuzzy sets, A and B, are equal if and only if: \xA(x) - n „ ( x ) ,V XEX. (3.5) The union of A and B is a fuzzy set with the following membership function: where the symbol V is the maximum operator. The union operation corresponds to the linguistic operator OR. (3.6) Intersection: The intersection of A and B is a fuzzy set with membership function: P^As- ( H A A " a ) (3.7) where the symbol A is the minimum operator. The intersection operator corresponds to the linguistic operator AND. 31 Complementation: The complement of A is a fuzzy set A with a membership function: \ij-l-\xA(x) . (3.8) The complement operation corresponds to a logical NOT. The operations of union, intersection and complementation are displayed graphically in Figure 9. 3.1.2 Fuzzy relations A fuzzy relation expresses a relationship between ambiguous or fuzzy concepts and ideas. The phrase "x is more beautiful then y" is a fuzzy relation which relates the two entities, x and y, in an imprecise manner. The ability to mathematically evaluate these relations is essential to applications of fuzzy theory. A fuzzy relation, R, from a set X to a set Y is a fuzzy set in the Cartesian product: Xx Y- {(x, y) | xex, yeY), (3.9) and is characterized by a membership function (JLR: \IR:XXY~[0,1] . (3.10) When X = Y, R is known as a fuzzy relation on X. For example, consider sets X = {x1? x2} and Y = {y1; y2} with fuzzy sets A and B respectively. The fuzzy relation from X to Y in the cartesian product, R = A x B, is 32 a) 1.0 0.0 b) 1.0 0.0 c) 1.0 0.0 Figure 9 The fuzzy operations of a) union, b) intersection, and c) complementation. 33 a fuzzy set having membership value in the Cartesian product, X x Y, of /*R(xn, ym),where: V>Rixa,ym) - l\iA(xn)A\xB(ym)], xRexymeY. (3.11) This relation can be expressed by a relation matrix as follows: \\xR(.xliyi) | i * U l f y 2 ) j (3#12) [ n « ( ^ / y i ) PR<x2.y2)\' 3.1.3 Composition of fuzzy relations If R is a fuzzy relation in X x Y and S is a fuzzy relation in Y x Z, the composition of R and S, RoS, is a fuzzy relation in X x Z as follows: R°S~\iRoS(x,z)-\/{\iR(x,y)AVLs(x,y)}, (3.13) y This composition uses max and min operations, so it is called max-min composition. Many other forms of composition have been suggested in the literature as discussed by Terano et al. (1987). An understanding of max-min composition only is required for this work. 3.1.4 Fuzzy conditional statements A fuzzy conditional statement or implication is a construct of the form: 34 'If A then B' where A and B are fuzzy subsets. For example, the statement: 'If flow is high then deltaD is medium', defines the relationship between the fuzzy variables "high" and "medium". This relationship is expressed by the Cartesian product A x B which can be represented by the derived relation matrix. In this work all applications are of the general form "if \ then Bn" and are evaluated as: (A1xB1)U(A2xB2) . . . {A,pcBn) (3.14) 3.1.5 Compositional rule of inference If R = is a fuzzy relation from X to Y and A is a fuzzy set on X, then the fuzzy set B which is induced by A is given by the composition of R and A: B - AOR. (3.15) which is a specialization of general composition and its membership function is given by: HBU) -max min[u.A(x) ;\iR(x,y)] (3.16) X Given the relation R = A x B, the fuzzy subset on Y, B', which is induced by applying variable A', can be obtained by: B'-A'°R-A'o{AxB) . Q.V7) 35 Through the use of fuzzy set theory, human concepts in the form of linguistic expressions such as "high", "low", or "medium" can be represented in a way that includes the vagueness or ambiguity of the concepts. Moreover, relationships between linguistic variables may be defined mathematically thus allowing the formation of fuzzy conditional statements. These statements may then be evaluated using the fuzzy operations of intersection, union and complementation which are analogous to the logical connectives AND, OR and NOT. 3.1.6 Fuzzy decisional algorithm A fuzzy decisional algorithm, consisting of an ordered set of fuzzy if-then rules (ie. a rule base), embodies a domain of knowledge based upon imprecise modes of reasoning. The decisional algorithm is a widely used tool in areas such as systems analysis, control, signal processing, pattern recognition, decision analysis, diagnostics and many related fields. In this study, the decisional algorithm is used for process control, pattern recognition, and for refinement of a crisp operating algorithm. Consider the following fuzzy decisional algorithm which consists of two rules: Rule 1: If X is Ax and Y is Bx then Z is Ct Rule 2: If X is A2 and Y is B2 then Z is C2 where X and Y are the universes of rule base input, and Z is the universe of rule base output, and Av Bv Ci? for i = 1, 2 are fuzzy subsets on the universes X, Y, and Z respectively. 36 For any given set of input variables, the fuzzy singletons Ax', Bj ' , A2' and B2 ' (i.e. a fuzzy singleton is a fuzzy set consisting of only one element) can be calculated and used to obtain the fuzzy output Z' as follows: , _ ( (A[o (A1xC1))f) (B[O (B1xC1)))U ( 3 # 1 8 ) " ( u 2 ' o u 2 x c 2 ) i n ( B 2 0 ( B 2 X C 2 ) ) ) . Generally, a single output is desired from the decisional algorithm. This can be derived from the fuzzy set Z' using any of several defuzzification methods. The next section discusses the inferencing and defuzzification methods used in this work. 3.2 Inference methods Computationally, the fuzzy rules are evaluated using simple max-min logic. And in a fuzzy controller, the inputs are generally single-valued and discrete so they can be represented as fuzzy singletons. However, since rule antecedents generally overlap, it is common for more that one rule to fire at a time resulting in multiple output fuzzy sets. For most applications, some means of resolving these fuzzy outputs to a single discrete output is required. This is accomplished through the processes of inferencing and defuzzification. The inference method defines how the strength of the rule is applied to the control outputs. The most commonly-used method, and the method used in this study, is max-product or max-dot inferencing. To illustrate this method, consider again the fuzzy rules Rule 1 and Rule 2. Referring to Figure 10, the discrete values x0 and y0 are inputs to the fuzzy algorithm for the fuzzy variables X and Y. The degrees of belief of the 37 antecedent conditions for Rule 1 are given by ACA1(X0) and /xB1(y0) where /xA1 represents the membership function for A^ Similarly, the degrees of belief of the antecedents for Rule 2 are MA2(XO) an(^ /*B2(y<>)- T n e strengths of Rule 1 and Rule 2 are respectively given by: V ^ ^ ) A | i B i ( y 0 ) , (3.19) and «2"l-lA2(*0)Au.B2(y0) . (3.20) The respective strengths of the rules are applied to the fuzzy output sets by multiplying the memberships of the sets Cl and C2 to yield the output sets C^ and c y as follows: H ^ z J - f f i ' H ^ l z ) , (3.21) and u ^ U J - c v u - ^ U ) , (3.22) where z ranges over the universe of the output variable. This means that, as a result of inputs x0 and y0, Rule 1 is recommending an action with membership function ncv and Rule 2 is recommending an action with membership function /xC2>- These membership functions are then combined to produce a single outputfuzzy set, nc. In Figure 10, the output fuzzy set is obtained pointwise using the maximum or union operator as follows: \ic(z)-\xcj(z)Vnci(z) . (3.23) 38 Though this is the most commonly-used method, the method used in this study sums, rather than unions the outputs (see Section 3.6) as follows: \ic(z) -\I,J(Z) + iic>2(z) . (3.24) Regardless of the method of combining outputs, the resulting output fuzzy set nc(z) must now be defuzzified to yield a single output. 3.3 Defuzzification Defuzzification is the operation that produces a non-fuzzy value from the fuzzy output /xc(z). Several defuzzification methods are described in the literature but the most common method, area-centroid defuzzification, is the only one used in this work. This discussion will therefore describe only that method. The area-centroid method calculates the centre of gravity of the fuzzy membership function and specifies the corresponding value on the universe as the non-fuzzy output. Assuming a continuous universe of discourse, the centroidal position, Z*, can be calculated as: fz\ic(z) Z*--2- , (3.25) z where /*c(z) is the membership value of element z on the universe Z. 39 o Figure 10 Max-dot fuzzy inferencing technique 4.0 The Computer Model A simple computer model was developed which is capable of generating a randomized rainstorm and converting the rainfall into a runoff hydrograph for a specified catchment. It was reasoned that a highly sophisticated rainfall-runoff model was unwarranted because the objective of this study was only to assess the viability of fuzzy control in a combined sewer system, not to design an actual controller for a real system. That is, it was regarded that the additional programming, data collection and computational effort which would be required by a more sophisticated model would add very little to the results. It was only necessary to provide a model which would produce a consistent runoff response for a given catchment under a variety of storm conditions. The program which was used to perform the simulations was written in Borland Turbo C+ + , version 3.0 for Windows™. The program modules are shown in hierarchical form in Figure 11 and the complete program listing is given in Appendix A. main geUatchjiata get_storm getjerial lag_storms Generate runoff make TA UH route getjunoff Figure 11 Hierarchical structure of computer simulation program 41 The modular construction allows the programmer to easily manipulate the order of execution to represent the situation being modelled. Hence, it is possible to represent a wide variety of scenarios with very little manipulation of the program code. The following sections describe each module in detail and provide some of the theoretical background behind their functions. 4.1 Module get catchdata The get_catch_data module reads a text file containing the runoff-routing parameters required by the program to characterize the catchment(s) be modelled. The parameters contained in the file are shown and described briefly in Table 1 but each one is discussed in more detail in later sections as it is used in separate program modules. The name(s) of the predefined text file(s) is given by the user as a Hxmmand line argument at run time, thus making it easy to switch to a different set of parameters. Table 1 Catchment runoff parameters for computer model Catchment Runoff Parameters Parameter A Tc h w K X Inf B Description Total area of catchment Time of concentration fraction of total catchment area contributing flow at time Tc/2 ratio of maximum catchment width to average width Muskingum storage constant Inflow constant Infiltration Baseflow Units ha. hours --hours -mm/hr m3/s 42 4.2 Module getstorm The get_storm module retrieves the storm hyetograph to be used for the simulation in one of two ways. It may be supplied by the user in an external text file or it may be generated randomly within the program. Upon entering this module the user is asked which alternative is desired. If an external file is selected the user is then prompted for the file name. Otherwise the program prompts the user for an integer value to seed the random number generator. The storms which are generated by the program are based upon data and storm pattern information for the Vancouver, British Columbia region. It should be emphasized, however, that this module is not intended to generate rainfall hyetographs which are representative of actual storm patterns in the Vancouver region. That is, there is no correlation intended between the magnitudes, frequencies and durations of the generated storms and those of naturally occurring storms. The reason for using this information (as opposed to information from other regions) is that it is readily available and, given that this study has been conducted in Vancouver, it is relevant to local conditions. Indeed, the storm information is only required to provide internal consistency. That is, the variation in resulting storm patterns should be reflective (though not reproductive) of natural weather systems. The variation should not be so great that the storm patterns become unrealistic. The generation of a random storm for use in the simulation has been accomplished using two pieces of information: a set of cumulative rainfall distribution curves or Huff curves, and an Intensity-Duration-Frequency curve for two-year return period events. 43 For the British Columbia coastal region, the rainfall patterns for a 12 hour storm are characterized by the Huff curves shown in Figure 12. These curves illustrate the temporal pattern of rainfall deposition by showing the accumulated depth as a function of time. The value labelled on each curve indicates the percentage of the total number of storms events for the region which fall to the left of that curve. It is apparent from this diagram that the rainfall distribution is fairly uniform for most storms in the B.C. coastal region over the duration of the event. This reflects the fact that rainfall patterns in this region are dominated by large-scale, synoptic systems which produce less-intense rainfall on the average over a longer period of time (Watt, 1989). Each of these curves was normalized along the time axis (i.e. expressed as a ratio of elapsed time over total duration) and then fitted to a cubic of the form: d=at2+bt2 + ct (4.1) where d is the percentage of accumulated rain depth and t is the fraction of the total time elapsed since the start of the storm and a, b, c are coefficients given as follows: Coeff-icient a b c Total No. of Events 10% -0.36 0 1.36 30% -0.225 0.18 1.045 50% -0.63 0.99 0.64 70% -0.765 1.395 0.37 90% -0.495 1.44 0.055 In order to provide a reasonable correlation between a randomly-generated storm duration and the total depth of rainfall, an Intensity-Duration-Frequency (IDF) curve for the Abbotsford, British Columbia recording station was used (Figure 13). The two-year 44 0.9 0.8 0.7 0.6 c '(5 DC § 0.5 CO 0.4 0.3 0.2 0.1 ^ 1 30% 50% / \ 7)%/\ / / / / / S oy 3% y ^ ^ / ! 0.2 0.4 0.6 dt/Duration 0.8 Figure 12 Cumulative rainfall distribution curves (Huff curves) for the B.C. coastal region (source: Hydrology of Floods in Canada - A Guide to Planning and Design, National Research Council, 1989). 45 U\J 1 n IU H 1 -v^>> 10 rear v-»^ 5 year ^* 2 y jar 10 100 Duration (minutes) 1000 10000 Figure 13 Intensity-Duration-Frequency curve for Abbotsford, British Columbia Two year return curve used by model (source: Atmospheric Environment Service, Environment Canada). return event curve was selected to represent this relationship because it was the lowest return period curve provided. Again, this information is used for the purpose of providing internal consistency only. If both storm depth and duration were randomly generated, completely unrealistic combinations (e.g. very high total depth of rain over a very short time period) are likely to result. The use of an IDF curve ensures a reasonable relationship between these parameters. 4.2.1 Random storm generation The random storm generator makes extensive use of a function called normal^, a) which converts the uniformly distributed random numbers produced by the computer to normally distributed numbers having mean, /t, and standard deviation, a. The function uses the following equations taken from the "Handbook of Mathematical Functions" (Abramowitz and Stegun, 1965): a0+a* t x - t- 0 1 p l+bxt+b2t2 CKp^O.5, *-\ ln-i-P 2 a 0 - 2 . 30753 2 ^ - . 99229 ( 4 2\ ax-. 27061 b2-. 04481 47 which yield a distribution with mean zero and standard deviation one and where p is a uniformly distributed random number. The procedure used for generating a random storm is illustrated by the steps shown in Figure 14. The first step is to obtain the total duration, td, of the storm event by generating a random number corresponding to a normal distribution with a mean of 4 hours and a standard deviation of 2 hours (ie. normal(4, 2)). Using the two-year return IDF curve, the average rainfall intensity corresponding to the duration is obtained which readily yields a total depth, d, of rainfall (Step 2). The total depth is then randomized using the normal function, normal(d, 0.05d), so that the storm depth-duration combinations vary somewhat from a strict two-year return event (Step 3). Having obtained values for duration and total depth, the program selects, at random, one of the five Huff curves for the B.C. Coast region (Step 4). Using this curve, the total depth of rainfall is calculated for each of n time steps where n is given by: n ' 4 T > (4'3) A t and At is length of each time step (Step 5). The magnitude of the rainfall intensity, i, at each time step is then calculated (Step 6) and randomized using: ij - normal {ijt0. 2 i) , 0<.j<n (4.4) (Step 7). By repeating Steps 5 through 7 n times, the rainfall hyetograph is built up (Step 8). 48 Step 1: Get random storm duration, td, from normal(4,2). Step 2: Calculate the corresponding depth, d, from the 2 year IDF curve. Step 3: Randomize the depth using normal(d, 0.05d). Step 4: Select Huff curve at random. Step 5: Calculate the incremental depth of rainfall in each time step. Step 6: Calculate the rainfall intensity,i, for each time step. Step 7: Randomize the rainfall intensity using normal(i, 0.2i). Step 8: Repeat Steps 5 through 7 until hyetograph is complete. Figure 14 Steps to construct a randomly-generated rainstorm. There is one difficulty associated with this algorithm. By randomizing the intensities and hence the depth of rainfall in each time step, the accumulated depth of rainfall will usually differ from the total depth calculated in Step 3. Consequently, as the generation routine tries to calculate the depth of rainfall in the final time steps of td, it is possible that the accumulated depth will already exceed the total depth. This would yield erroneous results in the rainfall hyetograph. To overcome this difficulty, at Step 5 the incremental depth of rainfall is calculated as the percentage of the total rainfall yet to come, rather than as the percentage of the rainfall already fallen. Doing so ensures that the total accumulated depth after the n repetitions is nearly the same as depth calculated in Step 3. This procedure yields, after stepping through the duration of the storm, a rainfall hyetograph such as the one shown in Figure 15. Since the random number generator 49 era c Intensity (mm/hr) o U l W to re 1-1 69 mm ZT V< ft O 90 -1 W TJ =r o re 63 « • * n a cr «<: • 1 so 3 a. o 3 ore n> 3 3 <- • o produces the same sequence of numbers for a given seed, the storms are reproducible by specifying the same seed at the start of each simulation. 4.3 Module getserial The module get_serial has been included to incorporate into the model spatial and temporal variation in intensities as the storm traverses multiple catchments. It creates an hyetograph which is serially correlated to an input hyetograph by randomizing the intensity during each time step using: ij - normal ( i ) , 0 . 2 i j ) , Ozj<n (4.5) where L1 and L2 are the intensities in step j for the original and the serial storm respectively. 4.4 Module lagstorms The module lag_storms receives the original and the serially-correlated storm and generates a random time lag between them in order to simulate the movement of a storm across two catchments. The time lag is generated based upon a normal distribution with a mean of 10 minutes and a standard deviation of 6 minutes (i.e. normal(10, 6)). This result is rounded to the nearest time step unit and the hyetograph elements of the lagged storm are shifted back by that amount. 51 Though natural storms generally have a prevalent direction of travel over any land area (i.e. west to east in SW B.C.), the occasional storm will travel in a different direction. In order to account for this variation in the prevailing storm traversal patterns, the serial storm is lagged two thirds of the time and the original storm is lagged one third of the time. 4.5 Module Generaterunoff Once the catchment runoff parameters and the storm hyetographs have been obtained, the outflow hydrograph from each catchment can then be calculated. The basic model used to perform this task is the Clark Model in which rainfall is lagged by a time-area curve and routed through linear storage. The Generate_runoff module makes use of three sub-modules to perform this task: make_TA_UH, route, and generatejrunoff. 4.5.1 Module make_TA_UH Module make_TA_UH constructs a time-area unit hydrograph based upon the specified parameters for each catchment. It makes use of the U.S. Corps of Engineers Hydrologic Engineering Centre S-curve (Chow et al., 1988), such as the one displayed in Figure 16, to obtain the ratio of the area contributing runoff, Ac, to the total catchment area, A, as a function of elapsed time,t, divided by the time of concentration, Tc. It has been modified by Russell1 to include the parameters h and w which further characterize 1 Presented as class notes in CIVL 551, Advanced Hydrology, Department of Civil Engineering, The University of British Columbia 52 1.0 0.8 — 0.6 < o < 0.4 0.2 — 0.0 Figure 16 Time-Area S-curve used by Clark model 53 the catchment basin. The parameters h and w represent the proportion of the total area contributing runoff at time t/Tc = 0.5 and the ratio of the maximum catchment width to the average width respectively. Substituting x for t/Tc the S-curve can therefore be represented by a cubic of the form: —- - ax2+bx2+cx , A (4.6) where the coefficients a, b, and c are given by: a - 4 ( 1 - ^ ) ; b - 6w-4h-4; c - 4h-2w+l; (4.7) The derivation of the time-area unit hydrograph is accomplished by first calculating the following while x ^ 1.0: —2 \ for each X.-JAJ* , i - 1 , 2 , 3 , . . (4.8) where At is the hydrograph time step, The ordinates, Uj, of the time-area unit hydrograph are then given by: u±-KA A K- • > i 360 A t i - l (4.9) 54 The factor K converts one millimetre of rainfall over one hectare (ie 10 m3) in one hour to an inflow in units of m3/s. The resultant unit hydrograph is shown in Figure 17 for a catchment where h = 0.4, w = 1.3, Tc = 0.6 hours, At = 5 minutes and A = 198 hectares. 4.5.2 Module route The time-area unit hydrograph takes no account of storage. The module route does so by routing the inflow through linear storage by the Muskingum method which is given by: °Ui - c 0 J i + 1 +c 1 j i +c 2 o i , where c,-- **-°-5t , 0 K-Kx+0.5fc Cl - J0?0'5* . (4.10) C K-Kx+O.St K-Kx-0.5fc 2 K-Kx+O.St ' where K is the Muskingum storage constant, x is the inflow constant, and t is the routing period. The development of these equations is well documented elsewhere (Lindsley et al. 1982) so it is not discussed here. The unit hydrograph which results from routing the 55 0.80 0.60 (fi I 0.40 0.20 0.00 0.00 0.40 0.80 1.20 X = t/T, Figure 17 Example unit hydrograph produced by Clark model 56 time-area unit hydrograph obtained above is shown in Figure 18 for a catchment having values K = 1.2 hours and x = 0.1. 4.5.3 Module Generaterunoff Having now obtained the unit hydrograph for a prescribed catchment, the runoff is easily obtained by multiplying the effective rainfall during each time step by the unit hydrograph ordinates. The flow, Q, at each time step, i, is obtained through a lag and add procedure so that: Q1=u1eri+u2eri_1+u3eri_2+ . . .+uier1 (4.11) where the effective rainfall, erj, is equal to the total rainfall during each time step minus the infiltration. The total flow is then calculated by adding the baseflow, B. 4.6 Fuzzy logic modules The encoding of the fuzzy algorithms used in this study was performed using the Personal Fuzzy-C Development System from Togai Infralogic, Inc. 1988-1991. The system compiles a source file containing the fuzzy set definitions and the rule set for a fuzzy algorithm into an output C file. The resultant output file was then linked to the simulation program and compiled to create an executable program. An example of the output C code is given in APPENDIX B. 57 0 50 100 150 Time (minutes) 200 250 18 Example unit hydrograph routed using the Muskingum method with parameters K = 1.2 hours and x = 0.1. 58 Some limitations of the Togai system made it necessary to modify the output C file to accomodate the fuzzy algorithms employed in this work. For example, the Togai system can compile a maximum of 12 rules. As a result, any additional rules had to be manually encoded in the ouput C file. Also, this particular system allowed a maximum of two input variables. However, as is discussed later, this study used fuzzy algorithms having three inputs. Again, the output file was modified manually. One unique characteristic of the Fuzzy-C output code is that it uses a modified form of the max-dot inference method that sums rather than unions the scaled fuzzy set membership functions. This results in smaller code and faster execution times since the centroid of the output membership function does not need to be calculated at runtime. Although the effect of using this technique has not been investigated, it is not believed to significantly affect the results. 59 5.0 Description of Control Scenarios The first step in implementing real-time control for a CSS involves the establishment of control objectives for the system. These objectives describe and clarify the nature of the control problem by defining the desired outputs and establishing the concomitant constraints on the controlled process. Having specified the control objectives, a control strategy can then be developed. In this work, a control strategy is defined as the time sequence of all regulator set points in a real-time control system (Schilling, 1989). Synonymously, the rules which specify such a time sequence may also be known as the control strategy. More specifically, the control strategy establishes the desired output level (in this case, flow) at selected measurement locations and the variable regulators are then adjusted to achieve that level. For example, given a fixed set point strategy, the regulator is operated in such a way that the output flow remains constant in spite of continual perturbations to the runoff process. The control objectives provide the basis for evaluating the effectiveness of the control strategy and for defining the constraints on the process. For example, at a given outfall location, the following two objectives may be specified: 1. minimize the total overflow volume; and 2. prevent the occurrence of flooding. Here, the first objective defines a performance criterion by which to evaluate the effectiveness of the strategy and the second constrains the strategy to prevent the occurrence of undesirable outcomes. Additional objectives related to controlling specific pollution parameters, reducing operation and maintenance (O&M) costs or public and 60 worker safety may be included as further constraints on the process. This study explores two CSO control scenarios in which the stated objectives are to be attained by diverting a portion of the incoming flow to a storage facility of finite capacity. These scenarios shall be referred to as the "First-Flush Capture Scenario" and the "Peak Capture Scenario". The storage facility in both cases is an off-line, near-surface tank that retains flow diverted from a trunk sewer using an adjustable gate regulator. Since the purpose of this study is simply to assess the feasibility of fuzzy inferencing for controlling CSO flows, and not to develop an optimal control strategy for any given site, the objectives for each control scenario are purposely simplified. Therefore, for the two control scenarios studied here, the primary control objectives are limited to pollution mitigation for the first and flood control for the second. There is no consideration given to objectives involving worker safety, emergency shut down or minimizing O&M as would be required for a real system. Such elements, though important in real systems, would tend to distract, rather than contribute, to the desired goals of this study. 5.1 First flush capture scenario During initial CSO monitoring programs in the early 1970s, it became evident that higher than average levels of contaminant loading were characteristic of the discharge during the early stages of a storm runoff event. Sanitary waste which settles in the pipe during dry weather periods in addition to metals, oils, animal waste and other sediments 61 which accumulate on impervious areas draining into the sewer system are quickly entrained by the higher flows at the beginning of a storm. Typically the average loading of key contaminants (i.e. TSS, BOD5, fecal coliform, etc.) during the first thirty minutes of a discharge event may be several times the average loading after sixty minutes (Moffa, 1990). Consequently, the greatest impacts upon receiving waters tend to occur during the early stages of the storm where concentrations of most contaminants are high. A typical control strategy for CSO reduction entails the retention of the initial flows during a storm runoff event in order to minimize first-flush impacts. This strategy makes use of available internal and external storage capacity to capture the potential overflow and hold it until downstream conveyance capacity is increased. However, once the available storage is exhausted, all flows which exceed the sewer system capacity are discharged directly into the local receiving waters. Presumably, by this time, the flows with the highest contaminant load have been retained so that the potential impact at that overflow point is lowered. 5.1.1 Description of first flush capture model A two sub-catchment model, as shown in Figure 19 was synthesized to serve as a case study for a first-flush capture simulation. It consists of a single interceptor servicing both sub-catchments with a fixed-height overflow weir, Wl, located just below the junction of the interceptor and the trunk main from Catchment B. Located at the base of Catchment B is a near-surface CSO storage tank with a capacity of 20,000 cubic metres. 62 Catchment A Catchment B 0\ u> Figure 19 Site plan of first flush capture model A regulator, Rl, (i.e. sluice gate or radial gate or similar structure) on the trunk main from Catchment B can be adjusted to divert between zero and 100 percent of the flow from Catchment B into the adjacent storage tank. An overflow pipe from the storage tank to the interceptor relieves the excess flow when the tank is full. Level sites at the locations marked LI and L2 indicate depth measuring devices which are used to calculate flows. LI measures the flow from Catchment B and L2 the flow in the interceptor at the overflow weir (which is comprised of flow from Catchment A and the portion of flow that is released from Catchment B). It is assumed that LI is located far enough upstream that the readings are unaffected by the backwater from Rl. In order to introduce further natural random variation into the process simulation, a model in which the two sub-catchments are separated from one another was adopted. This geographical isolation implies that the flows in the interceptor are subject to spatial variations in rainfall intensity as well as lag times in rainfall deposition as the storm traverses both sub-catchments (refer to Sections 4.2 & 4.3). In addition, the flows from Catchment A must be routed through a section of the interceptor before the confluence with flows from Catchment B. Hence, Catchment A flows are subjected to further attenuation. These factors, in addition to the differences in the runoff-routing parameters, shown in Table 2, create a level of complexity that is somewhat reflective of real systems. The overflow weir, Wl, regulates downstream flow in the interceptor. When the water level in the interceptor exceeds the height of the weir crest an overflow occurs. It is assumed that the weir will pass to the downstream inteceptor all flows less than or 64 Table 2 Runoff-routing parameters for subcatchments in first flush capture model Variable B (m3/s) Inf (mm/hr) A (ha.) w h K (hrs) Tc (hrs) X Catchment A 0.7 3 267 1.6 .4 .45 1 .1 Catchment B .52 3.5 198 1.3 .4 .35 .66 .1 equal to a constant overflow threshold. The portion of the flow that exceeds the threshold, which, in this case is 3.6 m3/s, is overflowed to the river. 5.2 Peak capture scenario The peak capture scenario is the second, and more difficult, control problem to solve. This time the objective is not, as was the case for the first flush capture scenario, to retain as much of the initial overflow as possible. Rather, the main objective is to minimize the peak flow issuing from the regulator site. For example, if the control objective is to capture the initial runoff, all available storage may fill up before the runoff subsides below the overflow threshold. In such an event, a sudden surge of high flows downstream of the regulator will occur since the excess flow cannot be retained within the system. The objective of the peak capture strategy, however, is to maintain sufficient 65 storage capacity in the tank at all times so that sudden surges are avoided. Hence, the control strategy must be able to specify an action in anticipation of the future inflows, increasing the release rate if it appears that the present rate will cause an overfilling of the tank, or decreasing it if it appears that the tank will be significantly underfilled at the conclusion of the event. The ability to control the process in anticipation of future inflows is the key factor in properly managing peak flows. In contrast to the first flush capture strategy, where the effectiveness of a control action can be evaluated immediately after its implementation (i.e. in terms of how close the release rate is to the overflow threshold), the effectiveness of the the peak capture strategy can only be assessed at the conclusion of the event. Hence, each control action must be specified with some sort of an "impression" about the effect that it will have on the final state of the event. Therefore, there must exist within the control mechanism, some method of incorporating that "impression" into the output set points. Otherwise, there would be no way of evaluating the effectiveness of any action that is specified during the process. The peak capture scenario is, admittedly, somewhat artificial for a combined sewer system since contaminant loading is usually of greater concern than flood control. More than that, combined sewer systems are designed to overflow the peak flows, thereby eliminating the risk of downstream flooding. Nevertheless, the practical applications of the problem extend beyond the scope of CSO control to the problem of real-time reservoir operation for flood control. The real time regulation of flows for flood control in a single or multi-reservoir system is subject to high levels of uncertainty associated with temporal storm patterns, 66 flow routing characteristics, differing management levels and priorities, and multiple control objectives. Generally, however, the greatest uncertainties are associated with inflow prediction over both the short and the long term (Malinowski, 1988). The necessary predictive time horizon required for effective reservoir operation tends to increase with the magnitude of the reservoir operation. That is, for a large-scale reservoir, a prediction of future inflows over the next several weeks, months and possibly years may be required to effectively manage the flows. On the other hand, a small reservoir, designed to handle only sporadic urban peak flow occurrences, may require a predictive horizon of only days or even hours. Of course, the longer the predictive horizon, the greater is the uncertainty in the estimated flow values. The combined sewer system peak flow reduction model is therefore a simplified case of the general reservoir operation problem because the predictive horizon falls within the time frame of several hours. While still incorporating much of the uncertainty associated with temporal storm patterns and flow routing characteristics, a long term forecast of climatological trends is not needed. 5.2.1 Description of peak capture model The peak capture model consists of a single catchment having the same parameters as Catchment B from the first-flush capture model (see Table 2). A variable regulator is located at the base of the catchment to divert flows to an off-line, near-surface storage facility having a capacity of 5000 m3 (see Figure 20). A fixed-height overflow weir downstream of the storage overflow pipe discharges the portion of the flow exceeding 1.8 67 Figure 20 Site plan of the peak capture scenario model 68 m3/s directly into the receiving stream. This overflow threshold can to be considered the "safe" release rate below which no flooding will occur. The task of anticipating and capturing the peak runoff requires more information than was required for first-flush capture. In addition to level sensors LI and L2 located above the regulator and at the overflow weir respectively, several additional real-time sensors are provided. A sensor located inside the storage tank, L3, indicates the fullness of the tank, and a rain-gauge (of the tipping bucket variety), Gl, located in the middle of the catchment, provides on-line measurements of rainfall intensity. 5.3 Modelling assumptions In both scenarios outlined above, the runoff simulation has been simplified by neglecting some constraints which would otherwise be relevant in a real system. It was perceived that these constraints produced effects that were secondary or peripheral to the central problem and hence could be neglected. The following assumptions were applied to the runoff simulations: 1. There is no flow capacity limit on the trunk mains and on the interceptor upstream of the overflow weir. That is, it is assumed that the pipes are sufficiently large so as to ensure open channel flow in all situations; 2. Base flow (average dry weather flow) and infiltration rates are constant; 3. Backwater and surging effects are neglected; 4. In-pipe storage capacity in the trunk mains is ignored; 69 5. The storage tank is completely empty before the start of any storm. These assumptions, while simplifying the model considerably, should not detract significantly from the results of the fuzzy control strategies proposed herein. 70 6.0 First Flush Capture Control Strategy This chapter describes the development and the results of applying fuzzy techniques to the first flush capture problem. As mentioned in the previous chapter, this type of scenario is more likely to be encountered in real combined sewer systems as opposed to the peak flow capture scenario dealt with in the next chapter. Consequently, as far as CSS control is concerned, the issues dealt with in the first flush capture scenario are most relevant. 6.1 Control strategy development The experience required to construct a fuzzy rule base to control the runoff model was obtained by the developer through a "hands-on" interactive process. This involved the developer monitoring the conditions in the system at each time step during the simulation and then trying to prescribe a control action that would accomplish the stated control objectives. Initially, of course, the user lacked any knowledge of the control dynamics, but as more time was spent interacting with the simulation, a significant experience base was developed. Through the experience gained by manually controlling the flows, a set of rules of thumb, expressed in linguistic form, was developed which could then be translated into a fuzzy decisional algorithm suitable for controlling the process. The fuzzy decisional algorithm was then encoded into the computer language, C, and linked to the runoff simulation. Trial runs were performed for a series of randomly-71 generated storms to assess the effectiveness of the control algorithm. When deficiencies were observed, the causes were noted and appropriate alterations of the fuzzy rule base were made. In certain cases the fuzzy sets were modified to more closely reflect the linguistic expressions they represented or sometimes individual rules were changed or added to respond more effectively to different process states. Through such a trial and error procedure the fuzzy controller was progressively refined to handle a wide variety of flow situations. 6.2 Description of fuzzy controller Effectively, the objective of the first flush capture control strategy is to maintain the flow at the weir, Wl, just below the overflow threshold by regulating the percentage of the flow diverted into storage at Rl. By interacting with the simulation in real time, the developer found that this objective could be accomplished manually by observing the changes in two state variables and by responding accordingly. Those two variables are the value of the overflow at the weir, OF, and the incremental change in the flow issuing from catchment B during the last time step, AQ. The variable OF is expressed relative to the overflow threshold. That is, a negative value of OF indicates that the flow is below the threshold, a positive value above the threshold, and zero OF indicates that the flow is just at the top of the weir crest. Having established this relationship in heuristic form, a fuzzy rule base was constructed that incorporated the elements of the developer's experience of manually operating the control structure. The two inputs, OF and AQ, and the one outgwt, AD, 72 were divide into fuzzy regions as shown in Figure 21. The nomenclature used to label individual fuzzy sets follows a common fuzzy logic convention of designating these on a real number scale ranging from the most negative, NL (i.e. negative large) to the most positive, PL (i.e. positive large) for OF. These fuzzy sets were then compiled into the fuzzy rule base summarized in Table 3. Hence, an individual rule, Rule 3 for example, may be stated linguistically as follows: "If overflow is positive small and the flow increment is zero then the change in diversion is positive small" Due to some overlap, the fuzzy mapping in Table 3 reduces to a set of 11 such rules. Table 3 Fuzzy mapping of the first flush capture controller Flow Incre-ment, AQ NEG ZERO POS Overflow, OF NL NL11 NL11 NL11 NS NS10 NVS9 zo8 zo zo7 PS6 PS5 PS zo4 PS3 PL2 PL PL1 PL1 PL1 Key: Superscript refers to rule number in rule base. 6.3 Results The fuzzy mapping illustrated in Table 3 represents the final result of a trial and error process to tune the fuzzy algorithm. The initial attempts to develop a functional controller resulted in a highly unstable response and a generally ineffective control strategy. However, as the fuzzy algorithm was progressively modified, the controller 73 a) 1.5 0.5 -0.8 -0.6 -0.4 -0.2 0 0.2 0.4 0.6 0.8 1 Overflow, OF {m3/s) -0.6 -0.4 -0.2 0 0.2 Inflow Increment, AQ (m3/s) 0.4 0.6 -50 -40 -30 -20 -10 0 10 20 Change in Diversion, AD (%) Figure 21 Fuzzy regions for first flush capture controller 30 40 50 74 response became more stable and effective. Figure 22 illustrates three stages in the fuzzy rule base tuning process for a single storm. They represent the controller response to the initial fuzzy rule base, to the finalized rule base shown in Table 3, and to an intermediate rule base. There are four curves shown on each of the hydrographs in Figure 22. They represent the flow from Catchment A, the flow from Catchment B above the regulator, the overflow at the weir and the flow released from the regulator. In this particular case, the flow from Catchment A exceeds the overflow threshold of 3.6 m3/s, so that even though all flow from Catchment B is being diverted to storage, a positive overflow still occurs at the weir. It can be seen from this figure that, through a trial and error process of adjusting rules and fuzzy sets, the controller response improved considerably. The fully tuned response shown in Figure 22(c) illustrates the effectiveness of the fuzzy algorithm. Recalling that the only inputs to the controller are the overflow and the flow increment from Catchment B, the controller reponds to the rapidly changing flow conditions from both catchments reasonably well. The diversion of flow to storage begins at the 40 minute mark. Here, the fuzzy value of OF is mostly NS but partly ZO and the value of AQ is POS. Consequently, a slight increase in the rate of diversion is observed as a result of the interaction of rules 5 and 8. At the 45 minute mark, the overflow is very close to zero. Therefore, the controller responds more agressively by increasing the diversion rate significantly, primarily by applying Rule 5, to prevent a positive overflow from occurring. The overflow is maintained below the zero level until the 90 minute mark. At this point, however, the controller does not respond as aggressively as may be desired for this 75 6 Time since start of storm (minutes) Catchment ° Catchment B ° Release Set Overf low A Inf low Inf low Point Figure 22 Tuning of the fuzzy controller for Sim # 4620F showing a) initial, b) intermediate, and c) final controller response. 76 situation. This is because the flow from Catchment B has already peaked and is beginning to recede. As a result, the fuzzy value of AQ becomes ZO or even NEG and with OF being ZO, rules 6 and 7 are applied. Hence, the change in diversion is between ZO and PS; not as large as required to bring the overflow back below zero. However, a more aggressive approach than this is generally undesirable. This is because this case represents a relatively unique condition where the flow from Catchment B is declining while the Catchment A flow is still rising rapidly. In the contrary case where the flows from both catchments are declining at the same time, if OF is PS a response greater than AD is ZO would result in overcompensation. That is, if both flows are already receding, then increasing the diversion rate would result in the overflow falling too far below zero. At the 100 minute mark, the regulator gate is fully closed and all flow is diverted to storage. Nevertheless, since the flows from Catchment A are greater than the overflow threshold, an overflow occurs. Once the flow from Catchment A falls below the overflow threshold at the 180 minute mark, the controller responds by decreasing the diversion rate to storage. The regulator gate opens rapidly until all Catchment B flow is being released. By this time, the inflow has receded to almost baseflow levels. In general, then, the fuzzy controller responds quite well to a storm of this nature. There is only minimal unnecessary overflow while, at the same time, the amount of flow diverted to storage is not excessive. In can be reasonably stated, therefore, that the prespecified control objectives have been achieved (see Chapter 5). This event is a typical short duration, high intensity storm. However, in order to verify the effectiveness of the controller, it must be tested under different conditions. Figure 23 shows the controller response to a runoff event resulting from a longer, lower 77 o 500 -0.5 Time since start of storm (minutes) Catchment A Inflow Catchment B Inflow Release Set Point Overflow Figure 23 Sim #7402F - Long duration storm example 78 intensity storm (Sim # 7402F). In this case, the flow from Catchment A isn't large enough to exceed the overflow threshold. It is, however, of relatively long duration, so it is desirable that the controller not divert excess flow in order to maintain storage capacity for the latter stages of the event. It can be seen that the controller maintains the overflow between 0 m3/s and about -0.4 m3/s (i.e. a negative overflow indicates that the flow is less than the overflow threshold) with an average of about -0.2 m3/s throughout the duration of the diversion period. This results in the storage tank being slightly overfilled by the end of the event. The local peak in the overflow hydrograph at time 380 minutes represents the overflow from the storage facility. In this case, however, it was not large enough to cause an overflow at the weir. Generally, then, the controller appears to respond reasonably well to this type of event. It may be possible to bring the overflow a little closer to zero in a case such as this, but that will only result in minor benefit. Moreover, it is better to adopt a risk averse strategy and avoid overflow over against storing flows unnecessarily. The two simulations discussed here are fairly reflective of the results of many more simulations performed using the fuzzy controller. In cases where the flow from Catchment A exceeded the overflow threshold, the controller usually quickly drove the diversion rate to 100% with very little unnecessary overflow. In cases where Catchment A flows did not exceed the threshold, the overflow was consistently maintained just negative. Although it wasn't attempted in this study, further refinement could presumably be achieved by implementing a three input controller. That is, in addition to OF and AQ, the flow increment from Catchment A may also be included as an input. This should 79 resolve some of the difficulties noted in the first example where the controller is responding to a somewhat ambiguous situation. Nevertheless, the reponse based upon just the two inputs appears to be adequate so no further refinement was pursued. 6.4 Discussion of results From the limited assessement undertaken here, it appears that fuzzy techniques are readily and effectively adaptable to the first flush capture problem. In terms of the control objective of capturing the initial flows during the event, the controller was quite successful. In this case, the amount of available storage was quite large in relation to the magnitude of the runoff events encountered. As a result, there were few difficulties associated with too much diverted flow leading to insufficient storage later in the event. Nevertheless, in simulations where the overflow could be maintained below zero, the controller seemed quite effective at preventing too much diversion from occurring. One of the noteworthy aspects of the controller is that it is able to respond effectively with only minimal information. This controller utilized inputs representing the flow at the weir and the flow increment from Catchment B. Alternatively, a fuzzy controller could have been designed that incorporated a third input - the flow increment from Catchment A. A properly tuned, three input controller would probably have produced a somewhat smoother response, but the improvement in performance would only be marginal. The implication of this result, then, is that fuzzy methods are quite useful for handling fairly complicated processes given limited (but the right kind of) 80 information. Thus, for application in a real CSS, fuzzy techniques could be effectively implemented without the necessary investment in expensive and computationally intensive modelling. Rather, a simple heuristic model is all that is really needed to manage the flows according to the desired control objectives. The computational effort that is required is negligible relative to other more sophisticated methods and the development time should also be considerably lower. 81 7.0 Peak Capture Control Strategy The peak capture scenario is the more complex of the two dealt with in this study. Whereas the objective of the first flush capture strategy was to maintain the outflow at the overflow weir at or below a predetermined fixed value, the outflow from the peak capture control scenario can vary considerably depending upon the nature of the storm. In the first flush capture case, the release rate from the regulator could be determined based upon the value of two, or at most three measured variables. As a result, the control strategy could be expressed linguistically in terms that could be easily translated into a fuzzy algorithm. In the peak capture case, however, the number of variables required to ascertain the appropriate response is much greater. More than that, some means of anticipating the future inflows to the regulator site must exist so that sufficient capacity can be maintained in the storage tank to capture all peak flows. As discussed previously, the control objective for the peak capture strategy is to retain peak inflows subject to the available storage volume in the tank. Before an automatic controller can be designed to accomplish that objective, however, the control process must be sufficiently well understood that it can be translated into a fuzzy algorithm. That is, for a given set of input state variables (i.e. variables describing the state of the process at any point in time), it should be possible to to specify a response that will probably produce favourable results. The task of developing such an understanding is demanding, though. Even for the single catchment, single reservoir model being used in this study, the relationship that exists between the state variables and the corresponding "best" release rate is highly complex. 82 In view of these complexities, two methodologies were developed in an attempt to create an effective control strategy. The first method utilized the capability of the storm generation module to reproduce identical rainfall hyetographs and runoff hydrographs. By repeating a single storm simulation several times, it is possible, using the perfect information available through hindsight, to determine a manual control response that will minimize the peak flow. Having obtained a good enough response, the step by step input and output data from the manually-controlled simulation was preserved in database form. It was postulated that by mapping out the data from a large number of simulations controlled using perfect information, a pattern of "optimal" control actions could be identified. From this data a fuzzy control algorithm that reflected those patterns could then be developed using a special adaptive procedure. This method shall hereafter be referred to as "Method A" and the resultant controller as "Controller A". As it shall become evident later in this discussion, "Method A" was only marginally effective. In fact, in most cases, the performance of the fuzzy controller derived using this method was quite ineffective in satisfying the control objectives. As a result, a second method was pursued in which an on-line, rainfall-runoff transformation model was provided to render real-time predictions of inflows over an horizon equal to the time of concentration. Using this predictive capacity, a crisp control function relating peak flow and the optimal release rate was used to select release set points on-line. However, since there is some natural deviation from a crisp peak flow/optimal release rate relationship encountered during most simulations, some adjustment of release set points is necessary to better manage the flows. Hence, a fuzzy adjustment algorithm was devised that could manipulate the set points based upon the values of other state 83 variables. This method shall hereafter be referred to as "Method B" and the controller as "Controller B". 7.1 Control strategy development: Method A In a real-time flood control situation, decisions must be made on-line based upon limited information about the state of the runoff process. Sometimes, for lack of knowledge about future inflows, decisions must be made based upon intuition or even guesswork. Through experience these attempts at managing for future unknown flows may become refined, but they are still subject to considerable uncertainty. In such cases, the availability of perfect information is a highly desirable commodity. If it were possible to fully know in advance when and how large future inflows will be, then it should be possible to optimally control the flood flows so as to meet the control objectives. Perfect information is never available to the on-line controller. However, over time, a significant historical record of storms is built up, and for each of those storms, a review of the outlfow hydrograph after the event provides, in effect, the perfect information required to ascertain an optimal control response1. By compiling the data from a large number of simulations controlled manually using such perfect information, it 1 The term "optimal" is used rather loosely here and in the remainder of the discussion. In this study the only condition of optimality is that the tank is between 95% and 100% full at the conclusion of the runoff event. This condition, however, doesn't consider the magnitude of peak flows during the event, which may actually be considerably greater than the minimum possible. The condition of "optimality" of a specific output set point at each time step is even more elusive. In this usage, a specific output is optimal only in so far as it is one in a series of outputs that lead to an optimal result. In other words, all set points in a simulation are optimal if the condition of optimality is met at the conclusion of the event. 84 may be possible to recognize patterns of control actions that lead to near-optimal responses under a wide range of storm runoff conditions. Having determined such patterns, it should be possible to incorporate them into an automatic fuzzy controller that can effectively manage flood flows. This is, in essence, the strategy employed in Method A. Using the storm generation and rainfall-runoff transformation model developed for this study, a set of 42 different simulations were repeatedly executed in order to obtain optimal results. It was felt that this number should be sufficient to encompass a fairly broad range of flow conditions thereby forming the basis for a controller capable of dealing effectively with most events. During each simulation, the objective was to determine a constant release rate that would result in zero overflow at the weir, or if overflows were inevitable, to make full use of the available storage so that by the end of the simulation, the tank would be between 95% and 100% filled. A trial and error procedure was applied to each storm simulation to try to establish the optimal set point. For example, for the storm shown in Figure 24(a) a release set point of 1.75 m3/s (i.e. just below the overflow threshold), results in the tank filling before the peak inflows subside. By observation, a second release set point of 1.85 m3/s is selected. This time the peak inflows are successfully reduced but the tank is only 89% filled (Figure 24(b)). A third attempt, using a release of 1.80 m3/s, results in complete capture of peak inflows and the tank being 99% filled (Figure 24(c)) as desired. 85 a) 2.5 5 2 E ~ 1.5 I , 0.5 / ^ . 120 100 80 60 40 # •o 9 10 D o o> S o *-w 20 50 100 150 200 250 300 350 400 b) 2.5 § * ~ 1.5 I , 0.5 —*_ QAjtl'VVYYT 120 100 _ 80 60 40 20 I I 50 100 150 200 250 300 350 400 120 100 # o 1 50 100 150 200 250 300 Time since start of storm (minutes) 350 400 Inflow Trial Release Rate Overflow Storage Used Figure 24 Determination of optimal set point by trial and error 86 Table 4 Process variables selected to represent the runoff state during manual control simulations Variable t Qin AQin Qw s i teos R Unit minutes m3/s m3/s m3/s % mm/hr minutes m3/s Description time since the beginning of the storm inflow at the regulator, level site LI flow increment at the regulator, level site LI flow at the weir, level site L2 percentage of the storage tank that is filled rainfall intensity measured at gauge Gl time since the end of the storm release set point This procedure was repeated for each of the 42 simulations. After each time step the values of the process state variables and the output set point were recorded to disk. In order to characterize the flow conditions as completely as possible, the process state variables shown in Table 4 were selected as the most strategic. Presumably, this information represents a fairly complete description of the step by step control process for each simulation. Once all 42 optimized storm simulations were completed and recorded, all the data was written contiguously to a single database. This data was then transformed into a fuzzy control algorithm using the Fuzzy Associative Memory Bank (FAMB) procedure as described by Wang and Mendel (1991). In their paper, they present a methodology for developing an adaptive fuzzy control system in which the FAMB "learns" how to respond to a given set of input variables based upon the control patterns from a set of example control scenarios. For example, consider a set of n input-output data pairs: where x^ and x2' are inputs and y1 is the output for set i. The task here is to generate a 87 (xl.x^y1) , ixl.xi;y2) , . . . (x1i,x2i;yi) (xxn,x2n;y») (7.1) set of fuzzy rules from the set of data pairs (7.1), and to use these fuzzy rules to define a mapping f:(x1} x2,) -»y. Or, using the example database derived in this study, the FAMB method creates a fuzzy mapping f:(t, Qin, AQin, OF, S, i, teos) -»R. The procedure for building a FAMB is summarized by the following headings: Step 1: Divide the Input and Output Spaces into Fuzzy Regions Step 2: Generate Fuzzy Rules from Given Data Pairs Step 3: Assign a Degree to Each Rule Step 4: Create a Combined FAM Bank Step 5: Determine a Mapping Based on the Combined FAM Bank In this study, this procedure is modified somewhat to accommodate the unique facets of the peak-capture problem. In particular, the third step, which is provided to resolve conflicts between rules (i.e. a conflict occurs when two rules having the same antecedents have different consequents), has been modified. The reason being that this step requires the developer to assign a degree of importance to each rule. Given that the number of rules generated from the peak-control examples is over one thousand, the amount of manual work required to do so was deemed excessive and has therefore been avoided. However, the issue of handling conflicting rules was resolved by another method as will be explained later. For each of the recorded input and output variables, a set of fuzzy regions (i.e. fuzzy sets) were assigned to their universes of discourse in accordance with Step 1 above. These fuzzy regions are shown in Figure 25. Then, for each record (i.e. one record 88 b) 1.5 0.5 0 1.5 0.5 d) 1.5 0.5 100 200 300 400 500 600 Time since start of storm, t (minutes) 2 3 Inflow, Qjn (m3/s) -0.6 -0.4 -0.2 0 0.2 0.4 0.6 Flow increment from Catchment B, AQjn(m3/s) -2 -1.5 -1 -0.5 0 0.5 1 Overflow at weir, OF, (m3/s) 1.5 Figure 25 Division of state variables into fuzzy regions - for a) time, b) inflow, c) inflow increment, and d) flow at weir 89 f) 1.5 0.5 g) 1.5 0.5 h) 1.5 0.5 Time since end of rainfall, te o r , (minutes) 20 40 60 Storage Used, S f (%) 10 15 20 Rainfall intensity, i (mm/hr) 1.6 1.8 2 2.2 Release Rate, R (m3/s) 80 25 2.4 100 30 2.6 Figure 25 Division of state variables into fuzzy for e) time since end of storm, f) storage, g) rainfall intensity, and h) release rate. 90 represents the inputs and outputs for one time step), a fuzzy rule was deduced by assigning to each variable the fuzzy value having highest membership for the numeric value. That is, the membership of each discrete input or output numeric was calculated for each fuzzy set on the input or output space. The fuzzy set having the highest membership was then selected as the value of the input or output. For example, if the value of OF is 1.98 m3/s, its membership in fuzzy set PS is 0.8 and its membership in PM is 0.3. In the corresponding fuzzy rule, OF takes on the fuzzy value with the highest membership which is PS. Table 5 shows the numeric values and the corresponding fuzzy values assigned to each variable for one example database record. Using a computer program, this process was repeated for the data from all 42 storms yielding a database consisting of over a thousand records, each one, in effect, representing a fuzzy rule. This process satisfied Step 2 above. The next task was to extract a manageable number of rules from this database to form an effective control algorithm. This was complicated by two factors. Firstly, as noted above, a method of differentiating between conflicting rules that is less time and effort-intensive than what is suggested in Step 3 was required. Secondly, with 8 possible inputs in each rule, the number of potential combinations was excessive (over 6000). It was therefore necessary to limit the antecedents to the two or three most important variables in order to keep the rule base within a practical size. As a first effort, the time since the start of the storm, t, the inflow, Qin, and the inflow increment, AQin, were selected as inputs and the release rate, R, as the output. Other variables could justifiably have been chosen in addition to these. In particular, the 91 Table 5 Assignment of fuzzy values to numeric inputs for one example database record Variable t Qin dQin Qw s i leos R Numeric Value 160 min 2.60 m3/s 0.003 m3/s 0.15 m3/s 75 % 6.47 mm/hr 0 1.98 m3/s Fuzzy Value MID MED ZERO ZERO HI LOW ZERO M_OF variable Storage, S, could have been included as an input since the volume of unused storage is one of the most important factors to assess in determining the output level. However, during the manual trial and error control process for each simulation the optimal release rate was that which resulted in the tank being almost full at the end of the storm. Therefore, though not defined explicitly as an input variable in the fuzzy algorithm, the amount of storage available is defined somewhat implicitly in the values for the selected variables. All combinations of the three selected inputs, ignoring the values of the other input variables, were compiled and tabulated as shown in Table 6. Here, the number 92 Table 6 Number of occurrences of fuzzy outputs for each set of inputs in example database Inputs1 t EARLY MID LATE Qi„ LOW MED HIGH VHIGH LOW MED HIGH VHIGH LOW MED HIGH VHIGH . AQin KEG ZERO POS NEG ZERO POS NEG ZERO POS NEG ZERO POS NEG ZERO POS NEG ZERO POS NEG ZERO POS NEG ZERO POS NEG ZERO POS NEG ZERO POS NEG ZERO POS NEG ZERO POS Release Rate, R Number of Occurrences Z_OF 0 24 4 o 4 0 0 9 9 9 0 o H 6$ l U 73 2 2 5 1 0 0 0 20 146 0 2. 34 0 0 Q 0 9 0 9 S_OF 0 10 20 0 21 8 0 1 0 o 0 o 6 47 4 32 100 2 3 33 0 0 0 0 32 44 2 17 57 2 3 5 2 0 0 9 M_OF 0 0 6 0 2 9 0 4 3 0 0 o 2 4 2 13 29 0 8 20 1 0 2 0 7 8 0 4 17 0 1 10 0 0 0 o L_OF 0 0 1 0 1 5 0 0 3 0 0 0 0 1 0 6 13 3 7 19 1 4 5 3 1 0 0 3 0 0 5 7 0 0 0 9 0 0 0 0 2 3 0 1 1 4 1 2 0 0 0 2 5 3 2 3 4 6 2 6 0 0 0 1 0 0 1 0 0 3 6 i Wfd Avg VLOF Z OF S OF S OF M OF M OF L OF VLOF VL OF VL OF Z OF Z OF S OF S OF S OF M OF M OF M OF L OF VL OF L OF VL OF S OF Z OF S OF S OF S OF S OF M OF M OF S OF VL OF VL OF VL OF 1 1. R is Z_OF for all cases where Qin is VLOW. 93 of occurrences of each output value in the example database is shown for every possible combination of the three input variables. In effect, this table represents the FAM Bank suggested in Step 4. It is a mapping from a three-dimensional input space to a single-dimensional output space. Note that for almost every combination of fuzzy inputs, more than one output fuzzy value results. In order to form these into rules, only one output can be applied for each rule. These conflicts were resolved by using a weighted average approach where the output fuzzy sets Z_OF, SOF, MOF, LOF, and VLOF were assigned ordinal values of 1, 3, 5, 7 and 9 respectively. Using the number ofoccurrences of each fuzzy output as the weight, a single output value, R- was obtained as follows: E nii Tj i € 1 , 3 , 5 , 7 , 9 ( 7 . 2 ) A . - = — , i 6 1 , 3 , 5 , 7 , 9 where nJ is the number of occurrences of the fuzzy output corresponding to the ordinal i in rule j . The fuzzy set with ordinal closest to the value of R was selected as the appropriate output for each rule. For example, for Rj equal to 4.2 the fuzzy output for rule j became M_OF. Due to significant overlap, the number of fuzzy rules was reduced to 19 from the 45 possible combinations of the three inputs. A fuzzy mapping summarizing these rules as required by Step 5 is shown in Table 7. However, considerable uncertainty is associated with certain flow conditions due to their rarity of occurrence. The input combinations that occurred 10 or fewer times in the example database are shaded in the table. These are associated primarily with the extreme flows or with positive flow 94 Table 7 Fuzzy mapping of Controller A rule base t EARLY MID LATE Qin VLOW LOW MED HIGH VHIGH VLOW LOW MED HIGH VHIGH VLOW LOW MED HIGH VHIGH AQin NEG Z OF 4 Z OF* * Z OF* ' M OF* ,u VL OF " Z OF Z OF iy S OF " M OF ^ VL OF 'a Z OF il Z OF J4 S OF J / M O F w VL OF 4J ZERO Z OF Z OF S OF M OF l< VL OF i# Z OF w Z O F M S OF ^ M OF VL OF ™ Z OF " Z OF S OF M OF 41 VL OF "* POS Z OF J S OF M OF y L OF " VL OF " Z OF S OF lv M OF "4 L OF VL OF ** Z OF " Z OF S OF M OF 4Z VL OF n Key This combination of inputs did not occur in the example database. Therefore a fuzzy output value has been interpolated. Shaded cells indicate fewer than 10 occurrences of the input combination in the example database. L O F Emboldened fuzzy output indicates different output than determined from example database. 95 increments during the mid or latter stages of the storm. In only two of the 42 example storms was the inflow high enough to be rated VHIGH. Therefore, although Rule 10 assigns an output of R is VL_OF for all extreme flow situations, the historical basis for this judgement is limited. In some cases, there were no occurrences of the input combinations in the example database. Notably, the combination of t is EARLY and AQin is NEG and Qin is LOW, MOD, or HIGH, does not occur within the example database at all. However, to complete the rule base, the fuzzy outputs for these rules were selected by interpolation from the surrounding fuzzy regions. In the emboldened rules marked in Table 7 a fuzzy output value was selected that differed from the output specified in Table 6. This was done to provide a smoother response between adjacent fuzzy input regions. For example, when t is EARLY and Qin is MOD and AQin is ZERO, the appropriate output, as determined from the example database, would be R is Z_OF. However, the response dictated by the example database for the input combinations of the cells immediately above and below that one (i.e. t is EARLY, Qin is LOW, AQin is ZERO and t is EARLY, Qin is HIGH, AQin is ZERO) are R is Z_OF and R is M_OF respectively. In order to provide a smoother response between these two adjacent regions, an output of R is S_OF was selected for the rule in question, rather than Z_OF as specified in Table 6. 7.1.1 Results In order to allow a direct comparison of the effectiveness of the fuzzy algorithm, it was tested using the same 42 storms that were used to derive the example database. 96 The results of the control simulations using Controller A are summarized in Table 8. Included in this table are the volume of overflow, the percentage of the storage tank that is filled at the end of the event and the peak overflow experienced during both the manual and the fuzzy controlled simulations. In addition, the peak inflow and the maximum possible overflow for each storm are presented so that the relative effectiveness of each control simulation can be compared with the uncontrolled response. It is readily apparent from the numbers presented in Table 8 that the fuzzy algorithm was only modestly effective in reducing peak flows. In fact, the flow at the weir, Qw, (equal to the overflow, OF, plus the overflow threshold of 1.8 m3/s) resulting from fuzzy control is an average of 13% greater than the flow resulting from manual control. Of course, the manual control simulations represent an idealization of the control process where the release rates have been "perfected" through hindsight. Therefore, when the increase in overflow due to fuzzy control is quite small (i.e. 0% to 5%), as is the case for several storms, the fuzzy controller can be considered effective. However, in many of the simulations the response of the controller is much less satisfactory. In several simulations, the storage facility is completely filled before the runoff fully recedes. Of the 42 simulations using the fuzzy controller, 15 resulted in the tank filling completely or overflowing before the runoff subsided. Of these, eight simulations, marked with an asterisk (*) in Table 8, resulted in the peak flow occurring after the tank had filled. In some of the latter cases, the peak flow at the weir due to fuzzy control was up to 46% greater than under manual control. However, even neglecting the simulations where the peak flow occurs after the tank is filled, the peak flows from the fuzzy controller are still 10% greater than from manual control. 97 Table 8 Summary of results of Controller A simulations Storm * 1000 1051 1290 1403 1634 1779 2084 2227 2305 2494 2652 3063 3780 4085 4212 4227 4269 4321 4338 4407 5173 5348 5515 5678 5720 6394 6411 6496 6933 7070 7138 7393 8002 8642 8765 8820 9031 9201 9320 9729 9993 9999 Average Maximurr Minimum Peak Flow (mVs) 2.98 2.69 2.77 3.26 2.26 3.55 2.48 2.53 2.97 2.22 2.25 1.97 5.45 2.1 2.88 3.03 1.88 2.98 4.29 4.24 2.51 2.76 2.04 1.44 2.65 2.28 2.79 2.6 2.87 2.97 2.67 2.54 3.5 2.53 3.11 1.76 2.37 2.58 2.5 3.02 2.97 3.19 I i Max. O/F (m'/sl 1.18 0.89 0.97 1.46 0.46 1.75 0.68 0.73 1.17 0.42 0.45 0.17 3.65 0.3 1.08 1.23 0.08 1.18 2.49 2.44 0.71 0.96 0.24 -0.36 0.85 0.48 0.99 0.8 1.07 1.17 0.87 0.74 1.7 0.73 1.31 -0.04 0.57 0.78 0.7 1.22 1.17 1.39 Manual Control Vol. of Storage overflow) Used m3 2154 0 691 1697 0 3319 0 0 413 0 0 0 2731 0 239 1902 0 953 3872 8374 0 670 0 0 242 0 32 1484 1735 1113 913 0 3427 66 2670 0 0 0 0 0 1368 3023 I % 98 90 97 99 78 95 79 94 99 41 37 10 95 23 96 95 6 96 98 97 72 98 28 0 98 59 99 93 100 98 99 83 96 96 99 0 60 97 54 100 99 95 Peak Controller A Reduct'n Vol. of overflow| of peak m'/s 0.27 -0.01 0.09 0.26 -0.02 0.47 -0.01 -0.01 0.07 -0.03 -0.04 -0.03 0.93 -0.004 0.05 0.23 -0.03 0.14 0.79 1.11 -0.04 0.11 -0.04 -0.36 0.04 -0.03 0.02 0.16 0.23 0.14 0.11 -0.03 0.42 0.02 0.4 -0.04 -0.02 0 -0.03 -0.01 0.17 0.42 % 3 1 % 33% 32% 37% 2 1 % 36% 28% 29% 37% 20% 22% 10% 50% 14% 36% 33% 6% 35% 40% 3 1 % 30% 3 1 % 14% 0% 3 1 % 22% 35% 25% 29% 35% 28% 30% 37% 28% 29% 0% 25% 30% 29% 4 1 % 34% 30% 28% 50% 0% Storage overflow| Used m1 2019 584 576 1535 1038 2881 1139 671 953 608 690 193 2682 328 834 1530 161 781 3519 8023 432 948 638 0 960 590 500 1073 1681 1015 1081 561 3205 1262 2274 0 538 530 534 614 1303 2656 % 121 74 100 108 48 117 40 72 88 21 17 3 97 15 84 116 0 103 113 200 57 95 6 0 83 40 91 107 118 104 98 65 115 71 137 0 40 84 38 83 109 140 Peak overflow m3/s 0.6 • 0.19 0.14 0.59 * 0.17 0.96 0.21 0.17 0.25 0.13 0.17 0.13 0.98 0.11 0.19 0.44 • 0.08 0.23 0.98 2.44 * 0.14 0.37 0.13 -0.36 0.19 0.12 0.35 0.32 • 1.04 * 0.33 0.23 0.2 0.98 0.23 1.3 • -0.04 0.13 0.19 0.25 0.3 0.54 • 1.27 • Reduct'n] Change i of peak % 19% 26% 30% 27% 13% 22% 19% 22% 3 1 % 13% 12% 2 % 4 9 % 9% 3 1 % 26% 0% 3 2 % 35% 0% 23% 2 1 % 5% 0% 25% 16% 23% 18% 1 % 28% 24% 2 1 % 2 1 % 20% 0% 0% 19% 23% 18% 30% 2 1 % 4% 19% 49% 0% in Qw % 16% 1 1 % 3% 16% 1 1 % 22% 12% 10% 10% 9% 12% 9% 2% 6% 8% 10% 6% 5% 7% 46% 10% 14% 10% 0% 8% 8% 18% 8% 40% 10% 6% 13% 25% 12% 4 1 % 0% 8% 1 1 % 16% 17% 19% 38% 13% 46% 0% " Peak flow occurs after the tank fills completely. 98 Viewed another way, the effectiveness of the controller can also be assessed by comparing the percentage reduction in peak flow from the uncontrolled result. Controller A produces an average decrease in the peak flow of 19% (max. 49%, min. 0%) compared with the manual result of an average decrease of 28% (max. 50%, min. 6%). The manual result of 28% represents a baseline standard by which subsequent simulations can be measured since it effectively represents the best possible result given the set of simulations used. Example runoff control simulation results In the following section, a representative sample of the control simulations are presented along with a discussion of the strengths and weaknesses of the methodology. The response of the fuzzy controller to different runoff patterns varied considerably. In some cases, the response was quite good, resulting in only marginally higher flows than with manual control. In other cases, however, the fuzzy algorithm was found to be highly inadequate for on-line control of the regulator. The reasons for this variation can be best deduced from an analysis of individual storms. In a few cases the fuzzy controller response was good. One of these is Sim # 1290A, shown in Figure 26. Here, the peak flow at the weir increases by only 0.05 m3/s over the optimized manual control response. Moreover, the storage facility is completely full with no overflow at the conclusion of the runoff event, thereby satisfying the prespecified control objectives. That is, though some chaotic behaviour is noticeable in the controller response, the peak flows are effectively minimized while making full use of 99 2.5 1 I 1.5 0.5 120 100 •o V in v Ol V) 50 100 150 200 Time since start of storm (minutes) 250 300 Inflow Release Set Point Overflow Storage Used Figure 26 Sim # 1290A 100 the available storage volume. It should be noted, however, that this storm is also very 'average' in the sense that the runoff characteristics tend to represent the mean pattern of all the simulated storms. For example, the peak flow of 2.77 m3/s is equal to the mean peak flow from all 42 storms. The length of the storm and the apparent rainfall distribution also seem to reflect average conditions. The good response to Storm # 1290, however, represents the exception rather than the rule. In most of the other simulations, one or a combination of two of the three following "problems" are evident in the fuzzy controller response: 1. Underutilization of the available storage, 2. Overutilization of the available storage, 3. Erratic response. Each of these problems are illustrated with examples in the following discussion. Underutilization of storage Sim # 9031A illustrates the problem of underutilization of the available storage. In the runoff hydrograph, shown in Figure 27, there is some overflow at the weir that is unnecessary. Since the storage facility was only 40% full at the end of the runoff event, a lower release rate could have been sustained without increasing the risk of overflow resulting from exhausted storage. Indeed, during the manual control simulation, the overflow was maintained below zero and the storage facility was only 60% full at the conclusion of the event. 101 2.5 1.5 s I 0.5 100 I I 50 100 150 200 250 Time since start of storm (minutes) 300 350 Inflow Release Set Point Overflow Storage Used Figure 27 Sim # 9031A 102 The reason for this overrelease can be deduced from the example database occurrence data presented in Table 6. For each set of fuzzy inputs, more than one output generally occurs within the example database. Since, in the resultant fuzzy rule base, the . weighted average of the outputs was applied to each input combination, there will be situations where another response is more appropriate. For example, for the inputs t is MID, Qin is MOD, and AQin is ZERO, the output in the fuzzy rule base is R is S O F because the 100 occurrences of this response in the example database dominate. However, for this same set of inputs, there were also 73 occurrences of R is Z_OF, 29 occurrences of R is M_OF, 13 occurrences of R is LOF , and 5 occurrences of R is VL_OF. Essentially, this wide variation in outputs means that a release of R is S_OF will be appropriate for only 45 % of the occurrences of the given set of inputs. In the case of Sim # 9031 A, the rules in the fuzzy algorithm that conclude on R is S O F or M O F tend to "pull" the release rate above the optimal fuzzy value of Z_OF. As a result, the flow at the weir hovers just above the overflow threshold, rather than just below as it should. Overutilization of storage Given the problems with underutilization, it may seem appropriate to adjust the fuzzy rules downward to try to capture more of the flow. However, doing so would only exacerbate the problem of overutilization of the storage. The more critical control situation is where all storage is exhausted before the runoff subsides. As already noted, this frequently results in highly undesirable conditions. To reduce the release rate any 103 further only increases the risk of such occurrences. Sim # 4407A is the most problematic of the simulations where overutilization occurs. The hydrograph, shown in Figure 28, is characterized by a low to moderate early peak at the 140 minute mark followed by a high peak about 80 minutes later. In terms of the control strategy objectives, the fuzzy controller fails completely. The controller is unable to respond to the latter peak flow resulting in an overflow of 2.44 m3/s at the weir. As in the case of underutilization, the problem of overutilization can be attributed to the fact that the outputs to the fuzzy rules were determined based upon a weighted average of the distributed outputs in the example database. Therefore, the outputs of the fuzzy algorithm are only effective for the storms that have "average" characteristics. However, the temporal distribution of rainfall and the subsequent runoff from Storm # 4407 are very unique amongst the 42 example storms. As such, the control action required to best handle these conditions cannot be achieved by a controller that is designed to respond best to "average" runoff conditions. Therefore, during the initial stages of the runoff leading up to the first peak, the controller sets a relatively low release rate corresponding to a singular low to moderate peak. Since it is "unaware" that a greater peak is yet to come, the controller cannot respond by increasing the release rate high enough to accommodate the later flows. So by the time the later peak arrives, too much of the previous flow has already been diverted to the storage tank. Consequently, there is no longer sufficient capacity to capture the late peak. 104 4.5 3.5 (A n E u. 2.5 1.5 0.5 250 200 150 •D a> (A a> o> re o 100 50 100 150 200 250 Time since start of storm (minutes) 300 350 Inflow Release Set Point Overflow Storage Used Figure 28 Sim # 4407A 105 It appears, then, that the weight averaging approach used to resolve rule conflicts has biased the controller in such a way that it's response approaches optimality only when the runoff follows "average" flow patterns. As a result, the fuzzy controller response is unacceptably sub-optimal for most storms because the majority of the events tend to deviate considerably from the "average" runoff pattern. It is the "non-average" events, however, that are the most critical, and therefore, they are the ones to which the controller must be able to effectively respond. There is little value in a controller that is unable to deal with a variety of possible flow conditions. Erratic response It is desirable that the flow changes induced by the controller should be smooth and gradual, free from significant fluctuation and erratic behaviour. The reason for this is twofold. Firstly, in a real control situation, if the controller output fluctuates widely the frequent adjustments that are required to achieve the controller-specified set points would result in excessive wear upon the mechanical components of the regulator gate. Secondly, and more relevant to this study, the greater the fluctuations in the release rate, the higher will be the peak flows issuing from the regulator. A smooth response, however, has not been achieved by the fuzzy controller employed here. To a greater or lesser extent all fuzzy control simulations displayed some fluctuation in the release rates. In the more severe cases, the release rate has been highly variable, resulting in peak flows that are considerably larger than necessary. This type of behaviour is illustrated by the fuzzy control simulation for Storm # 106 1779. It can be seen from the resultant hydrograph shown in Figure 29 that the controller specifies a release rate that fluctuates over a range of 0.9 m3/s during the diversion period. The peak overflow resulting from fuzzy control is 0.96 m3/s which compares with a peak overflow of just 0.47 m3/s under manual control conditions. In addition to the problem of erratic controller response, the simulation for Storm # 1779 is also characterized by overutilization. After the tank fills completely, there is another sudden peak in the overflow, though not quite as large as the peak fluctuation. Nevertheless, it's obvious that the controller is grossly inadequate to deal with even a relatively simple runoff situation as this. A close examination of the runoff characteristics for Sim # 1779A suggests that the primary reason for the wild fluctuations in the release rate is that the fuzzy algorithm yields outputs that are discontinuous on the universe of discourse of R. That is, the rules that are adjacent to one another on the fuzzy input space do not always yield a continuous fuzzy output. Of particular interest in this example are the outputs for cells 25 and 26 (t is MID, QJJJ is HIGH and AQin is NEG or ZERO) and cells 28 and 29 (t is MID and Qinis VHIGH and AQin is NEG or ZERO) in Table 7. For example, when the flow conditions move from the fuzzy input space described by cell 25 to the space described by cell 28, the fuzzy output shifts from R is M_OF to R is VL_OF. It can be seen from Figure 25(h), however, that there is a gap between these fuzzy sets on the universe of release rates. Consequently, the response of the controller to a shift in flow conditions in this direction is a significant jump from a lower to a higher set point. Similarly, a movement in the opposite direction produces a jump from a higher to a lower set point. 107 160 3.5 2.5 V) n~ E ~ 2 5 o 1.5 0.5 0 0 Inflow 50 100 150 200 Time since start of storm (minutes) 250 Release Set Point Overflow 300 Storage Used Figure 29 Sim # 1779A 108 In fact, wherever there is discontinuity on the output universe, abrupt changes in set points can be expected whenever the flow transitions from one input space to another. 7.1.2 Discussion of results In view of the inadequacies noted in the previous section, some discussion of the reasons for the poor performance of the fuzzy controller must be undertaken. In this respect, there are several observations that should be noted. First of all, with respect to the discontinuities in the fuzzy output space that caused the erratic response problems, it may have been possible to tune and refine the rule base in order to improve the performance. The division of the input and output spaces into fuzzy regions was performed quite arbitrarily, so it is likely that a more stable response may have been achieved by progressively refining and manipulating individual fuzzy sets and rules. This was not pursued, however, because it was apparent that such work would only provide marginal improvement to the controller. Tuning the rule base may have reduced some of the extreme fluctuations, but the more fundamental problems encountered during the testing of the controller, those associated with the inability of the controller to respond to a wide variety of storm conditions, would not be resolved. Secondly, on reflection upon the results of this set of tests, it is evident that the methodology employed here was fundamentally flawed. That flaw lies in the development of the example database from which the fuzzy algorithm was derived. Specifically, it lies with the method used to determine the optimal release rate for each storm that made up that database. As described earlier, the optimal release rate was 109 determined by hindsight, by selecting a constant value for the variable R that would result in the tank being nearly full at the conclusion of the runoff event. Having determined that value, the database simulation was run in such a way that the release was maintained at that value regardless of the state of the runoff process. In other words, the selection of the release rate at any point in time had nothing to do with the magnitude of the flow, the time since the start of the storm, the amount of storage remaining in the tank or any other measurable variable reflecting the state of the process. The release rate was strictly predetermined and was not based upon any on-line analysis of the process state whatsoever. As a result, the release rates specified in the example database are merely incidental to the values of the input variables. There is no direct correlation between the values of any combination of inputs and the value of the output. The only relationship between them is somewhat informal. For example, a high release rate is generally associated with a high inflow. This relationship is reflected in the rules, but it is an informal, rather than a causative relationship. When the fuzzy algorithm developed from this example database is applied to a control situation, however, it responds as if there were a rigorous relationship between the inputs and the output. That is, the controller responds as though it is the state of the process variables that define what the optimal release rate ought to be. It's operational procedure therefore differs considerably from the procedure used to define the rule base in the first place. As a result, the actions specified by the fuzzy controller on-line do not necessarily represent the best response to the given process state. In fact, the control actions may deviate significantly from the best response, resulting in the problems of overutilization and underutilization discussed earlier. 110 The objective in designing a fuzzy controller is to capture the "intelligence" used by a human operator to control the process. This "intelligence" consists of the procedural control knowledge and expert protocols that have been developed from experience interacting with the process. Jamshidi (1992) suggests that this "intelligence" must be developed and well-defined before it can be represented in a fuzzy rule base. The range of conditions that can be expected, the effects of a particular control action, and the governing control objectives must be well understood before they can be implemented in fuzzy form. Assuming that the human understanding is sufficient, the controller should then mimic that knowledge as closely as possible both in terms of the linguistic variables employed and in terms of the fuzzy relations between those variables. So, in effect, the fuzzy controller not only yields similar results as a human expert would, but it's reasoning process should also approximate the human process. Provided that the human understanding of the control process is adequate, the degree to which the fuzzy controller reasoning process imitates the human reasoning process is the degree to which the controller is effective. The strategy employed in this study, however, violates this principle of effective controller design. In the development of the example database, the method used to determine the appropriate release rate was devoid of any "on-line intelligence". That is, the hindsighting method did not determine the appropriate release rate on-line based upon an evaluation of the process state. Instead, as discussed earlier, the release rate was predetermined by successive repetitions of the simulation. There was no reasoning performed on-line during the manual control simulation to select the best set point. As a result, the set of data that formed the example database lacked internal consistency and 111 embedded "intelligence". Having established the example database, the FAMB method was then used to convert the data into a fuzzy rule base. The rule base, however, did not, and indeed, could not, imitate the reasoning process used by the human operator since the control set points had to be selected on-line. Instead, rather than mimicking a human operator, the controller reasoning process was little more than a pattern-matching algorithm. That is, the release rate was selected based upon the shape of the inflow hydrograph at any point in time. The input variables of t, Qin, and AQin, are analogous to the horizontal position, the magnitude and the slope of the curve respectively. These "geometric" parameters were then used to select the most commonly occurring release rate for the given condition in the example database. Consequently, the averaging effect noted above tended to dominate the controller response, with the result that most simulations were inadequately managed. 112 7.2 Control strategy development: Method B Given that the first method was fundamentally flawed, there was no reason to pursue it any further. However, the failures encountered using that method did provide some knowledge of the viability of fuzzy techniques and in what situations they can be used. It is apparent that the "black box" type of approach used in Method A is unsatisfactory for developing an effective controller. Instead, the fuzzy rule base must have imbedded within it some degree of "intelligence" in the form of expert procedural knowledge. To this end, it was clear that any new method of devising a control strategy had to be more reflective of the response of an on-line human operator. The greatest uncertainty associated with the strategy for capturing peak flows is the unknown future inflows. Yet, for the controller to be effective, some mechanism must be provided to "anticipate" those flows. In Method A that mechanism was hidden, expressed in the control actions contained in the example database. Since, during the manually-controlled storm simulations there was no uncertainty about future inflows, it was believed that the recorded control data should implicitly contain the procedures necessary to accommodate the future inflows. However, as discussed extensively above, that method was largely ineffective, resulting in controller responses that were grossly suboptimal. Therefore, it was felt that any new method for developing a control strategy must use a more explicit mechanism to deal with the future inflows. As a result, in Method B a module was included in the model that was capable of providing a real-time prediction of inflows over the runoff horizon based upon the measured rainfall intensities in the catchment. 113 Although adding a predictive capacity to the model improves the quality of information available to the controller (whether human or automatic), it nevertheless also increases the complexity of the control problem. Now, not only must the existing values of the state parameters be evaluated in selecting the output, but the predicted values must also be considered. As a result, it becomes even more difficult to reduce the input space to a dimensionality low enough to be understood by a human operator and translated into a fuzzy algorithm. These constraints governed the use of Method B to create a workable control strategy. 7.2.1 Runoff prediction It is possible at any time, t, given on-line measurements of rainfall intensity, to estimate future inflows over a predictive horizon approximately equal to the time of concentration, Tc, of a catchment. This is accomplished by routing the real-time values of rainfall intensities through a calibrated computer model of the catchment. However, the runoff estimate for time t + Tc must include the contribution from the rain that falls between time t and time t + Tc. This, of course, is impossible since, at the time the prediction is made, that rain hasn't fallen yet. To compensate for this lack of information a simple technique was adopted of extrapolating the rainfall pattern prior to time t into the period t + Tc. For the catchment under consideration, the time of concentration is equal to about 30 minutes or 6 time steps. This means that a flow estimate can be made 30 minutes in advance of the flood wave in this simulation. In order to account for the rainfall 114 contribution yet to come, the hyetograph was extrapolated 15 minutes or three time steps (i.e. Tc/2) into the future. This was accomplished by setting the rainfall intensities over the next three time steps equal to the average intensity over the last three time steps as shown in Figure 30. Having projected the rainfall pattern into the next few time steps, the resultant modified hyetograph was then routed using the Getrunoff module to yield a flow prediction for time t + Tc (see Section 4.5). To calculate the predicted runoff the module used the same catchment parameters that were used to generate the actual runoff. In effect, then, it was assumed that the predictive model was perfectly calibrated. Though unrealistic, this assumption was deemed reasonable because accuracy in the runoff prediction is less important than consistency. Even if the runoff prediction is biased toward lower flows, for example, so long as the prediction remains consistently low during the development and implementation of the fuzzy algorithm, then the controller should be effective. More than that, the magnitude of the error induced by imperfect calibration is likely to be significantly less than that caused by deviation in the projected rainfall from the actual rainfall. The Controller B simulations discussed in the following sections all include the predicted inflow curve on the hydrographs (i.e. Figures 31 and 34 to 39). Note that the actual flows lag the predicted flows by approximately 30 minutes. From these examples it can be seen that the model generally yields a reasonable estimate of future flows. However, there are still some defieciencies which will become evident later. 115 2.0 1.6 1.2 jo o o New inflow prediction using projected rainfall. 0.8 — O O O O O O O O O O l 0.4 0.0 20 Actual Inflow Projected rainfall for next three time steps equal to the average depth of rainfall in the pre-vious three steps. — 16 12 — 8 40 80 120 Time (minutes) 160 — T c — H 200 t+Tc Figure 30 Projection of rainfall intensities into period from time t to t + T 116 7.2.2 Control strategy development Considerable time and effort was expended in an attempt to develop a fuzzy rule base that would respond in a way that an experienced human operator might given a thirty minute flow prediction. The objective was to try to form a set of heuristically-derived control rules based upon on-line observance of process variables and the subsequent control actions. After a considerable effort to define such a set of rules, it became apparent that the number of variables necessary to characterize the flow conditions at any point in time was excessively large. In other words, the amount of information required to properly assess the flow conditions and to prescribe an appropriate control action was so complex that it was deemed impractical, if not impossible, to reduce it to a set of if-then rules having a small number of antecedents. For example, the information required at any point in time to select the next control action might include the present flow, the present rate of change in flow, the predicted flow, the predicted rate of change of flow and the available storage capacity in the tank. The task of integrating all of this information in heuristic form, that is, in a form that can be stated by a control operator, is daunting. It was clear from this observation, then, that alternate algorithmic methods were required to achieve the stated objectives. The method that was eventually adopted was a dual component controller. The controller was comprised of a crisp operating algorithm that is based upon the relationship between peak runoff and the optimal release rate and a fuzzy adjustment algorithm that modifies the output of the crisp algorithm based upon the process state. 117 These development of each of these components is dealt with in some detail in the following discussion. Crisp algorithm development Realizing that some simplification in the understanding of the control process was necessary, the runoff control dynamics were re-evaluated in a more general sense. Specifically, it was noted that there exists some general relationship between the magnitude of the peak runoff during a storm event and the optimal release set point required to fully and effectively capture the peak. Using the data from the 42 manually-controlled storms, the graph shown in Figure 31 was constructed showing the optimal release rate plotted against the peak runoff for each storm. As would be expected, the larger the peak runoff, the greater the release rate ought to be. This relationship, general as it is, nevertheless provides a good starting point from which to begin building a controller. The domain of peak runoff was divided into four regions and a straight line was fitted by eye through the points in each region. The equation of the line is given as follows: R = 0.833 Q ^ + 2.5, Qpeak > 4.6 mVs; R = 0.551405 Q ^ + 0.288929, 3.1 m3/s < Qpeak < 4.6 m3/s; R = 0.419177 Q ^ + 0.71871, 2.5 m3/s < Q ^ < 3.1 m3/s; R = 1.75, Qpeak < 2.5 m3/s; (7.3) 118 (O * V) CO _<D <D Ql 75 E O 1.0 2.0 3.0 4.0 Peak Flow, Qp (m3/s) 5.0 6.0 Figure 31 Peak runoff/optimal release relationship 119 where R is the output release rate and Qp eak is the peak flow. For reasons which will be discussed shortly, the line is plotted slightly higher than a regression-fitted line. A crisp algorithmic control strategy, based upon Equation 7.3, was then developed whereby the peak predicted runoff was used to calculate the appropriate release rate. Under this strategy, a prediction of the runoff thirty minutes hence is calculated at each time step. This prediction is then compared with the previously-predicted peak runoff and if the former exceeds the latter, a new release rate is calculated using equation 4.1. Otherwise, the release rate remains the same as previously assigned. This strategy is illustrated for the storm shown in Figure 32. In this example, the predicted runoff first peaks at 40 minutes. The release set point is therefore established at 2.26 m3/s beginning when the runoff first exceeds the release set point at a time of 50 minutes. The predicted runoff then declines until the 55 minute mark at which point it begins to increase again. At 60 minutes the predicted runoff is greater than the previously-predicted peak runoff recorded at the 40 minute mark. Consequently, the release rate is increased slightly. The predicted runoff continues to rise beyond that point and so, therefore, does the release rate. The predicted runoff peaks again at 70 minutes and steadily declines after that point. As a result, the final release rate of 2.59 m3/s is maintained until the flood wave recedes below the release set point. From this strategy, the reason for setting the line described by Equation 7.3 slightly high is apparent. That is, in the 42 manually-controlled simulations used to develop the peak flow/optimal release relationship, the release rate was set at a pre-determined level at the start of the event and then held constant throughout the duration of the runoff. If a regression-fitted line was used to determine Equation 7.3 then the 120 4.5 3.5 « 2.5 n E S £ 2 1.5 0.5 50 100 150 Time since start of storm (minutes) 200 250 Inflow Overflow Fuzzy Adjusted Set Point Predicted Flow Crisp Set Point Figure 32 Example control simulation showing effects of using predicted inflow and fuzzy adjustment 121 response to an on-line simulation using this relationship would generally result in overutilization of the available storage. This is because the release rate, using such a relationship, would gradually increase as the predicted runoff increases. Consequently, the release rate does not reach its "optimal" value until the peak flow has been predicted. That is, during the period before the peak flow is predicted (i.e. up to 30 minutes in advance of the actual event), the release rate will be lower than what is generally required to best control a storm of that magnitude. As a result, there will be a tendency for overutilization to occur, because the release rate during the early part of the runoff is lower than the "optimal" release corresponding to the peak inflow. This tendency is offset, however, by hedging the Equation 7.3 relationship upwards so that the higher output release rates compensate for the low response before the peak flow is predicted. Hence, by assigning higher set points throughout the control interval, greater capacity can be maintained in the storage facility. This method yields a rough approximation of the optimal release set point. However, as is apparent from the graph in Figure 31, there is considerable scatter in the data points, and consequently, the optimal release rate for a given storm may deviate significantly from the rate given by Equation 7.3. For many simulations Equation 7.3 tends to result in a response that is either too conservative (even after the effect of setting higher release rates, as discussed above, is considered), as is the case for simulations falling significantly below the curve in Figure 31, or too tolerant where the simulations fall above the curve. In the former case, excessive runoff is overflowed while capacity remains in the storage tank at the end of the storm. In the latter case, the tank fills completely before the flows have subsided and hence, flooding occurs. It was postulated, 122 therefore, that the response could be improved by adjusting on-line the release set point from that specified by Equation 7.3 based upon the values of the state variables at any given point in time. This adjustment or refinement of the release set point was achieved by the use of a fuzzy algorithm. Fuzzy adjustment algorithm Because the random storm generator uses a two year return IDF curve (Sec. 4.2) to construct all storms, the runoff hydrographs tend to follow certain patterns. For example, short duration storms are generally characterized by high intensity rainfall yielding a runoff hydrograph that rises quickly, peaks at a high flow, and then recedes quickly. On the other hand, the hydrograph for a long duration storm tends to rise slowly, waver back and forth within a range of relatively low peak flows, and then recede slowly at the end. A storm of moderate length will have a hydrograph that falls somewhere in between these two patterns. Examples of each of these patterns are given in Figure 33. Assuming that a crisp control algorithm like that expressed by Equation 7.3 is being used, it is possible for a human operator, during on-line observation, to make reasonable judgements about how much to adjust the release rate to bring it closer to optimal. As the storm progresses, the necessary adjustments can be approximated based upon the degree to which the actual (or the predicted) runoff hydrograph deviates from an average hydrograph (i.e. an hydrograph falling along the curve represented by Equation 7.1) having the same peak flow. For example, if the predicted peak runoff is high, and 123 n E 5 o EC Stoirm Duration - • Moderate ~° Short ~* Long IVi»' 11 ii 11111 11111 T¥rffl*»ttmiiimnm i 100 200 300 400 Time since start of storm (minutes) 500 Figure 33 Typical runoff patterns for short, medium and long duration storms 124 the predicted runoff is falling very rapidly and the tank is less than half full, then it is likely that the original release set point is too high. In this case, a better control response may be obtained by adjusting the release rate downward a little bit. Or, if the predicted peak runoff is moderately high and the predicted runoff is rising and the tank is over three quarters full, it usually means that the release rate should be adjusted upward considerably in order to avoid flooding. Using an heuristic approach such as this allows the operator to make adjustments on-line in response to the runoff pattern observed as the storm progresses. Naturally, this heuristic approach implies that the adjustment algorithm can be represented by a fuzzy rule base. Therefore, the domains of the three variables, predicted peak runoff, Qp Peak, change in predicted runoff, AQ , and the amount of storage already filled, Sf, were each divided into an appropriate number of fuzzy regions. These variables are illustrated in Figure 34. A fuzzy rule base was subsequently constructed which prescribed the appropriate adjustment, AR, for each combination of antecedent conditions. The fuzzy regions for the three input variables and for the one output variable are shown in Figure 34. A total of 60 rules were created to cover all possible combinations of inputs. The fuzzy mapping of the adjustment algorithm, developed from experience gained by the operator during on-line control simulations, is given in Table 9. The structure shown in the table illustrates the organization of information in the control algorithm. Firstly, the magnitude of the predicted peak runoff, Q Peak, is characterized as low (LOW), moderate (MOD), high (HIGH) or very high (VHIGH). When Qp_Peak is LOW, however, there is generally no need to adjust the set point since the optimal 125 a) 0.5 1 2 3 4 5 Peak Predicted Inflow, QpPeak (m*/s) -0.5 0 0.5 Change in Predicted Inflow, AQp (mVs) und_qtr und_hlf ovr hlf ovr_3qtr 20 40 60 Storage Used {%) 80 100 -0.16 -0.12 -0.08 -0.04 0 0.04 0.08 0.12 0.16 Release Adjust, R (m3/s) Figure 34 Fuzzy regions for adjustment algorithm 126 Table 9 Fuzzy mapping of adjustment algorithm Qp P e a k is MOD AQp NB NS ZERO PS PB Storage, Sf udr_qtr N3 N2 Nl ZO PI udrjilf N2 Nl ZO PI P2 ovr_hlf Nl ZO PI P2 P3 ovr_3qtr ZO PI P2 P3 P4 Qp Peak ^ HIGH AQp NB NS ZERO PS PB Storage, Sf udr_qtr N2 Nl ZO PI P2 udr_hlf Nl ZO PI P2 P3 ovr_hlf ZO PI P2 P3 P4 ovr_3qtr PI P2 P3 P4 P5 Qp Peak i s VH1GH AQp NB NS ZERO PS PB Storage, Sf udr_qtr Nl ZO PI P2 P3 udr_hlf ZO PI P2 P3 P4 ovr_hlf PI P2 P3 P4 P5 ovr_3qtr P2 P3 P4 P5 P6 127 release rate will almost always fall below the overflow threshold for a runoff of this magnitude. Therefore, any possible rules having antecedent Q_ Peak is LOW are omitted from the adjustment algorithm. However, corresponding to each of the three latter characterizations is a fuzzy subalgorithm2 that evaluates the set point adjustment based upon the relative fullness of the storage tank and the rate of change in the predicted runoff. These subalgorithms assess the degree to which the state variables, Sf and AQp, deviate from the "average" runoff pattern for an event having a magnitude of Q Peak and then calculate how much the release rate should be adjusted based upon the magnitude of those deviations. For the purposes of this discussion, the "average" runoff pattern is roughly described as the approximate values of the state variables that commonly occur concurrently. More concretely, the "average" runoff pattern is reflected in the set of fuzzy rules that conclude on "AR is ZO" (see Table 9). For example, during a runoff event having a moderate predicted peak flow, the "average" runoff pattern is characterized by a slowly decreasing predicted runoff when the tank is over half full (Rule 7). If, on the other hand, the predicted flow is increasing slightly when the tank is over half full, the release rate should be increased somewhat aggressively to compensate for higher than "average" flows (Rule 15, AR is P2). Likewise, if, in a runoff event having a high predicted peak flow, the predicted flow is decreasing rapidly while the tank is less than one quarter full, then the release rate should be decreased somewhat aggressively in order to capture more of the runoff. 2 The characterization of the predicted peak flow as MOD, HIGH or VHIGH, is, of course, merely descriptive from a structural point of view. The adjustment algorithm is simply a set of 60 fuzzy rules each having three antecedents. Naturally, since the boundaries between these sets are fuzzified, the output response will incorporate the contribution from each relevant subalgorithm. 128 During on-line, automatic control, the fuzzy adjustment algorithm is invoked only when the predicted flow is less than the predicted peak flow. That is, if, at any given time step, the predicted flow is greater than all previously-predicted flows, then the crisp control algorithm overrides the adjustment algorithm and the release rate is determined by Equation 7.3. Therefore, referring once again to the runoff simulation shown in Figure 32, the use of the fuzzy adjustment algorithm can be seen. After the predicted runoff peaks for the first time at the 40 minute mark, the crisp algorithm produces a set point of approximately 2.25 m3/s which is held constant up to the 55 minute mark. However, at that point the predicted runoff is also decreasing. Consequently, the fuzzy adjustment algorithm edges the release rate down slightly because the information available at that time suggests that the peak inflow may have already been predicted, and that the present release rate is too high for a storm of that magnitude. If the predicted flow continued to decline at this point, the fuzzy algorithm would have progressively reduced the set point in order to capture more of the potential overflow. However, at the 60 minute mark, the predicted inflow jumps to a value that exceeds the previous maximum predicted inflow (i.e. the peak recorded at the 40 minute mark). As a result, the crisp algorithm overrides the fuzzy algorithm, thus setting successively higher release rates until the predicted inflow peaks once again at the 70 minute mark. Beyond that point the predicted inflow does not rise again and therefore, the fuzzy algorithm controls the output throughout the remainder of the simulation. Over the next 30 minutes the release rate is decreased mildly because the measured state inputs and the output are very close to the "normal" pattern for an event of this magnitude. That is, based upon the "intelligence" embedded within the fuzzy algorithm, the release rate is already close to optimal given the values of 129 the state variables Qp, Qp Peak, and Sf during this period and so there is no need for radical changes in the set point. After the 100 minute mark, the fuzzy adjustment algorithm begins to increase the release rate again in response to the decreasing storage availability in the tank. This continues until the end of the runoff event, where it rises slightly above the crisp set point before the inflow falls below the release set point at 135 minutes. The overall effect of the fuzzy adjustment algorithm on this simulation, then, is to reduce the release rate slightly below the crisp output, thereby making better utilization of the available storage. At the conclusion of the event, the tank was 89% full, which is somewhat better than the result of using only the crisp algorithm. However, this represents only one simulation, and the effects of using this new controller must be evaluated on the basis of many more. 7.2.3 Results As in the case of the Method A controller, the fuzzy rule base developed using Method B was tested with the 42 example storms so that its effectiveness could be compared most directly with the results of both the manual control simulations and the Method A simulations. The results of the Method B simulations are presented in Table 10, shown alongside the results of the manual control simulations and the Method A controller simulations. Upon initial review, a modest improvement, measured in terms of reduction in peak flow, over the results produced by the Method A controller was observed from the Method B controller. The difference in the peak outflow, Qw, averaged a 10% increase 130 V) C O « - C N C O > - C O « - ' - C N < - . - T - C N « - C M O O ' - C O O O O O ' - C N < -<u < = E o « I 2 (J *-^ ^ ^ j£ O CM W l*» # r # # # LO ,fr 0 0 ™ CO ™ CD " . SP ^ ^ s? ^ ae •* O •* °> O "* op cri in 9 CM d e^ o o 3"* CN CO # <N CO -8 co Ol s^ o o s^ o •tf GO c_> ° o ) r v - O 00 r - C O c O ^ J O r - ^ o o CO <*>£ o | 2 c 3 ^p >p NP »«P NP VP VP O >SP **p NP >p ^p vP %p o^ o ^ O *^ 0 ^ C^ CT* C^ " 0 ^ O^ C *^ ^ " 0^" O^ O^ O *^ jP eP ^ ;P N < D < N O 0 0 0 0 r 0 0 ) ^ N < - t 0 N l O N f . < - l 0 l , N 0 ) ( M N n N N C M N N t S N i - ' J i - N N ^ M n BS SP- ge j?. ss o ^i ^ o CO w i— £ co £ o CM r» co t - o i*> «-; CM Tj; o •*: o *-; i n t f ) U 5 a ) i o t ^ c D i D ' ^ 0 ' " O O O c M O c o m O O O O o o o o o O o o c   9 d d 9 d d CM i n co i- . C N a i ' t O ' ^ - O O O c M **. o * c> <5 cS CM o ' CO co -a CD CO ^ p •-» - J CO oo in <* o CD O) 00 in co oo P~ CM o «- oo o O r-CO O) > t M i - N N CD CO T - ^ r^ i ^ ^ <j> oo ^ p^ co ? c f tS S . S o # # CT* CT* *J? cr* Cr* CT* Cr* Cr* CT* # * cP * cP cP eP i n cP cP cN £f* i 8 J^? co Q. 3~-NP NP >p -VP -SP >p *p NP vP "*P NP O ^ O^" O ^ O^* Cf* O ^ O^" 0^* CT* Cv" CV" 0 5 C O O t > » 0 0 C M a ) C M « - C 0 C M T - C M C O C M t - C M « - C N C 0 « - r -<^ ;£ ^ ^ ^ «+ °' m rvi <-> LD CO CO BP * CO t -CM CM in ? O V) § E o OT^j- r « « c o « - r - . i n c o r > > c o o o « - c n co oo co • ^ • p ^ c o ' O c n i - ^ O l i - f f l N ' - N ' - i - i - f f l ' - ' - ' i - O N m ^ r - M ^ M ^ o o i n o o o o o o o o o o o o o o o o o 9 o CO CO T3 o JS * r-! i*-o oo o o CO L. O N 00 •«t JI •* f«. 00 _,. CO M f 0 O N CO o clS ^•s <sP vP -sP Np vP gS gS QS o^ * o^ * r - CO <N r^ vP vp sP sp -sP NP NP VP VP NP S P _. vP •sS' «sS» N0 xP \P A ^^ os o^ o^ o^ o^ o* w^  o^ o^ <y^  "-v o^ o^ o** o^ o** 0s* sP £ i n p r - O r - ^ ^ co oo 0) r^  o CN C O C O O O C O C M C O C N C M C O C M C M o o •* in co co CO CO # # JP ^ in O T-  «-co »* oo co co ^  o CO co co k_ O o o g CO CO a. 5 i O n CO «b_ z ^ a. « £ o r ^ ^ o ) c o r ^ r > . r r r ; r ^ c 5 S f 2 c o o i " t r ' 5 2 , t c " ' - S ' - S 5 S ' ^ " c N p o c N P ' < ! t P 9 o P P P c n o O c M 9 » - i ^ » - P r - p c o o 0 9 0 0 9 0 9 9 6 9 9 9 0 6 0 0 9 0 0 ^ 9 0 9 9 0 CO co co o 2 V) O O O N O ) O O l f l O ) < t O ) ' -o > a ) O ) c n r ^ c n r » < T ) a > ^ j - c 0 r - c n c N a ) o > N N 00 CO en cn en r~ en CM a. -S2 5 ° . E to m N <- 00 O) co co in 00 ** •* r» co co r>- CN in rv r» «- t «cr »-i n co o o * - o « - o o « - o o o o o co -'. o CM o o o c o c o o o c n ' < * « - c O ' t f t P , t f > o > - ; ' * " * r > . c n c N « o o d ' - ' c N C M d d d 9 d 11 00 en N to <o 10 to 05 CO l»» CM CN i n ' t co r* CN in r^  in at CN CM en CM CN CN CO CN CO CN CN r^  CN CM CN CN m 0 CO CN CN •* 05 •>* CN CN CN in CO CN *^ CO CD O CO i n _ o o c o o o o o o 5 ^ i -' t ^ O O O O O C n C N C N initNcNcri>-:cN<*'<t «- CD •* "* tn 1^ 0 •* CM CM CN «- CN E o =»* O «- O CO >* CT) •* o in a> o co r« 00 o o CN ** co t*» o t- ^ ^ t- r- CN O i n c N r » a ) < - c o r - ~ 0 0 0 0 « - C N C O C N C O O I ^ O C N C N C N C O C O ^ -co 00 in co o r^ •* »- r^ CN «- co in CD r^  in in in in in 131 ^ N n n n M co CN co CJ CO < CD II ( J — CO § cj . -* c co ^ n- # ££ o # * # <£ # 01 M °i o n Tt o # sP- ^ # aR CM O CO CO CM • * » - « -O ^ O ^ ^ ^ O ^ O ^ O ^ O ^ O ^ ^ J P O ^ O ^ O ^ C R S N J P . CD GO "O o .2 * CO g +-» c o O O 5 .* o 03 »- r-o i n CO o ,-9 d c o o o t o ^ j - 15 £ »- o CM co * 0 9 ° d d c ) 6 9 9 o 6 o c i to CO CO CM # # # o to co eR cR -JP "- m o CN •* ° O ^ o CD oo <» o o lO CM Tt (O 00 t o o o j i ~ c D 0 > r - . o o c D ^ CD o o O) N CO CN N in oo in r» CD ^ ^p cR &•* s~ &- # C O C O O O ! : C O ' * * - < - O S £ C D C O O O O ' -« - C M » - C M C N C M C N C M v - ' ~ o j co co t_> «— ' - ' «- CM i - CO CM c o u 15 D C TO 2 CO CS XJ fO CO ^p +-» - J CO # CM i n M C I M O O M J C O O l l O - , C O C M ^ t - C O C M ^ C n C M f v j O ^ ^ C M " " * CO CO 2 ? o o o CO o o o o o ,_; 9 o o o in CM d »-• o - o 2 S « " > £ - c o " o •* oo CO •<4- oo CO oo CD o *P *sP >P "sP >P vp *»P NP **p ^ p _ -»P NP S P vp >P %P ON ON ff* o^ o^ CN o* ff* o^ o^ ;J? ON ON ON O^ O^ ON c \ i i f > w o > w o o o r « . o o O T 2 ; w o a > « - ' f r o C N C O C M C M C O C N C O C O C N C N ^ - ' c N C O C N ^ ' C O C O 2 CM CO CO •<* O O « - CM « -CO T3 0> ^c 5 ° v. -52 '11 p d d d d d p d d CO CM CM _.. ^ ^ CO O ^ J - O T O O Q O °dd do tr r~ CM p ,- *t d d # c£ 00 o CM in 0") CD CO IS O) O) 00 05 CO CO CO CD CD CD 00 Ci 05 CD o rv Tt co CD in CD in CD CD 00 CD TJ- CD d d 00 i*» i-» r«. •* O <- CO N CO *-IV CO q m i-« oo CM CM r» CD «- co »-*dd'-d'-:9dd £ co 00 CD CN |v csi CN r ~ r » r » ' t , _ c O T - c o ( v o o coa)<pir) uiiDr-r«.ooio CM rvi /^i *^i /^i CO fvj pn ^- rvj rvl CM i n CM CN CM CM CN CO « - CN CN O CD CO CM ^ • T - C O C O O O O C O C N C M i n O « - « - O C D C O C D C D ' - C D C O I ^ C O C D O ' t C O C N C O O C M C M C D C D C O T t ' ^ C D O ' - C O O C O I v O O O C N C O f v C D O ) c o c o c o c o r ~ i ~ . r ~ o o o o c o o o c D e D C D C D a > o > II 132 over manual control compared to an average increase of 13% for the first method. Similarly, when the cases are discounted where peak flows occur after the tank fills, the peak flow increase averages 7% versus 10% previously. Viewed in other terms, the total reduction in peak flow obtained by the second method averaged 21% (min. 0%, max. 43%) versus 19% for the first method and 28% for the manual control method. So, in general, the results seemed somewhat favourable, but a better understanding of the effectiveness of the method requires a more intensive examination of the simulations on an individual basis. The results of the Controller B simulations are best assessed by dividing them into three different classes that reflect both the storm runoff characteristics and the response to each simulation effected by the different control strategies. The classes are as follows: • Class 1 All potential overflow (at the weir) can be captured without filling the tank completely. • Class 2 The tank capacity is not sufficient to capture all potential overflow, but the tank is not overfilled at the conclusion of the simulation using Controller A. • Class 3 The tank capacity is not sufficient to capture all potential overflow and the tank is overfilled at the conclusion of the simulation using Controller A. A Class 1 response is primarily identified as one having an overflow value of 0 m3/s for the manually-controlled simulations. A Class 2 response is one that has a non-zero 133 overflow value for the manual control simulation but the tank fullness is less than or equal to 100% for the Controller A simulations. A Class 3 response has a non-zero overflow value and the tank fullness is greater than 100%. A Class 1 simulation is characterized by the property that the total volume of inflow in excess of the overflow threshold is less than the storage capacity of the tank. In such cases, the inflow peaks are naturally low, though the storm duration may be extended. In the manual control simulations, the release rate could be maintained below the overflow threshold throughout the duration of the simulation without any adverse effects. However, using Controller A, the release rates tended to fluctuate just above the overflow threshold, thus resulting in overflows at the weir. This was one of the undesirable results of the Method A simulations that it was hoped could be improved by using Method B. As is evident from the data in Table 10, Controller B has been largely successful in achieving a better control of Class 1-type flows. In fact, there is an overall average decrease in the peak value of Qw of 6.2% over the controller A results. Of the 19 simulations that fit the Class 1 designation, only in two did the peak value of Qw increase, and that was by a maximum of 1% (i.e. Sim # 9201B and Sim # 9729B). In the remainder, the new controller yielded lower peak flows, reducing them by as much as 12% (Sim # 9320B) over the Controller A result. The reduction in peak flows in Class 1 simulations can primarily be attributed to the stability of the sequence of outputs derived from the crisp control algorithm employed by Controller B. The relationship described by Equation 7.3, from which the crisp algorithm was formed, specifies that for all predicted peak flows below 2.5 m3/s the 134 release rate is set below the overflow threshold at a value of 1.75 m3/s. Moreover, in terms of the fuzzy algorithmic response, the value of Qp Peak is LOW throughout the duration of the event, so the set points specified by the crisp algorithm are not altered. An example of a representative Class 1 simulation is Sim # 5515B shown in Figure 35. Here, the predicted peak flow doesn't rise above 2.2 m3/s, and, as a result, the release rate is maintained at 1.75 m3/s for the entire duration of the simulation3. This is in contrast to the Controller A simulation where the release rate fluctuates considerably through a range that exceeds the overflow threshold. There are associated with the structure of the second controller certain tendencies observed in some Class 1 simulations and in a large number of Class 2 simulations. Specifically, the release hydrograph produced by the controller is often characterized by a "dip" where the fuzzy algorithm initially decreases the set point from the crisp algorithm output, and then increases it again, often back above the crisp set point, before the conclusion of the runoff event. Often as the adjustment algorithm increases the set point through the latter part of the "dip" the release rate is driven back above the peak value recorded for the same storm in the Controller A simulations. In fact, it is primarily due to this effect that the average peak value of Qw using Controller B is more than 3% greater than for Controller A among Class 2 simulations. Nevertheless, this response, as it shall become evident through the discussion of several example simulations, cannot be avoided given the incompleteness of the information available to the controller. Among Class 1 simulations, there are a few that displayed the "dip" pattern. One of A floor of 1.75 m3/s has been set so that the fuzzy adjustment algorithm cannot reduce the set point below that value. 135 2.5 100 1.5 5 o 0.5 100 200 300 400 Time since start of storm (minutes) 500 Inflow Overflow Fuzzy Adjusted Set Point Predicted Inflow Crisp Set Point Storage Used Figure 35 Sim # 5515B - Class 1 response 136 these is Sim # 2227B, shown in Figure 36. From the simulation hydrograph, it can be seen that the fuzzy algorithm adjusts the release rate first downward slightly, and then, after the 155 minute mark, it adjusts it back up again to a level that is 0.14 m3/s greater than the overflow threshold. While this is a slight improvement over the results of Controller A, it still represents an 18% unused portion of the storage tank. Presumably, through better management of the flows, the controller could have captured more of the overflow. There are two factors that cause the increase in the set point during the latter stages of an event. The first is that, as the tank fills up, the controller compensates by reducing the amount of flow being diverted to storage. From Table 9, it can be seen that as the tank fills, the release adjustment becomes more and more positive. So, for example, when the tank is over three quarters full, the fuzzy algorithm will always yield a zero or a positive increment in the release rate, even when it can be reasonably deduced that the current release rate is sufficiently high to prevent overfilling. The second factor is that the controller responds rather aggressively to late peaks encountered in the predicted inflow. After the major peak has been predicted and passed and the crisp controller establishes a final set point, the fuzzy algorithm is then designed to respond to sudden increases in inflow that occur late in the event. As the stored volume increases, the controller more and more sensitive to positive ir zero rates of change in the predicted inflow, increasing the release rate so as to avoid overfilling the tank. Both of these factors are operative in causing the release rate to climb near the event in Sim # 2227B. It can be seen that the increases in the set point occur concurrently with several short, but sudden, spurts in the predicted inflow, with the 137 50 100 150 200 250 Time since start of storm (minutes) 300 350 Inflow Fuzzy Adjusted Set Point Crisp Set Point Overflow Predicted Inflow Storage Used Figure 36 Sim # 2227B - Class 1 response 138 increases becoming more pronounced as the tank fills. As the tank passes the three quarter full point, even a zero change in the predicted inflow causes an increase in the set point. Obviously, for this particular simulation such a response is unnecessary since enough storage was available to retain the additional flow. However, as it shall been seen, a less aggressive response can have more drastic consequences in other simulations. This "dipping' behaviour is even more pronounced among the Class 2 simulations. In many of these cases, the peak Qw also occurs near the end of the event as a result of positive increases in the release rate due to tank filling. One of the more dramatic of these is Sim # 7070B, shown in Figure 37. In this example the Qw curve displays a well-pronounced dip. This dip consists of an incremental decrease in the release rate from the crisp set point beginning at the 60 minute mark that flattens out at the 110 minute mark and then begins to increase again until it intersects the receding inflow curve. The initial decrease occurs because that controller, being "unaware" of the flows beyond the predictive horizon, responds as though all peaks in the inflow have already been predicted and that the inflow can subsequently be expected to recede at a steady rate. At 110 minute the tank is about 60% full and filling steadily. In response, the fuzzy algorithm reverses the decreasing trend and begins adjusting the set point upward to prevent overfilling. At 130 minutes, the rate of increase becomes quite strong because the inflow prediction indicates that another surge in inflow is coming and, therefore, some storage must be preserved. Through the remainder of the runoff event, the controller continues to increase the set point until the inflow recedes below the release rate. By this time, the tank is 95 % full, which is a near-ideal result. In this case, if the controller had 139 3.5 2.5 _ 2 V) g o 1.5 N I r I / r" "  " ^ \ ••. i | i i i I I i i 140 0.5 0 120 100 80 60 5^ • o w V) 3 9) Ol CO w o C/> I f / I 7 ^ -/ \ - A -! 40 20 50 100 150 200 Time since start of storm (minutes) 250 300 Inflow Overflow Fuzzy Adjusted Set Point Predicted Inflow Crisp Set i Point ! Storage • Used Figure 37 Sim # 7070B - Class 2 response 140 responded less aggressively toward the end of the event, the tank would certainly have overfilled. Among Class 3 simulations, the effectiveness of Controller B is mixed. Overall, there is a 1.7% average decrease in the magnitude of peak flows over Controller A results, but among individual simulations that value ranges from a 12.5% decrease to a 13.2% increase. Several points can be advanced to explain these results. First of all, the number of simulations where overutilization occurs has decreased from 14 to 54. Associated with this reduction is a decrease in the frequency of peak flows occurring subsequent to early filling of the tank. However, among the simulations in which overfilling occurs using Controller A but not using Controller B, the average decrease in the peak flow was only about 2.6%. This indicates that although the new strategy was able to respond more effectively to prevent overutilization of storage, it nevertheless had to adjust the release rates so that they were near or even greater than the peak flows experienced using Controller A. So the improvement achieved by reducing the frequency of overutilization tends to mask a less substantial improvement in the ability of the controller to reduce peak flows. Secondly, in many of the cases where Controller B was able to prevent overfilling, the amount of storage used is relatively low (eg. 85%, 79%, 82%, and 86% for Sim #'s 1779B, 4227B, 4338B, and 8002B respectively). The reasons for this response vary somewhat from one simulation to another but there are a few commonalities that can be forwarded to explain this behaviour. For example, in Sim # 4 Among Controller B results, there are 6 simulations in which the storage used exceeds 100%. However, one of these is a Class 2 simulation (Sim ft 5348) in which overfilling occurred using Controller B but not Controller A. Therefore, it is not included in this discussion. 141 4227B (Figure 38), where the tank is only 79% filled, the primary reason underutilization occurs is because the peak predicted inflow was significantly greater than what actually occurred. Consequently, the crisp set point was initially specified too high for the fuzzy adjustment algorithm to bring it down enough. Moreover, the occurrence of the latter local peaks in the predicted inflow further when a more appropriate response may have been to leave it the same or even to decrease it. What is evident here is the inability of the controller to "ignore" the minor perturbations in the predicted inflow when it is more effective to do so. Rather, when they are encountered, the controller responds by increasing the set point since it is "unaware" that such an action is unnecessary. In general, the reason for low storage utilization (and hence higher release rates) among the Class 3 simulations primarily (and in other classes generally) is that the controller automatically responds by increasing the set point near the end of the event when a much less aggressive action is required. Thirdly, the fact that there are Class 3 simulations where overfilling was experienced using Controller B suggest that, in these cases, the controller was still not able to respond aggressively. Sim # 6496B, shown in Figure 39, illustrates that in some situations the controller doesn't increase the set point fast enough to prevent overfilling. The storm in this simulation is only low to moderate in magnitude, but its duration is abnormally long, and as a result, the controller fails to prevent the excess diversion. The problem is particularly acute in the simulations where the storm runoff peaks late. Once again the example of Storm # 4407 is relevant. Referring to the Controller B response shown in Figure 40, as in the case of the Controller A response, the large peak in the runoff that comes late in the event completely overwhelms the facilities. By the 142 140 120 100 80 £ •o V </> Z> 0) o> ra 60 o to 40 20 0 50 100 150 200 Time since start of storm (minutes) Inflow Overflow Fuzzy Adjusted Set Point Predicted Inflow 250 Crisp Set Point Storage Used 300 38 Sim # 4227B - Class 3 response 143 120 100 80 s^  •o v en 60 => (0 c/3 40 20 0 50 100 150 200 Time since start of storm (minutes) 250 300 Inflow Overflow Fuzzy Adjusted Set Point Predicted Inflow Crisp Set Point Storage Used 39 Sim # 6496B - Class 3 response 144 140 n £ o 50 100 150 200 250 Time since start of storm (minutes) 300 350 Figure 40 Sim # 4407B - Class 3 response 145 time that these peaks are predicted, too much of the storage capacity has been used and the controller can't respond fast enough to capture them. In fact, the tank reaches fullness just before the peak inflow arrives, so there is no reduction in peak flow magnitude at all. 7.2.4 Discussion of results In general, Controller B produced a moderate improvement over the Controller A results. The improvement was not so much in terms of an overall decrease in the magnitude of the peak flows issuing from the regulator site, though the second method did yield an overall 2% reduction in peak flows, but more in terms of the "intelligent" response of the controller to changing conditions. As observed previously, there was no real "intelligence" embedded within the rule base of the first controller; rather, it was a linguistic abstraction from a set of data that was obtained through rote mathematical methods. The second controller, on the other hand, was designed to mimic the actions that a human controller might employ during on-line control of the process. The end product did appear to respond in a more human-like fashion, but there were several shortcomings in the results. Problems associated with Controller B After reviewing the Controller B results, there were three main areas that proved problematic. They were: 146 a) Uncertainty about future inflows, b) Incomplete understanding of the control process, and c) Insufficient information available to the controller. Although there are other lesser problems that could be suggested, these seem to be the most prominent. Any significant improvements in the controller response would have to be made in one or more of these three areas. The nature of these problems and the extent to which they may be improved is discussed next. Uncertainty about future inflows Although the implementation of a predictive mechanism within the model yielded obvious improvements to the control process, there nevertheless remained considerable uncertainty with respect to future inflows. Firstly, even with the assumption of a perfectly-calibrated rainfall-runoff transformation model, there was still, in many cases, considerable predictive inaccuracy associated with the simulations. As discussed above, the primary reason for underutilization of storage in Sim # 4227B was that the peak flow prediction was significantly higher than what was realized. Other examples could be shown, though they are not discussed individually here, where the inflow predictions deviate from the realized conditions with the result that the control process is less effective than desired. However, given that the prediction mechanism already assumes perfect calibration using on-line rainfall measurements, there is little or no potential for improvement. Secondly, the greatest uncertainty is with regard to the future inflows that lie 147 beyond the predictive horizon, which, in this case is approximately equal to the time of concentration of the catchment. In more than one simulation, the greatest flows occur late in the event (Storm # 4407 is one example). However, during the early stages of the event these peaks generally lie well beyond the predictive horizon and so the controller responds by specifying low set points. As a result, too much of the storage capacity is used up early, and by the time the late peaks are predicted there is insufficient capacity to capture them. Of course, this problem can only be remedied by developing a predictive mechanism that is able to extend its forecasts beyond the time of concentration, presumably using radar methods or something similar. However, this issue lies beyond the scope of this study. It is mentioned at this point only to emphasize that many of the inadequacies observed in the simulation results can be attributed to the uncertainty regarding future states. As such, when assessing the viability of fuzzy reasoning for controlling flows, the problems related to incomplete knowledge of future inflows must be differentiated from the results of using the fuzzy algorithm in this strategy. Lack of understanding of the control process During the course of this study, considerable time was spent interacting manually with the model and reviewing the results of the completed simulations in order to obtain a better understanding of how to respond to different state conditions. However, the task of compiling all available, on-line information and synthesizing it to determine an appropriate output set point was very difficult. Even after the completion of many hours of interaction and study, the understanding of the control process remains incomplete. It 148 is desirable that the level of understanding should be such that, for any given state of the control process, a single "best" response should be determinable by the human controller. However, such levels were not attained during the development process. In fact, it could probably be argued that such a comprehensive understanding is unattainable and that there can be no "best" response. This incomplete comprehension of the control problem has obvious implications for the controller developed from it. The degree to which the human understanding of the process is lacking is the degree to which the controller will be ineffective in accomplishing the stated goals. The use of fuzzy methods to represent the control strategy does not mysteriously compensate for incomplete human knowledge. Rather, the lack of knowledge will tend to be amplified in the controller due to imperfections in translating the heuristics into fuzzy rules. Therefore, the human knowledge will always tend to form the upper limit of effectiveness in terms of the development of fuzzy controllers. Insufficient information available to the controller At any one point in time, it may be necessary to reference several variables to ascertain the state of the process and to make the appropriate control decision. However, to simplify the decision process sufficiently that it can be stated in algorithmic form requires that the most important process variables can be referenced by the algorithm. As a result, the controller may lack the information required to respond most effectively at different times in the control process. 149 Controller B references a total of four state variables to determine the proper output. The crisp algorithm uses the value of the predicted inflow, Qp, and the fuzzy algorithm uses the predicted inflow Qp Peak, the incremental change in the predicted inflow, AQ_, and the amount of storage used, Sf. However, after reviewing the results of the Controller B simulations, it was apparent that at least one, and perhaps two more variables are necessary to ascertain the best response. Specifically, the tendency of the fuzzy algorithm to increase the set point near the end of the event in response to late peaks and decreasing storage availability needs to be addressed. As discussed in the presentation of the results of Controller B, there were times when the fuzzy algorithm responded appropriately (eg. Sim # 7070B), times when it should have been less aggressive (eg. Sim # 2227B), and times when it should have been more aggressive (eg. Sim # 4407B). However, based upon the information available to the controller, it is not possible to ascertain which response is required. Some additional piece of information is required to differentiate between runoff patterns and to prescribe more appropriate actions. It seems that what is missing from the set point determination algorithm is an indication of the volume of inflow yet to come. As the available storage volume decreases, the controller responds by increasing the set point so as to reduce the amount of flow being diverted. However, it does so without "knowing" how much additional flow to expect relative to the available storage. For example, as the tank storage rises above three quarters full, it may be that the volume of flow in excess of the present release rate can be completely captured without causing overfilling. In such a case it may be better to maintain the release rate as it is or even to decrease it rather than to 150 increase it as the present controller would. Similarly, the prediction of the volume yet to come may indicate that the release rate should be increased drastically in order to avoid overfilling. The present controller is unable to respond in such a manner. Without going into a discussion of the details of how to do so, it is conceivable that a separate module could be added to the controller capable of estimating the volume of diverted flow yet to come given a particular control strategy. Such a module may be able to reduce this information into a single variable that can be included within the fuzzy adjustment algorithm. Doing so, however, would increase the number of inputs to the fuzzy algorithm to four, and would increase the number of rules by a factor equal to the number of fuzzy regions defined for that variable. For example, assuming that the universe of X has been defined for inclusion in the fuzzy rule base, and that the universe of X has been divided into five fuzzy regions, then the number of rules in the fuzzy adjustment algorithm would be multiplied from the present total of 60 rules to a total of 300 rules. It should be noted that very little tuning of the fuzzy algorithm has been attempted in this study. To do so, having a rule base of 60 rules, is a formidable task. Tuning would have to be performed using trial and error methods, making slight modifications to the rules or to individual fuzzy sets, followed by testing of the modified algorithm by a large number of simulations, and then making further changes. This is an involved and time intensive process that is only of marginal value to this study. For this reason it has not been pursued rigorously. If a fuzzy rule base were being developed for application in a real system, however, tuning is a necessary process. And if the fuzzy rule base was being defined 151 with the four inputs discussed here, then it would be necessary to tune a set of 300 rules. This is a daunting, if not impossible task assuming trial and error methods are employed. More than that, the complexities of real systems are such that additional inputs may be required, and the input variables may be divided into a greater number of fuzzy regions. Consequently, it may not be unreasonable that a fuzzy algorithm with rules numbering in the thousands may be required. Assuming, though, that such a large rule base could be developed and tuned, its very existence seems antithetical to the purpose of adopting fuzzy methods. The reasoning process in a rule base like that is inherently complex beyond the understanding of an individual operator. Though it may be theoretically possible to develop such a system, that amount of effort required to accomplish the task outweighs the merits of moving to fuzzy methods in the first place. Evaluation of fuzzy techniques for peak flow capture When assessing the overall effectiveness of fuzzy techniques with regard to the peak capture problem several comments are in order. First of all, laying aside the problems of insufficient information available to the controller, the fuzzy adjustment algorithm seemed quite effective in modifying the set point based upon what information was available to it. While recognizing that there is considerable room for improvement, the fuzzy adjustment algorithm was able, in most cases, to bring the controller response closer to optimal than with the crisp algorithm. In cases where the crisp set point was too high, the fuzzy algorithm responded by reducing the set point and thereby it was able 152 to capture more of the inflow. Similarly, the adjustment algorithm also increased the set point in response to a filling tank or to sudden surges in the predicted inflow. In this way, it tended to mimic a human intuitive response to the problem, responding in a stable manner to the sometimes unstable changes in the process. Secondly, since the storm generation module only uses one IDF curve with a two year recurrence interval to generate the rainfall hyetographs, the runoff hydrograph patterns, described in terms of the relationship between the magnitude of the flows and the duration of the storm, are relatively consistent. In a sense, these patterns are implicitly embedded in the controller because the crisp algorithm determines the output set point based upon the peak inflow/optimal release relationship described by Equation 7.3 - a relationship that was created from only two year storm simulations. However, even though the generated storms have a relatively constant recurrence magnitude, the controller was frequently unable to handle the more extreme storms, especially those with late peaks. This is significant in terms of the transferability of these techniques to a broader control situation with a wider variation in flow conditions. Specifically, if a storm with a less frequent occurrence interval is encountered, the controller would likely be quite ineffective because it will continue to respond as it would to a two year event. Undoubtedly, the result of such situations will be highly inadequate. Thirdly, the computing time is very reasonable. The simulations were performed on a PC-AT 386-33 Mhz computer system with a math coprocessor. During simulations an average of five time steps were executed per second. For each time step, both the inflow prediction is made and the set point is issued by the controller. Therefore the time of execution of the fuzzy algorithm is negligible in comparison to the 5 minute time 153 step being used in the simulation. By applying fuzzy techniques to real systems, then, a fairly broad network of control sites could conceivably be managed from a centralized control station. In summary, though there are some obvious benefits to be derived from their use, fuzzy techniques were inadequate to reasonably manage the peak flow reduction problem due to the inherent complexities. Fuzzy programming is a valid method for managing the imprecision and ambiguity in real systems but it does not possess any mysterious ability to deal with missing or incomplete information. The development of a fuzzy controller capable of dealing with the complexities of the peak capture problem would necessarily have to be so large and complex that it may not be worth pursuing in the first place. 154 8.0 Conclusions and Recommendations The pupose of this study was to assess the suitability of fuzzy algorithmic techniques or fuzzy controllers for real-time, on-line control of flows in a combined sewer system. The study focussed on two different control scenarios, devised to test the applicability of fuzzy control strategies to meet differing control objectives. The first, a two catchment system, was devised to test the ability of a fuzzy controller to capture the first flush from a storm runoff event. The second was comprised of a single catchment system in which the control objective was to use a storage facility to capture the peak flows during a runoff event. The folowing discussion outlines some of the important conclusions that can be drawn from this work. 8.1 Fuzzy techniques: strengths and limitations In general, the use of fuzzy methods was found to be quite effective in handling the first-flush capture scenario, but less so with the peak capture scenario. The reasons for this discrepancy, as it turns out, are quite instructive in terms of assessing the suitability of fuzzy techniques for CSO control, the situations in which they may be applied with some effectiveness, and the limitations of the techniques in a given situation. The strength of a fuzzy controller is its ability to imitate the reasoning process used by a human operator to make control decisions. Essentially, the development of a fuzzy controller entails the transformation of human procedural knowledge and expert protocols into fuzzy constructs that can be implemented in a form that mimics the human 155 reasoning model. It follows, then, that the overall effectiveness of the controller depends upon the integrity of the human procedural knowledge and how well that knowledge can be converted into fuzzy form. It was found, during the course of this study, that the difficulties encountered in developing fuzzy controllers pertained primarily to the incompleteness of the human procedural understanding of the process rather than to shortcomings in the fuzzy techniques themselves. For example, the control procedure for managing flows in the first flush capture scenario was well understood, and by translating the heuristic knowledge of the operator into the linguistic form of a fuzzy rule base, a relatively effective control strategy resulted. The control procedures were simple enough that they could be easily implemented in a two input-one output model and then tuned through an uncomplicated trial and error process. Contrarily, the peak flow capture scenario was highly complex. In that case, it was determined that a minimum of four variables were required to describe the process state sufficiently that a reasonable output could be specified. And even given four inputs, there would still likely be occurrences of control failure because, given the stochastic nature of rainfall events, uncertainty will always be a real element of the control and management problem. Fuzzy logic and fuzzy inferencing cannot overcome the deficiencies associated with uncertainty unless they can be overcome in terms of the human understanding of the problem first of all. That is, the effectiveness of a fuzzy controller will not, and in fact, cannot, exceed the effectiveness of a human controller because the fuzzy algorithm is nothing more than a linguistic translation of the human heuristic model1. Of course, through the process of developing a fuzzy controller, the human understanding of the process may increase, leading to better final results. 156 The most fundamental issue affecting the suitability of fuzzy techniques to a control problem is dimensionality. Where the dimensionality is low enough that the control strategy can be stated linguistically using simple but comprehensive reasoning, then application should be possible. Generally, however, this limits the number of inputs to two, or at most, three. Beyond this, the complexity of the problem increases exponentially, leading to formidable challenges in terms of defining the control rules and then tuning them for optimal performance. In such cases, other methods need to be sought. 8.2 Applicability of fuzzy techniques to real systems From the results of this study there appears to be sufficient evidence to warrant further development work into the application of fuzzy techniques for real systems. The good results obtained for the first flush capture strategy indicate that for CSO control fuzzy methods should produce satisfactory to good results. Generally, the control objective in CSO management is to prevent flows from exceeding certain predetermined water levels at specific sites for as long as possible. This objective should, in most cases, be achievable using a maximum of two inputs to a fuzzy rule base. At a given level site, only the magnitude of the deviation from the maximum water level and the rate of change in the measured levels are necessary to determine a control action. Provided that the objective is simply to capture initial flows, ignoring any exceedences of the maximum flow levels which may occur subsequent to the exhaustion of the available storage, then the use of fuzzy control should be pursued. 157 The use of fuzzy techniques for automatic control is not likely going to be highly successful in situations where the dimensionality of the input space is more than two or three, or especially where methods of handling uncertainty are unresolved. As evidenced by the results of the peak capture control strategies, there are considerable difficulties, usually accompanied by a relatively high probability of failure, involved in properly managing situations where such conditions hold. Consequently, in such cases, it would be more appropriate to provide off-line, advisory fuzzy systems, if fuzzy techniques can be applied at all. For example, in the case of flood control system, a fuzzy expert system may be developed that would advise a human operator on the value of a set point, but that value may be accepted or rejected by the operator. This allows the human operator to modify the output subject to his/her experience in interacting with the process, especially in extreme circumstances when the runoff patterns deviate considerably from the norm. 8.3 Recommendations for future study Given the varied results obtained in this study, future work into the applications of fuzzy logic control of CSO or flood flows should be along several paths. It is clear that in some areas, a more direct application to real systems should be pursued while in other areas further development work on the theoretical side is required. Some comments regarding these assertions follow. Firstly, where the control objectives relate more to pollution mitigation than to peak flow reduction, the use of fuzzy technologies should be pursued with a view toward 158 hastening their transfer to actual implementations. As such, any future work should be directed toward testing these techniques on a model of a broader, more complex CSS network that is comprised of multiple subcatchments, interceptors, regulators, etc. Preferably such a model should represent an actual CSS so that the constraints and complexities of real systems can be incorporated into the control problem. Furthermore, rather than using randomly-generated or otherwise artificial storms, historical rainfall records should be used as test data, thus reproducing truer and more varied runoff responses. Since many North American and European cities are presently faced with the development of real time control systems for their combined sewer systems, the use of fuzzy methods should be studied and promoted somewhat vigorously. Secondly, where flood control or peak flow reduction is the primary control objective (i.e. as opposed to pollution mitigation) the viability of fuzzy techniques for automatic control is marginal. In general, the complexities of the peak reduction problem are great and the task of constructing a simple fuzzy control algorithm that will be effective in all circumstances is difficult. Nevertheless, based upon the fundamental conclusions of this study that, if a control algorithm can be stated in linguistic form by a skilled human operator then it should be possible to translate that knowledge into a fuzzy rulebase, there is left open the door of possibility for attaining a workable controller. In other words, perhaps through a more concentrated effort to synthesize an heuristic understanding of the process, possibly by incorporating methods for longer range inflow forecasting, a better human control response may be attainable. This then, should facilitate the development of a fuzzy system that will be effective in automatic control situations, though the development of such a system would be quite intensive. 159 One further possibility is to pursue the application of alternative artificial intelligence techniques, specifically neural networks, to the peak reduction problem. The main limitation of using fuzzy inferencing for this problem is that the dimensionality of the input space is so great that it cannot be easily translated into a manageable fuzzy algorithm. Neural network techniques, on the other hand, have considerably fewer dimensionality limitations. They can be implemented to accept any number of inputs, and "trained" to produce the desired ouptuts through the use of example data. The application of these methods, however, is predicated upon the development of a more complete human understanding of the process. The example data used to train the network must be complete in so far as it reflects the best response known to the developer. In other words, just as with the use of fuzzy methods, the output of a neural network will only be as good as the information used to build it. 160 Bibliography 1. Abramowitz, M. and Stegun, LA. (1965), Handbook of Mathematical Functions, Dover Publications, New York. 2. Bardossy, A. and Disse, M. (1993). Fuzzy rule-based models for infiltration, Water Resources Research, Vol. 29, No. 2, 373-382. 3. Berenji, H.R. (1992) Fuzzy logic controllers. In: Yager, R.R. and Zadeh, L.A. (Eds.), An Introduction to Fuzzy Logic Applications in Intelligent Systems, Kluwer Academic Publishers, Boston, 69-96. 4. Bernard, LA. (1988). Use of rule-based system for process control, IEEE Control Systems Magazine, October 1988, 3-13. 5. Beron, P., Briere, F., Rouselle, L and Riley, LP. (1985). An evaluation of some real-time techniques for controlling combined sewer overflows. In: Options for reaching water quality goals: proceedings of a symposium held in Washington, D.C. at the Twentieth Annual Conference of the American Water Resources Association, Schad, T.M. (Ed.), Bethesda, Md. 139-145. 6. Braae, M. and Rutherford, D.A. (1979). Theoretical and linguistic aspects of the fuzzy logic controller, Automatica, Vol. 15, 553-577. 7. Chow, V.T, Maidment, L., and Mays (1988), Applied Hydrology, McGraw-Hill, 1988. 8. Combined Sewer Overflow Pollution Abatement - Manual of Practice No. FD-17, Prepared by Task Force of CSO Pollution Abatement, Jeffrey D. Sharon, Chairman, Water Pollution Control Federation, 1989 9. de Oliviera Galv^o, C. and Ikebuchi, S. (1992). Rule-based reservoir operation considering long range forecast, Bull. Disas. Prev. Inst., Kyoto Univ. Vol. 42, Part 3, No. 368, 71-94. 10. de Silva, C.W. (1991). An analytical framework for knowledge-based tuning of servo controllers, Engng. Applic. Artif. Intell. Vol. 4, No. 2, 1-13. 11. Freedman, P.L and Marr, J.K. (1990). Receiving water impacts. In: Control and Treatment of Combined Sewer Overflows, P.E. Moffa (Ed.). Van Nostrand Reinhold, New York, 79-118. 12. Harris, C.A. (1984). Fuzzy logic potential control technique in mineral processing, M.A.Sc. thesis, Queen's University, Kingston Ont. 161 13. Harris, C.A. and Meech, J.A. (1987). Fuzzy logic: a potential control technique for mineral processing, CIM Bulletin, September 1987, 51-59. 14. Honda, K., Yamada, F., Kobayashi, S., Oku, M., and Kunimi, M. (1990). On-line expert system for sewage pump control with fuzzy inference. In: Briggs, R. (Ed.). IAWPRC, Instrumentation, Control and Automation of Water and Wastewater Treatment and Transport Systems, Pergamon Press, 251-258. 15. Hou, S. and Ricker, N.L. (1992). Minimization of combined sewer overflows using fuzzy logic control, 1992 IEEE Internat. Confer, on Fuzzy Systems. March 8-12, 1992, San Diego California. 16. Jamshidi, M. (1992). Lecture notes from the 2nd B.C. Workshop on Intelligent Control and Applications, Burnaby, B.C., July 13-15, 1992. 17. Khelil, A. and Schneider, S. (1991). Development of a control strategy to reduce combined sewerage overflows: the case of the Bremen - left of the Weser, Wat. Sci. Tech. Vol 24, No. 6, 201-208. 18. King, P.J. and Mamdani, E.H. (1977). The application of fuzzy control systems to industrial processes, Automatica, Vol. 13, 235-242. 19. Kojiri, T., Panu, U.S. and Unny, T.E. (1990). Expert reservoir operation including preliminary control, The Hydrological Basis for Water Resources Management (Proceedings of the Beijing Symposium, October, 1990). IAHS Publ. no. 197, 1990, 327-334. 20. Kollatsch, D. and Biinzel, J. (1991). Detention of sanitary sewage as a method to reduce combined sewer overflow pollution loads, Wat. Sci. Tech. Vol. 24 No. 6, 217-224. 21. Leiser, C.P. (1974), Computer Management of a Combined Sewer System, Metropolitan Seattle, WA, ,USEPA-670/2-74-022 (NTIS PB 235 717). 22. Linsley, R.K. and Kohler, M.A. and Paulhus, J.L.H. (1982). Hydrology for Engineers, 3rd Ed., McGraw-Hill, New York. 23. Malinowski, K. (1988). Overview of important issues in operational flood control. In: Coulbeck, B. and Orr, C. (Eds.). Computer Applications in Water Supply, Volume 2 - Systems Optimization and Control, Research Studies Press Ltd., Letch worth, Herts. England, 110-145. 24. Mamdani, E.H and Assilian, S. (1975). An experiment in linguistic synthesis with a fuzzy logic controller, Int. J. Man-Machine Studies, Vol 7, 1-13. 162 25. Moffa, P.E. (Ed.) (1990). Control and Treatment of Combined Sewer Overflows, Van Nostrand Reinhold, New York. 26. Neugebauer, K., Schilling, W. and Weiss, J. (1991). A network algorithm for the optimum operation of urban drainage systems. Wat. Sci. Tech. Vol. 24, No. 6, 209-216. 27. Russell, S.O., Kenning, B.F.I, and Sunnell, G.J. (1979). Estimating design flows for urban drainage, Journal of the Hydraulics Division, Proc. of the A.S.C.E, Vol. 105, No. HYI, 43-52. 28. Schilling, W. (Ed.) (1989). Real-time control of urban drainage systems - the state of the art, by IAWPRC Task group on real-time control of drainage systems. 29. Smith, A.A. (1990). MIDUSS Version 4.70 User Manual, Alan A. Smith Inc., Dundas Ont. Canada. 30. Sripada, N.R., Fisher, D.G. and Morris, A.J. (1988). AI application for process control regulation and servo control. In: Pham, D.T. (Ed.). Expert Systems in Engineering, IFS Ltd., Kempston, Bedford, UK, 78-98. 31. Taunton, J.C. and Haspel, D.W. (1988). The application of expert system techniques in on-line process control. In: Pham, D.T. (Ed.). Expert Systems in Engineering, IFS Ltd., Kempston, Bedford, UK, 99-111. 32. Terano, T., Asai, K. and Sugeno, M. (1992). Fuzzy Systems Theory and Its Applications (english edition), Academic Press, Harcourt Brace Jovanovich, Publishers, USA. 33. Tong, R.M., Beck, M.B. and Latten, A. (1980). Fuzzy Control of the Activated Sludge Treatment Process, Automatica, Pergamon Press, IF AC , Great Britain, Vol. 16, 695-701. 34. Vitasovic, Z., Swarner, R. and Speer, E. (1990). Real-time control system for CSO reduction. Water environment and technology/Water Pollution Control Federation, Vol. 2, No. 3, 58-65. 35. Wang, L. and Mendel, J.M. (1991). Generating fuzzy rules by learning from examples, Proceedings of the 1991 IEEE International Symposium on Intelligent Control, 13-15 August 1991, Arlington, Virginia, U.S.A. 263-268. 36. Watt E.D. (Ed.) (1989). Hydrology of Floods in Canada - A Guide to Planning and Design, National Research Council. 163 37. Zadeh, L.A. (1984). Making computers think like people, IEEE Spectrum, August, 1984, 26-32. 38. Zadeh, L.A. (1992). The calculus of fuzzy if/then rules, AI Expert, March 1992, 23-27. 164 Appendix A: Source Code for the Computer Model #include <stdio.h> ^include <stdlib.h> #include <math.h> #include <conio.h> #include < float. h> #include <ctype.h> #include < alloc.h> include "flolib.h" #include "tilcomp.h" #include "divert.h" / ^ * ^ v ^ # ^ * ^ ^ T ¥ v ' K ' i ' V V ' l { ' l ' 3 K 5 l { ' p TH111"\f*f 10T1 T^1"Of Of A/TV*^ ^vv^^v^'K9K'fC'f*3K'F'ics('3fc'K'K'l*si<'fc't<'fc3(c/ HYDROGRAPHJTYPE Generate_runoff(CATCH_TYPE catchment_data, stormtype storm); CATCH_TYPE get_catch_data(char *catch_file); HYDROGRAPH_TYPE make_TA_UH(CATCH_TYPE catch_data); HYDROGRAPH_TYPE route(HYDROGRAPH_TYPE inflow, float K, float x, float initin); storm_type get_storm(void); HYDROGRAPH_TYPE get_runoff(HYDROGRAPH_TYPE unit_hydro, stormjype storm, CATCH_TYPE catch_data); char *get_num(FILE *pnt, char strl[8]); void flow_control(HYDROGRAPH_TYPE metered_flow, HYDROGRAPH_TYPE flow2, stormtype serstorm); void print2screen(int i, float inflow, float release, float volume, float p_filled, float interflow, float intensity, float overflow, float diversion); storm_type get_serial(storm_type first_storm); void lag_storms(storm_type *storml, storm_type *storm2); void lag(storm_type *storm, int lagsteps); void print2file(FILE *fp, int i, float inflow, float release, float int_flow, float overflow, double deltaD); / *i* *i* *p *i* *i* *i* i* *fs *i* *i* i* ^ * •(* *t* *i* *i* i* f* i* *!* t* *i* *i* *t* t n f*k i f^ ^^  ^ ^ ^ ^ ^^  ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^^  ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ / int main(int argc, char* argvQ) { HYDROGRAPHJTYPE runoff 1, runoff2; storm_type storm 1, serial_storm; CATCH_TYPE catchmentl, catchment2; 165 i f (argc!=3){ printf("usage: floctrl catch_filel, catch_file2\n"); exit(l); } catchmentl = get_catch_data(argv[l]); catchment2 = get_catch_data(argv[2]); storm 1 = get_storm(); serialstorm = getserial(storml); lag_storms(&storm 1, &serial_storm); print_storm(storml, storml.num_steps, "storml.stm"); print_storm(serial_storm, serial_storm.num_steps, "serial.stm"); runoff 1 = Generate_runoff(catchmentl, storm 1); runoff2 = Generate_runoff(catchment2, serial_storm); runoff2 = route(runoff2, 0.3, 0.1, catchment2.B); print_hydro(runoff 1, max_response, "runoffLout"); print_hydro(runoff2, max_response, "runoff2.out"); flow_control(runoff 1, runoff2, serial_storm); return (0); } /* The get_storm function prompts the user whether to import a storm or to generate a storm. If the user chooses to import a storm it prompts for the file name. The function returns an object of type storm_type. */ stormjype get_storm(void) { FILE *fp; // pointer to storm file int i; // counting variable char str[8], // input string from storm file storm_file[13], // name of imported storm file action; // User specifies imported storm or random storm storm_type new_storm; // storm object containing hyetograph // Prompt for imported or randomly generated storm do { printf("(I)mport Storm or Generate (R)andom Storm?\n"); action = toupper(getch()); } while((action != 'I') & (action != 'R')); if (action = = 'R') new_storm.init(); // Generate random hyetograph 166 else { // Retrieve import storm printf("Enter storm file name: "); scanf(" % s\n", storm_file); if((fp=fopen(storm_file, "r")) = =NULL) { printf("Storm file not found on disk.\n"); exit(l); } i=0; // initialize to element 0 while (!feof(fp)) { fgets(str, 8, fp); if (ferror(fp)) { printf ("error reading file.\n"); exit(l); } newstorm. hyetograph [i + + ] = atof(str); } fclose(fp); } return new_storm; } /* The function getserialO generates a storm that is serially correlated with firststorm to simulate changes in storm appearance over time. */ storm_type get_serial(storm_type first_storm) { stormtype next_storm; int i; // initialize nextstorm. hyetograph to zero for(i = 0; i < max_storm; i++) next_storm.hyetograph[i] = 0.0; // calculate random variation during each time step for(i = 0; i < first_storm.num_steps; i++) { next_storm.hyetograph[i] = normal(first_storm.hyetograph[i], 0.2 * firststorm. hyetograph [i]); } next_storm.num_steps = first_storm.num_steps; next_storm.dt = first_storm.dt; return next_storm; } 167 /* The function lag_storms() receives the initial and the serially correlated storm and generates a random time lag between them in order to simulate the movement of a storm across two catchments. */ void lag_storms(storm_type *storml, storm_type *storm2) { float time_lag; // time lag between storms int lagsteps; // the number of steps to lag in hyetograph timelag = normal(0.1666667, 0.1); // mean = 10 min, stdev = 6 min lag_steps = (time_lag/time_step + 0.5); // round lag_steps if(rand() % 3) lag(storm2, lagsteps); // 2/3 of time storml goes first else lag(storml, lag_steps); // 1/3 of time storm2 goes first } /* the function lagO pushes the hyetograph back by lag_steps steps and inserts zeros at the start of the storm. */ void lag(storm_type *storm, int lagsteps) { int i; // counting integer /* shift hyetograph elements back lag_steps */ for(i = (storm->num_steps + lag_steps - 1); i > = lag_steps; i—) storm- > hyetographfi] = storm-> hyetograph[i - lag_steps]; /* insert zeros at beginning of hyetograph */ for(i = 0; i < lag_steps; i + + ) storm-> hyetograph[i] = 0.0; storm- > num_steps + = lag_steps; // update num_steps } /sjesfeslcsjesjofesjesjesjcsfcsjcsjesiojcaicsjesjiisfesje T f l l f " | £ H 1 7 f * I^J l t " f *nTT l fM" l t " ^^5IT*J i tT1f* t f *T"^ ^v^%3K 3 K 5 f l » ' ! e s i * ' i e 5 i ' s K' l * ' ! e ' i * ' ! e 'K 3 K/ CATCH_TYPE get_catch_data(char *catch_file) { char str[8]; FILE *fp; // pointer to catchment data file CATCH_TYPE catchment_data; // catchment data object // printf("Entered get_catch_data.\n"); 168 /* retrieves next value from the catchment file. */ if ((fp=fopen(catch_file, "r")) = =NULL) { printf("Cannot open catchment fileAn"); exit(l); } // Retrieve paramters from catchment file catchment_data.B = atof(get_num(fp, str)); catchment_data.Inf = atof(get_num(fp, str)); catchment_data.A = atof(get_num(fp, str)); catchment_data.w = atof(get_num(fp, str)); catchment_data.h = atof(get_num(fp, str)); catchment_data.K = atof(get_num(fp, str)); catchment_data.Tc = atof(get_num(fp, str)); catchment_data.x = atof(get_num(fp, str)); fclose(fp); // printf("Completed get_catch_data.\n"); return catchment_data; } /***********#****** Retrieve Catchment Parameters from file ***************/ char *get_num(FILE *pnt, char strl[8]) { fgets(strl, 8, pnt); if (ferror(pnt)) { printf("error reading file\n"); exit(l); } return strl; } /* The following module generates the runoff hydrograph as a result of */ /* storm and the parameters of the catchment given in catchment_data. */ /***********************************************************************/ HYDROGRAPH_TYPE Generate_runoff(CATCH_TYPE catchment_data, storm_type storm) { 169 HYDROGRAPHTYPE Time_Area_UH, // Unit hydrograph from Clark Time-// Area diagram, unithydro, // Unit hydrograph from catchment after // routing, runoff; // final response to storm // printf("Entered Generate_runoff.\n"); Time_Area_UH = make_TA_UH(catchment_data); unithydro = route(Time_Area_UH, catchment_data.K, catchmentdata.x, 0); print_hydro(unit_hydro, maxresponse, "unithyd.out"); runoff = get_runoff(unit_hydro, storm, catchmentdata); // printf(" Completed Generate_runoff.\n"); return runoff; } /************** 3ui|(j un[i hydrograph from Clark Time-Area curve *********/ HYDROGRAPHJTYPE make_TA_UH(CATCH_TYPE catch_data) { int i,j; // counting integers int N; // number of time steps to complete runoff generation float a, b, c, // runoff parameters x, // number of Tc's since start of storm Ac, // Area contributing runoff AcLast = 0.0, // stores old value of Ac dt = time_step; // time step HYDROGRAPHTYPE unitjiydro; // unit hydrograph // printffEntered make_TA_UH.\n"); // calculate runoff parameters a = 4*(l-catch_data.w); b = 6*catch_data.w-4*catch_data.h-4; c = 4*catch_data.h-2*catch_data.w+l; // initialize unit hydrograph to 0 for(i=0; i < max_response; i++) unithydro. graph [i] = 0; // calculate runoff using Clark Time-Area method j =catch_data.Tc/dt+1; 170 for( i=0;i<j; i++) { x = i*dt/catch_data.Tc; if (x < 1.0) Ac = a*pow(x,3)+b*pow(x,2)+c*x; else Ac = 1.0; if (i) unithydro. graph [i] = catch_data.A*(Ac-AcLast)/(360*dt); AcLast = Ac; } // printfC'Completed make_TA_UH.\n"); return unit_hydro; } HYDROGRAPH_TYPE route(HYDROGRAPH_TYPE inflow, float K, float x, float initin) { float cO, cl, c2, // Muskingum routing constants dt = time_step; // time step int i; // counting integer HYDROGRAPHTYPE outflow; // outflow from routing function // printf("Entered route.\n"); cO = -((K*x-0.5*dt)/(K-K*x+0.5*dt)); cl = ((K*x+0.5*dt)/(K-K*x+0.5*dt)); c2 = ((K-K*x-0.5*dt)/(K-K*x+0.5*dt)); // initialize outflow to initial inflow initin outflow. graph[0] = initin; for(i = 1; i < max_response; i++ ) outflow.graphfi] = cO * inflow.graph[i] + cl * inflow.graphfi - 1] \ + c2 * outflow.graphfi - 1]; // printfC'Completed routeAn"); return outflow; } /sksfcJiesksksfcsksksiokskskJkJksksjesksk p-ot f lT15| l n i T l f l f f f l " O m P J l t P n m f n l " ^^^f^-^^^^f-^fi^^^^fi^^^fi^^'^^^fi^f HYDROGRAPH_TYPE get_runoff(HYDROGRAPH_TYPE unit_hydro, stormtype storm, 171 CATCH_TYPE catch_data) { int i, // counting integer step; // step in runoff hydrograph float flow, // flow in each time step eff_rain[max_storm]; // effective rainfall (ie. rain - infiltration) HYDROGRAPHJTYPE runoffjiydro; // runoff_hydrograph // printf("Entered get_runoff.\n"); // calculate effective rainfall for(i = 0; i < max_storm; i + + ) { eff_rain[i] = (storm.hyetographfi] - catch_data.Inf) * storm.dt; if(eff_rain[i] < 0.0) eff_rain[i] = 0.0; } for(step = 0; step < maxjresponse; step++) { if (step < storm, numsteps) { flow = 0.0; for(i = 0; i < = step; i++) flow + = eff_rain[step - i] * unit_hydro.graph[i]; } else { flow = 0.0; for(i = 0; i < storm.num_steps; i++) flow + = effrain [storm, numsteps - i] * unit_hydro.graph[step - storm, numsteps + i]; } runoff_hydro.graph[step] = flow + catch_data.B; } // printf("Completed get_runoff'); return runoff_hydro; } void flow_control(HYDROGRAPH_TYPE metered_flow, HYDROGRAPHTYPE flow2, stormtype serstorm) { #define max_flow 3.6 int i j ; //counting integers 172 float inflow, // flow at gate (cms) last_flow = 0, // flow during the last time step (cms) released_flow = 0, // flow which is not captured at gate (cms) tankvolume = 20000, // total storage tank volume (cubic metres) volumenow = 0, // volume of water in storage tank at each // time step (cubic metres) dt = time_step, pfilled, // percentage of tank filled intensity, // intensity of rainfall in serial storm overflowvolume = 0; // volume of overflow double overflow = -3.6, // overflow discharged to receiving water deltaQ, // change in flow between time steps (cms) deltaD = 0, // change in diversion required diversion = 0; // percentage of flow diverted to storage FILE *fp; // pointer to output file BOOL Fuzzy = false; // Use fuzzy control if true char ch; long int wait_time; float get_diversion(void); // prompt user for manual or fuzzy control printf("Manual or Fuzzy Control? (M/F)\nu); do { if((ch = toupper(getche())) = = 'F') Fuzzy = true; } while((ch != 'F') && (ch != 'M')); clrscrO; // open output file if(!(fp=fopen("control.out", "w"))) { printf("Cannot open file control.out."); exit(l); } // begin control algorithm lastflow = meteredflow. graph [0]; for (i = 0; i < max_response; i++ ) { inflow = metered_flow. graph [i]; 173 deltaQ = inflow - last_flow; // control decision is fuzzy logic if (Fuzzy) { Diversion(overflow, deltaQ, &deltaD); diversion + = deltaD/100; // check if diversion is less than 0.0 diversion = diversion < 0 ? 0.0: diversion; // check if diversion is greater than 1.0 diversion = diversion > 1.0 ? 1.0: diversion; waitjime = 100000; } // control decision is manual else { if (kbhit()) diversion = get_diversion(); waitjime = 1000; } released_flow = (1.0 - diversion) * inflow; overflow = releasedJlow + flow2. graph [i] - max_flow; // Check for reservoir overflow if ((pfilled = (volume_now/tank_volume)*100) > 100.0) { overflow + = inflow - released_flow; // discharge overflow for(j = 0; j < 5; j + +) printf("%c", 0x07); // sound alarm gotoxy(15, 7); printfC'WARNING! RESERVOIR OVERFLOW"); } // Check for reservoir near full else if (p_filled > 90.0) { printf("%c", 0x07); gotoxy(15,7); printfC'WARNING! RESERVOIR NEAR FULL"); 174 } // get overflow volume if(overflow > 0) overflow_volume + = overflow * dt * 3600; /* makes sure that print2screen() receives only O's if i exceeds the value of max_storm. */ if(i > max_storm) intensity = 0.0; else intensity = ser_storm.hyetograph[i]; print2screen(i, inflow, released_flow, volume_now, pfilled, flow2.graph[i], intensity, overflow, diversion); print2file(fp, i, inflow, released_flow, flow2.graph[i], overflow, diversion); volumenow + = inflow * diversion * 3600 * dt; last_flow = inflow; pause(wait_time); } fclose(fp); gotoxy(5,ll); printf("Total overflow volume: %.2f", overflow_volume); } /* print2screen prints out the flow control variables to the screen. */ void print2screen(int i, float inflow, float release, float volume, float p_filled, float inter_flow, float intensity, float overflow, float diversion) { static int heading = 0; // print table heading if (! (heading)) { printf(" i Time\t j \tPipe #l\t\t J InterceptorU j Tank\t\t j Rainfall\n"); printf(" j \t | Inflow\t | Flow\t j Divert\t | Inflow\t | OVflow\t | Volume\t | Percent j int'y\n"); printf(" i \t | \t | release | \t | \t | \t | stored\t | filled | \n"); printfC I (min)\t| (cms)\t| (cms)\t| (%)\t| (cms)\t| (cms)\t| (mA3)\t| (%)\t j (mm/hr)\n"); printfC \n"); heading = 1; } 175 gotoxy(l,6); printf("%6d%8.2f%8.2f%8.0f%8.2f%8.2f%8.0f%8.2f%8.2Ar,,,5*i, inflow, release, diversion * 100, interflow, overflow, volume, p_filled, intensity); } void print2file(FILE *fp, int i, float inflow, float release, float int_flow, float overflow, double deltaD) { fprintf(fp, "%8d\t%8.5f\t%8.5f\t%8.5f\t%8.5f\t%8.5f\n",i*5, inflow, release, int_flow, overflow, deltaD); } / *T* *** * l* * l* 1 * * l* •** *•* * l * 1* * l * * l * *t* *f* *t* 1 * *•* *t* *(* * l* *1* * l* * l* *** ^T^^ I ^1 "1 \ / ^ ^ 1 * d / ^ n ^^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ / float get_diversion(void) { float divert; gotoxy(5, 9); printf("Divert %:"); scanf("%f", &divert); return divert/100; } 176 // file: flolib.h #include <stdio.h> #include <stdlib.h> #include <math,h> #define max_storm 120 // maximum length of storm ie. 7 hrs #define max_response 120 // maximum length of response curve // these values represent time steps #define time_step 0.08333333 // simulation time step, ie. 5 min #define true 1 #define false 0 /* The type HYDROGRAPHJTYPE can represent any series of continuous flows. This includes time-area unit hydrographs, unit hydrographs, and runoffs from catchments. */ typedef struct { float graph[max_response]; } HYDROGRAPHJTYPE; typedef int BOOL; /* CATCHMENTTYPE contains the parameters which describe the catchment being modelled. */ typedef struct { float B; // baseflow float Inf; // infiltration float A; // basin area float w; // ratio of maximum basin width to average width float h; // portion of basin contributing at Tc/2 float K; // storage constant (hrs) float Tc; // time of concentration (hrs) float x; // Muskingum routing constant } CATCH_TYPE; /* This function generates a random value from the normal distribution having a mean of mean and a standard deviation of stddev. */ double normal(double mean, double stddev) { double aO, al, bl, b2, t, p, xp, num; 177 short is_neg = false; unsigned seed; static int seeded = 0; /* user seeds random number generator */ if (!(seeded)) { printf("Enter seed: "); scanf("%u", &seed); printf("\n"); srand(seed); seeded = 1; } aO = 2.30753; al = 0.27061; bl = 0.99229; b2 = 0.04481; do{ p = (double) random(1000)/1000.0; // generate random number between 0 & 1 } while (p = = 0); if(p > 0.5) { p = 1 - p; is_neg = true; } t = sqrt(log(l/pow(p,2))); xp = t - ((a0 + al * t)/(l + bl * t + b2 * pow(t,2))); if (is_neg) xp *= -1.0; num = xp * stddev + mean; if (num < 0) return 0.0; else return num; } /*********** print an hydrograph array of floats to a text file **********/ void print_hydro(HYDROGRAPH_TYPE hydro, int no_of_elements, char *file_name) { 178 FILE *fp; // pointer to file int i; // counting integer if ((fp = fopen(file_name, "w")) = =NULL) { printf("Error opening file\n"); exit(l); } for (i = 0; i < no_of_elements; i++) fprintf(fp, "%f\n", hydro.graph[i]); fclose(fp); } void pause(int time) { #define magic_number 1540 inti, j ; for(i = 0; i < time; i+ +) { for(j = 0; j < magic_number; j + +){} } } / «k *k sk 9k sk 9)c 9k sk 9k sk sk 9k sk sk sk sk sk sk sk sk sk 9{c sk sk 9k p l o c c Q("OT"lYI f V T l f * /* The class stormtype includes the public members dt, hyetographQ, and init(). dt is the time step, hyetograph[] is the array of storm intensities, and initO begins the storm building process. The private members are build_storm() and huff_storm(). build_storm() randomly selects one of five Huff curves for the B.C. Coast region, obtains the total depth fallen at time time from huff_storm(), cal-culates the intensity for each time step, and then randomizes that intensity to create some variation in the storm. */ class stormjype { void build_storm(void); // construct hyetograph float huff_storm(float time); // Huff storm formulae public: float dt; // time step float hyetograph[max_storm]; // storm hyetograph float duration; // total duration of storm 179 float depth; // total depth fallen int storm_number; // Huff storm (0 - 4) int num_steps; // number of time steps for duration void init(void); // initialize storm_type object }; void storm_type: :build_storm(void) { int step, // time step for building storm i; // counting integer float dlast, // depth calculated from Huff curve in last time step d, // depth calculated in this time step, deltad, // incremental depth fallen in this time step, pdeltad, // percentage of total depth fallen in this time step frac_of_rem, // fraction of total remaining depth fallen in this // time step. depth_remain, // depth of rain yet to fall, intensity, // intensity of rainfall in this time step, time; // time at this time step printf(" storm number: %d\n", storm_number); printf("duration: %f\n", duration); printf("depth: %f\n", depth); dlast = 0.0; num_steps = (int) (duration/dt) + 1; depth_remain = depth; // Initialize hyetograph to 0.0 for(i = 0; i < maxstorm; i++) hyetograph[i] = 0.0; // Begin to build storm for(step = 0; step < num_steps; step++) { time = (((float) step + 1.0)/(float) num_steps); d = huff_storm(time); pdeltad = d - dlast; frac_of_rem = pdeltad / (1.0 - dlast); dlast = d; deltad = frac_of_rem * depth_remain; intensity = deltad/dt; if(step ! = numsteps) // do not randomize intensity at last step 180 intensity = normal (intensity, 0.2 * intensity); hyetograph[step] = intensity; // printf("step %d: %f\n", step, intensity); depth_remain -= intensity * dt; } float storm_type::huff_storm(float time) { float a, b, c; // Huff storm parameters switch(storm_number) { case 0: a = -0.36; b = 0.0; c = 1.36; break; case 1: a = -0.225; b = 0.18; c = 1.045; break; case 2: a = -0.63; b = 0.99; c = 0.64; break; case 3: a = -0.765; b = 1.395; c = 0.37; break; case 4: a = -0.495; b = 1.44; c = 0.055; break; } // 10% Total No. of Events // 30% Total No. of Events // 50% Total No. of Events // 70% Total No. of Events // 90% Total No. of Events } return a*pow(time,3) + b*pow(time,2) + c*time; void storm_type::init(void) { float avg_intensity, a = 160.9375, c = 0.469774; // IDF curve parameters for 2 year storm dt = time_step; // set time step duration = normal(4,2); // get total duration of rainfall 181 // get average intensity based upon a 2 year IDF for the Abbotsford region avg_intensity = (a * duration * 60 * (1 - c)) / pow(duration*60, (1 + c)); depth = avgintensity * duration; // get total depth depth = normal(depth, 0.05 * depth); // randomize depth stormnumber = randO % 5; // choose 1 of 5 Huff storms at random buildstormO; // construct the hyetograph } void print_storm(storm_type storm, int no_of_elements, char *file_name) { FILE *fp; // pointer to file int i; // counting integer if ((fp = fopen(file_name, "w")) = =NULL) { printf("Error opening file\n"); exit(l); } for (i = 0; i < no_of_elements; i++) fprintf(fp, "%f\n", storm.hyetographfi]); fclose(fp); } void* allocate(size_t num_bytes) { void *pointer; pointer = malloc(numbytes); if(!pointer) { printf("Allocation error!"); exit(l); } return pointer; } float get_trend(float *data, int n) { int i; float sumxy = 0; float sumx = 0; 182 float sumy = 0; float sumxsquared = 0; float slope; for(i = 0; i < n; i++ ) { sumxy + = i * *data; sumy + = *data; sumx + = i; sumxsquared + = i * i; data+ + ; } slope = (sumxy - (sumx * sumy) / n)/(sumxsquared - sumx * sumx / n); return slope; } 183 Appendix B: Fuzzy Inferencing Routine Example C Code / * * Togai InfraLogic (R) Personal Fuzzy-C Compiler Version 1.1.2 * * Source file: "divert.til" * * Compiled Sat Dec 12 23:31:45 1992 * * Selected options: * Default map size: 256 * Output C format: OFF * Emit unused MEMBERS: ON * Force expr: OFF * Force map: OFF */ /* * Portability definitions and internal structures. */ ^include <stdio.h> #include < string.h> #include <math.h> #include <tilcomp.h> #include "divert.h" #define min(a,b) ((a)<(b)?(a):(b)) #define max(a,b) ((a)<(b)?(b):(a)) struct _til_cfinfo { double moment, area; }; /* * Point list evaluation routine for float values. */ static FLOAT _FLO_f_ploop (FLOAT var, int n, struct FLOfjpoint *pts); static FLOAT _FLO_f_ploop (FLOAT var, int n, struct _FLO_f_point *pts) { register int i; FLOAT _alpha; FLOAT _tmp; if (var < pts- > x) 184 alpha = 0.000000; else if (var = = pts- > x) _alpha = pts->y; else { _alpha = 0.000000; for (i = 0; i < n - 1; i+ + , pts++) if (var > pts->x && var < = (pts+l)->x) { tmp = (((double) var) - ((double) pts- > x)) * ((pts+l)->y-pts->y); _alpha = pts- > y + _tmp / (((double) (pts+l)->x) - ((double) pts->x)); break; } } return _alpha; } /* * User defined objects. */ /* * VAR OF */ /* * MEMBER NL */ static struct _FLO_f_point _OF_NL_f_ptsD = { { -3.60000, 1.00000 }, { -0.800000, 1.00000 }, { -0.400000, 0.000000 } /* * MEMBER NS */ static struct _FLO_f_point _OF_NS_f_ptsD = { { -0.800000, 0.000000 }, 185 { -0.400000, 1.00000 }, { 0.000000, 0.000000 } }; / * * MEMBER ZO */ static struct _FLO_f_point _OF_ZO_f_ptsn = { { -0.400000, 0.000000 }, { 0.000000, 1.00000 }, { 0.400000, 0.000000 } }; / * * MEMBER PS */ static struct _FLO_f_point _OF_PS_f_ptsQ = { { 0.000000, 0.000000 }, { 0.400000, 1.00000 }, { 0.800000, 0.000000 } }; / * * MEMBER PL */ static struct _FLO_f_point _OF_PL_f_ptsD = { { 0.400000, 0.000000 }, {0.800000, 1.00000}, { 10.0000, 1.00000 } }; / * * VAR deltaQ */ /* * MEMBER NEG */ static struct _FLO_f_point _deltaQ_NEG_f_ptsD = { { -0.600000, 1.00000 }, {-0.160000, 1.00000}, 186 { 0.000000, 0.000000 } }; / * * MEMBER ZO */ static struct _FLO_f_point _deltaQ_ZO_f_pts[] = { {-0.120000,0.000000}, {0.000000, 1.00000}, {0.120000, 1.00000} }; / * * MEMBER POS */ static struct _FLO_f_point _deltaQ_POS_f_pts[] = { { 0.000000, 0.000000 }, {0.160000, 1.00000}, { 0.600000, 1.00000 } }; / * * VAR deltaD */ /* * MEMBER NL */ /* * moment: -987.5 * area: 27.5 * centroid: -35.9091 */ static struct _til_cfinfo _deltaD_NL_cfinfo = { -987.500, 27.5000 }; /* * MEMBER NS */ /* * moment: -225 187 area: 15 * centroid: -15 */ static struct _til_cfinfo _deltaD_NS_cfinfo = { -225.000, 15.0000 }; /* * MEMBER ZO */ /* * moment: -2.08167e-015 * area: 15 * centroid: -1.38778e-016 */ static struct _til_cfinfo _deltaD_ZO_cfinfo = { -2.08167e-015, 15.0000 }; /* * MEMBER PS */ /* * moment: 225 * area: 15 * centroid: 15 */ static struct Jilcfmfo _deltaD_PS_cfinfo = { 225.000, 15.0000 }; /* * MEMBER PL */ /* * moment: 987.5 * area: 27.5 * centroid: 35.9091 */ static struct _til_cfinfo _deltaD_PL_cfinfo = { 987.500, 27.5000 }; /* * FUZZY Get_f_diversion */ 188 static void Get_f_diversion (FLOAT OF, FLOAT deltaQ, FLOAT *deltaD); static void Get_f_diversion (FLOAT OF, FLOAT deltaQ, FLOAT *deltaD) { FLOAT _alpha; FLOAT _OF_is_NS; FLOAT _OF_is_ZO; FLOAT _OF_is_PS; FLOAT _deltaQ_is_NEG; FLOAT _deltaQ_is_ZO; FLOAT _deltaQ_is_POS; struct _til_cfinfo deltaDtemp; memset (&_deltaD_temp, 0, sizeof (_deltaD_temp)); _OF_is_NS = _FLO_f_ploop (OF, 3, _OF_NS_f_pts); _OF_is_ZO = _FLO_f_ploop (OF, 3, _OF_ZO_f_pts); _OF_is_PS = _FLO_f_ploop (OF, 3, _OF_PS_f_pts); _deltaQ_is_NEG = _FLO_f_ploop (deltaQ, 3, _deltaQ_NEG_f_pts); _deltaQ_is_ZO = _FLO_f_ploop (deltaQ, 3, _deltaQ_ZO_f_pts); _deltaQ_is_POS = _FLO_f_ploop (deltaQ, 3, _deltaQ_POS_f_pts); /* * RULE Rulel */ _alpha = _FLO_f_ploop (OF, 3, _OF_PL_f_pts); /* * RULE Rule2 */ _alpha + = min(_OF_is_PS, _deltaQ_is_POS); if(_alpha!= 0.000000) { /* deltaD = PL */ _deltaD_temp. moment + = _alpha * _deltaD_PL_cfinfo.moment; _deltaD_temp.area + = _alpha * _deltaD_PL_cfinfo.area; } /* * RULE Rule3 189 * / _alpha = min(_OF_is_PS, _deltaQ_is_ZO); /* * RULE Rule5 */ _alpha + = min(_OF_is_ZO, _deltaQ_is_POS); /* * RULE Rule6 */ _alpha + = min(_OF_is_ZO, _deltaQ_is_ZO); if Calpha != 0.000000) { /* deltaD = PS */ _deltaD_temp.moment + = _alpha * _deltaD_PS_cfinfo.moment; deltaDtemp.area + = alpha * deltaDPScfmfo.area; } /* * RULE Rule4 */ _alpha = min(_OF_is_PS, _deltaQ_is_NEG); /* * RULE Rule7 */ alpha + = min(_OF_is_ZO, _deltaQ_is_NEG); /* * RULE Rule8 */ _alpha + = min(_OF_is_NS, _deltaQ_is_POS); /* * RULE Rule9 190 * / alpha + = min(_OF_is_NS, _deltaQ_is_ZO); if (_alpha != 0.000000) { /* deltaD = ZO */ deltaDtemp. moment + = _alpha * _deltaD_ZO_cfinfo. moment; _deltaD_temp.area + = _alpha * _deltaD_ZO_cfinfo.area; } /* * RULE RulelO */ alpha = min(_OF_is_NS, _deltaQ_is_NEG); ifOdpha!= 0.000000) { /* deltaD = NS */ _deltaD_temp.moment + = _alpha * _deltaD_NS_cfinfo. moment; deltaDtemp.area + = alpha * _deltaD_NS_cfinfo.area; } /* * RULE Rulell */ alpha = _FLO_f_ploop (OF, 3, _OF_NL_f_pts); if Calpha ! = 0.000000) { /* deltaD = NL */ _deltaD_temp. moment + = _alpha * _deltaD_NL_cfinfo.moment; deltaDtemp.area + = alpha * deltaDNLcfinfo.area; } if (_deltaD_temp.area ! = 0.000000) *deltaD = (_deltaD_temp. moment / _deltaD_temp.area); 191 } / * * PROJECT Diversion */ void Diversion (FLOAT OF, FLOAT deltaQ, FLOAT *deltaD) { /* * FUZZY Get_f_diversion */ Get_f_diversion (OF, deltaQ, deltaD); } 192 file: divert, h / * * Togai InfraLogic (R) Personal Fuzzy-C Compiler Version 1.1.2 * * Source file: "divert.til" * * Compiled Sat Dec 12 23:31:45 1992 * * Selected options: * Default map size: 256 * Output C format: OFF * Emit unused MEMBERs: ON * Force expr: OFF * Force map: OFF */ struct _FLO_f_point { FLOAT x; FLOAT y; }; void Diversion (FLOAT OF, FLOAT deltaQ, FLOAT *deltaD); file: tilcomp.h / * * tilcomp.h * * Fuzzy-C output portability type include file. * * Author: Erik Horstkotte, 3/17/89 */ typedef double FLOAT; 193 


Citation Scheme:


Citations by CSL (citeproc-js)

Usage Statistics



Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            async >
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:


Related Items