Laserfiche WebLink
<br />io~t335 <br /> <br />The Resident Power and Reservoir System Model (PRSYM) <br /> <br />Modular <br /> <br />The code should be modular, containing components of reusable code which can be identified <br />and modified if necessary. Code modularity should also support the addition of new or <br />different model functionality to accommodate utility-specific procedures (e.g., a unique <br />approach to computing hydropower generation) or to utilize new advances in analytical <br />methodologies (e.g., a new linear programming approach). Additionally, during the model <br />development stage, code modularity should enable the model to function at various levels of <br />complexity. For example, the model first could be operational based on mass balance <br />computations, then accommodate the addition of routing techniques. <br /> <br />Extensible <br /> <br />Model modularity will facilitate software extensibility in that new methods and procedures <br />can be added by a programmer. For example, a new approach for computing reservoir <br />releases or evaporation could be added to an object's (i.e., dam or reservoir) procedure <br />library. This capability allows PRSYM to be ported to other utilities with minimal effort and <br />supports the incorporation of advances in analytical techniques. <br /> <br />Object-Oriented Appraach <br /> <br />The object-oriented software modeling approach supports the requirements for a modeling <br />environment that is generic, portable, data-centered, modular, and extensible. Object- <br />oriented software separates functions from data by creating objects, each of which knows <br />how to perform its own functions and remembers its own data. <br /> <br />These objects provide a natural representation of reservoir system elements (dams, <br />reservoirs, power plants, diversions, etc.) from an engineering perspective. Simulated <br />processes (such as flow dynamics, hydropower generation, etc.) are separate from the <br />operating policies and rules which govern the operation of the system. Processes are also <br />separate from the data which define the system network (e.g., reservoir geometry) and from <br />data which drive the system (e.g., local inflow). <br /> <br />This separation results in a model of the system consisting of objects connected in a defined <br />network, each of which has a certain function. '01rough class inheritance, every object need <br />not be completely defined, but need only be differentiated from other objects in its class. <br />The network connections are data as well. Hence, porting the model to a new reservoir <br />system is a matter of defining a new network of given objects, giving the objects the correct <br />attribute data, and defining new operating policies or rules. The model/software is easily <br />extensible by adding new types of objects or by giving existing objects new functions. <br />Operating policies can likewise be modified as data, because they are not coded as <br />procedures or 'hardwired' into the modeling framework. <br /> <br />3-13 <br /> <br />~~-- <br />