24 .edu
MidAmerican Energy Company Non-Monotonically Increasing Generating Unit Dispatch
Design Report
May06-07
Client:
MidAmerican Energy Company
Alan Oneal
Faculty Advisors:
Dr. John Lamont
Dr. James McCalley
Students:
Matthew Ellis, EE
Noraima Fernandez, EE
Jeremy Hamilton, EE
Robert Walter, EE
REPORT DISCLAIMER NOTICE
DISCLAIMER: This document was developed as a part of the requirements of an electrical and computer engineering course at Iowa State University, Ames, Iowa. This document does not constitute a professional engineering design or a professional land surveying document. Although the information is intended to be accurate, the associated students, faculty, and Iowa State University make no claims, promises, or guarantees about the accuracy, completeness, quality, or adequacy of the information. The user of this document shall ensure that any such use does not violate any laws with regard to professional licensing and certification requirements. This use includes any work resulting from this student-prepared document that is required to be under the responsible charge of a licensed engineer or surveyor. This document is copyrighted by the students who produced this document and the associated faculty advisors. No part may be reproduced without the written permission of the senior design course coordinator.
Submitted December 8, 2005
Table of Contents
1 Frontal Materials iii
List of Figures iii
List of Tables iv
List of Definitions v
2 Introductory Materials 1
2.1 Executive Summary 1
2.2 Acknowledgement 2
2.3 Problem Statement 2
2.3.1 General Problem Statement 2
2.3.2 General Solution Approach 2
2.4 Operating Environment 3
2.5 Intended User(s) and Intended Uses(s) 3
2.5.1 Intended User(s) 3
2.5.2 Intended Use(s) 3
2.6 Assumptions and Limitations 4
2.6.1 Assumptions 4
2.7 Expected End Product and Other Deliverables 6
2.7.1 Microsoft Excel workbook file 6
2.7.2 Documentation 6
3 Approach and Product Design Results 7
3.1 Approach Used 7
3.1.1 Design Objectives 7
3.1.1.1 Unit Commitment Page 7
3.1.1.2 Output Page 7
3.1.1.3 Usability 8
3.1.1.4 Overall Structure of the Software 8
3.1.1.5 Programmer’s Guide 8
3.1.1.6 Miscellaneous Objectives/ Future Work 9
3.1.2 Functional Requirements 9
3.1.3 Design Constraints 10
3.1.4 Technical Approach Considerations and Results 11
3.1.5 Testing Approach Considerations 11
3.1.6 Recommendations Regarding Project Continuation or Modification 12
3.2 Detailed Design 12
3.2.1 Unit Commitment Page 13
3.2.2 Output Page 15
3.2.3 Usability 17
3.2.4 Overall Structure of the Software 23
3.2.5 Programmer’s Guide 24
4 Resources and Schedules 34
4.1 Resources Requirements 34
4.1.1 Estimated Personnel Effort Requirements 34
4.1.2 Estimated Other Resource Requirements 35
4.1.3 Estimated Total Financial Requirements 36
4.2 Schedules 37
4.2.1 Revised Schedule 37
4.2.2 Deliverables Schedule 42
4.2.3 Weekly Schedule – Spring 2006 44
5 Closure Materials 49
5.1 Project Team Information 49
5.1.1 Client Information: 49
5.1.2 Faculty Advisors: 49
5.1.3 Student Information: 49
5.2 Closing Summary 50
1. Frontal Materials
List of Figures
|Figure 1: |Monotonic Incremental Cost Curve |v |
|Figure 2: |Non-monotonic Incremental Cost Curve |v |
|Figure 3: |Combined Cycle Generator |1 |
|Figure 4a: |The Updated Unit Commitment Page |14 |
|Figure 4b: |The Updated Unit Commitment Page |14 |
|Figure 5: |The Generator Output Page |15 |
|Figure 6: |The Generator Cost Page |16 |
|Figure 7: |The Fuel Use Page |16 |
|Figure 8: |Menu Structure Flowchart |17 |
|Figure 9a: |Main Menu |21 |
|Figure 9b: |Main Menu |22 |
|Figure 10: |Basic Flow of Programming Modules |25 |
|Figure 11: |Algorithm Flowchart |29 |
|Figure 12: |Original Gantt Chart |40 |
|Figure 13: |Revised Gantt Chart |41 |
|Figure 14: |Original Deliverables Schedule |43 |
|Figure 15: |Revised Deliverables Schedule |43 |
List of Tables
|Table 1: |Project Assumptions and Justifications |4 |
|Table 2: |Project Limitations and Justifications |5 |
|Table 3: |Coefficient Computation Example |25 |
|Table 4: |Nuke 1 Data |26 |
|Table 5: |Nuke 1 Computed Coefficients |27 |
|Table 6: |Original Personnel Effort Resource Requirements |34 |
|Table 7: |Revised Personnel Effort Resource Requirements |35 |
|Table 8: |Original Other Resource Requirements |35 |
|Table 9: |Revised Other Resource Requirements |36 |
|Table 10: |Original Project Cost Estimates |36 |
|Table 11: |Revised Project Cost Estimates |37 |
List of Definitions
Combined cycle unit: a dual cycle generating unit that first produces power through a combustion turbine, then uses the waste heat to vaporize water and drive a steam turbine
Combustion turbine: a generating unit used to meet peak loading conditions by the combustion of fuel, usually natural gas
Economic dispatch: the allocation of the total load demand among generating units in order to achieve the most economical production of power
Heat-recovery steam generator: the second process of the combined cycle that recovers waste heat to drive a steam turbine
Incremental cost: the increase in cost in dollars per increase in mega-watt hours
Initial project: the dispatching algorithm designed by May 05-10 project team
Input/output function: the ratio of fuel input in MBtu per hour to power output in mega-watts
Main program: the initial run of code that must iterate through entire 168-hour range
Monotonic unit (MU): a generator that produces more power output as fuel input is increased
Non-monotonic unit (NMU): a generator that can have an increase in power output with no increase in fuel input
Secondary program: allows for the code to be ran for a user defined range of hours after the main program has been successfully completed
2. Introductory Materials
This section establishes the project’s purpose, including a description of the problem, plans for reaching a solution, and possible assumptions and limitations that the project team will have to deal with along the way.
1 Executive Summary
This section establishes the project’s purpose, including a description of the problem, plans for reaching a solution, and possible assumptions and limitations that the project team will have to deal with along the way.
Combined-cycle generating units are being incorporated into the current power system in order to meet peak loading contingencies as efficiently as possible. Combined-cycle generating units consist of two simple-cycle combustion turbines and one heat recovery steam generator as shown in Figure 1. Combined-cycle generating units exhibit non-monotonically increasing cost curves which cannot be solved by classical methods of economic dispatch optimization. The project team will modify and redesign a pre-existing algorithm to calculate optimal economic dispatch, including both monotonically and non-monotonically increasing generators, with a shorter solution time. Major milestones include comprehension of the pre-existing optimization algorithm, implementation of the algorithm in Microsoft Excel using Visual Basic macro programming, redesign of the optimization algorithm for faster solution speed, and delivery of the software and documentation to the client. Optimal results will allow for power to be produced at the lowest possible cost to the client while prolonging the life of each generating unit.
[pic]
Figure 3: Combined Cycle Generator
Graphic from
2 Acknowledgement
The senior design project team would like to acknowledge Alan Oneal from MidAmerican Energy Company as our client contact for the project. The project team would also like to thank Dr. Lamont for advising and overseeing the project.
3 Problem Statement
The problem statement is composed of two components: the general problem statement and the general solution statement.
1. General Problem Statement
The project involves the modification of an algorithm incorporated into Microsoft Excel macros to give MidAmerican Energy the lowest cost solution to meet power demand with the shortest solution time possible. The problem will involve the use of monotonic and non-monotonic generation systems. Monotonically increasing systems are systems that create more power when the fuel supply is increased. Non-monotonic systems may show a power increase without any more fuel being provided to the system and thus without the normal increase in costs. The algorithm will use information from an Excel workbook to come up with the most cost effective generation dispatch combinations. Macro programming using Visual Basic will be used to modify and implement the developed solution algorithm.
2. General Solution Approach
MidAmerican Energy supplied the data for the power generators. This data includes minimum and maximum load values, fuel costs, power generation levels with their corresponding incremental heat rate values and I/O values. The initial project team developed the algorithm used this data to create the piecewise-linear cost functions for each power generator range and also determine whether a given unit is a monotonic or non-monotonic generator based upon the piecewise-linear determinations.
The initial project team developed the equations for algorithm to perform a standard lambda search with the monotonic generators that the user specifies as operational. The program then populates a table for the lowest cost dispatch among the MUs at each possibly load value (a definable step, default = 1MW). The load values extremes are also determined using the combined generator minimum and maximum values.
After the monotonic unit table is populated, the algorithm moves on to the non-monotonic power generators. A similar table to that of the monotonic populated a minimum cost dispatches for each load value. These minimum cost values are determined by running a series of loops that compare all possible dispatch situations and then take the minimum value of each specified load value.
At this point the initial project’s algorithm determines the least cost dispatch available by the generator to meet the load requirements.
The project team will focus their efforts on a number of modifications to increase the overall usability of the software. These areas of modification will concentrate on improving the structure of the unit commitment page, reorganizing the way outputs are displayed, implementing a main menu, and finally restructuring the code to allow the user to dispatch only a range of hours.
During the project, weekly e-mails to the client and faculty advisor will detail the work that has been completed and future plans. After the initial software is completed it will be turned over to MidAmerican Energy Company for verification. In addition, the software will then be returned to the project team and any necessary modifications will be made. At the completion of the project all deliverables, including the completed software and final documentation, will be handed over to MidAmerican Energy Company.
4 Operating Environment
The solution program will be written using Visual Basic macro programming embedded in the form of a Microsoft Excel workbook. The software will run on a windows-based system with adequate processing capabilities.
5 Intended User(s) and Intended Uses(s)
This section provides the intended user(s) and use(s) of the project team’s final product.
3. Intended User(s)
The software will be designed for MidAmerican Energy employees who work in the short-term trading and have a basic understanding of optimization and economics. The user(s) must have experience using Microsoft Excel and an understanding of power system analysis.
4. Intended Use(s)
The software will be used to optimize the economic dispatch of power between monotonic and non-monotonic generators. Microsoft Excel will be used to process input data from generating units and produce output into a workbook or an external file which can be used for analysis of day-to-day operations.
6 Assumptions and Limitations
This section provides the assumptions and limitations concerning the problem.
5. Assumptions
Table 1 lists the project assumptions and their justifications.
|Table 1. Project Assumptions and Justifications |
|The project team will have access to the current methods for optimizing |Testing Requirement |
|combined-cycle generators. | |
|A priority status will be placed on all generation units. |Client Requirement |
|Project ideas should not be shared outside the project team. |Confidentiality Requirement |
|A well-designed solution method is more important than the most efficient solution. |Client Requirement |
|The end product will be used in the United States. |Power System Requirement |
|The initial project’s algorithm is determining the least cost dispatch available to |Testing Requirement |
|the generator to meet load requirements | |
6. Limitations
Table 2 lists the project limitations and their justifications.
|Table 2. Project Limitations and Justifications |
|The software will be written in Microsoft Excel with Visual Basic macro programming. |Client Requirement |
|The software code shall contain ample comments. |Client Requirement |
|Software must permit generator status to be specified hourly within a 7 day horizon. |Client Requirement |
|Status Codes |Software Requirement |
|- 1 |Forced Off |1 |On/dispatchable | |
|0 |Off/available |2 |On/fixed output | |
|Software accepts input data for generating units that use piece-wise linear incremental |Client Requirement |
|heat rate curves, with up to 10 segments each. | |
|Software includes an elapsed time indicator for performance measurements. |Software Requirement |
|A switch must be provided to allow full-output dumps (to the workbook, or output file) of |Software Requirement |
|iterations tested, their cost, total generation, and other relevant metrics as agreed upon | |
|between the client and the team. | |
|Results must be written into a single Excel workbook, by unit and by hour (MW output, |Client Requirement |
|production cost), with appropriate totals and other statistics as agreed to by the client. | |
|12 MUs and 2 sets of NMUs will be used for calculations. |Client Requirement |
7 Expected End Product and Other Deliverables
This section states what will be given to the client upon completion of the project.
7. Microsoft Excel workbook file
The Excel workbook file will include user instructions along with the Visual Basic code containing embedded commenting. The software will employ an economic dispatch algorithm used for monotonic and non-monotonic generating systems. An initial version of the software will be provided to the MidAmerican Energy Company for testing purposes. Any necessary changes will be made prior to completion of the project. The software will meet the requirements listed in the limitations section.
8. Documentation
Test results from the software will be given to MidAmerican Energy Company. A printed copy of the fully commented program code, a user manual, a programmer’s guide, and other documentation will be provided to the client upon completion of the project.
3. Approach and Product Design Results
The following section describes the project team’s proposed approach toward solving the problem, and tasks that will be successfully completed along the way.
8 Approach Used
A successful project will meet the following twelve requirements.
1 Design Objectives
Because the all of the main economic dispatching algorithms and data loading functions have already been designed, implemented, and assumed working appropriately, the project team will be concentrating their efforts on modifying the existing software for better usability and efficiency.
These goals shall be attained upon the successful completion of the project.
1. Unit Commitment Page
• The new unit commitment page will recalculate the maximum capability of the committed units, display the generation requirements the reserve of the committed units, calculate the foot room of the committed units, and calculate the minimum capability of the committed units for each of the 168 hours based on changes in the unit commitment table.
• The new unit commitment page will also contain a check to make sure that when the unit commitment page is changed; all of the up and down times for each generator will not be violated for all of the 168 hours. The upgraded page will also check that the load is within the following limits:
Min. Capability + Foot Room < Load < Max. Capability - Reserve
2. Output Page
• The current output page will be redesigned to be split up into three separate output pages which will all contain the maximum capability, reserve, the generation, the foot room, and the minimum capability.
• The pages will be split up into a page that contains generation output data, the cost of each generator, and the fuel use for each generator for each of the 168 hours.
3. Usability
• The entire program will be run from a visually appealing and easy-to-follow main menu. The menu will have hyperlinks to all worksheets where user inputted data is stored. Before each hyperlink a brief description of what the corresponding worksheets functions are and how to appropriately input data to them.
• The user will also have many more options from this main menu, which will allow for multiple combinations of output displays and the ability to reset many values to their default setting.
1 Overall Structure of the Software
• The way the code is currently arranged it finds dispatch solutions for all 168 weekly hours when it is executed. The project team will modify the current software so that the user will have the ability to specify a range of hours or a start day/hour and end day/hour to solve. This option will only be available to the user after the software has initially found solutions for the 168-hour week. This will allow the user to save time and concentrate their efforts on a specified time frame.
• There are two time requirements. The entire program when executed for the entire week (and loading in all new data) must completely solve for 168 dispatch solutions in less than five minutes. Since the project will now be able to solve for only a designated range of hours a separate time constraint must be included. The software must have the ability to dispatch a single hour in ten seconds or less. After completion of the project the team will spend remaining time optimizing the algorithm and data loading functions to decrease run time (see Section 3.1.1.5).
2 Programmer’s Guide
• A programmer’s guide will be written to assist anyone who plans on understanding how the program works, adds additional functionality to the code, or maintains the code.
• The programmer’s guide will contain the following information:
• The general solution algorithm of the program, with a hand calculated example for easy understanding.
• Descriptions of each subroutine as well as a call tree.
• A list and description of all global and local data variables. Each description will include a list of subroutines that calls the variable.
• A list of error messages as well as possible resolutions to fix the error message.
• The programmer’s guide will include a complete print out of the most updated code and comments
4. Miscellaneous Objectives/ Future Work
This section contains project specifications set by the client to be designed and completed on a time availability basis.
• Graphs that show weekly loading, weekly generation per generator and weekly generation for the entire system.
• Graphs that show weekly fuel usage for each generator and fuel usage for the entire system.
• Graphs that show weekly cost of operating for each generator and cost of operating for the entire system.
• Possible implementation of a faster solution algorithm.
1. Functional Requirements
Required functions of the end product include the following:
▪ The end-product will calculate economic dispatch results for both monotonically and non-monotonically increasing generators using Microsoft Excel with Visual Basic macros.
▪ Economic dispatch results will be calculated and displayed within five minutes for every possible generation scenario and ten seconds for the single hourly solution.
▪ The main page of the Excel file will have a user-friendly GUI and will contain explanations for the functionality of different pages and simple instructions for use of the program.
▪ The pages within the Excel file will be improved to display data in a more user-friendly manners. Displays will be changed to maintain a consistent theme throughout the program.
▪ The updated unit commitment page will have the following properties:
• The unit commitment page will have the ability to recalculate the maximum generation, reserve, foot room, and minimum generation based on the generation requirement and commitment pattern for each of the 168 hours.
• The unit commitment page will contain a check to ensure that each generator’s up and down times are respected after any change made within the unit commitment page.
▪ The output data will be modified to the following format:
• The output work books will be split into three separate work books; generator output, generator cost, and fuel use.
• Each output workbook will contain the following data at the top of each: maximum capability, reserve, total generation, foot room, and minimum capability for each of the 168 hours.
2. Design Constraints
The following design constraints must be considered:
▪ The algorithm will be implemented using Visual Basic macro programming embedded in Microsoft Excel.
▪ The design will be flexible with regard to the number of monotonic and non-monotonic units. This product should have the ability to be expanded upon by MidAmerican Energy for future expansion. Limitations should not be placed on the number or type of units that can be handled.
▪ The software will have the ability to be run for a range of user designated hours.
▪ Program run time limits will be respected.
• The final version of the complete 168-hour algorithm will have a run time of less than five minutes
• After the program has solved for the 168-hour solution once, the program will have the ability to solve for a single hourly solution. The single hourly solution time will be less than ten seconds.
▪ The upper and lower limits of all generators will be observed. In an effort to streamline the computational process, the upper and lower generating limits for each individual unit shall be observed. There is no need to run cost calculations for power dispatches that are outside the feasible generating ranges. For such an unfeasible case an error message will be displayed and program will stop running.
▪ All tables for user inputs and outputs will be displayed with a common theme.
3. Technical Approach Considerations and Results
The following considerations describe the technical approach to the problem:
▪ An algorithm will be created/modified which uses data provided by the client.
▪ Due to its wide use by MidAmerican Energy, Microsoft Excel will be the program in which the algorithm will be used. Visual Basic technology was also a requirement placed on the project by MidAmerican, thus no other technologies will be considered.
▪ A Windows platform will be used for this project. Windows platforms are used entirely throughout MidAmerican Energy, thus a Windows platform will be the only choice used for the basis of this project.
▪ A user-friendly graphic interface will be created using Microsoft Excel and Visual Basic macros.
▪ Testing will be conducted using the software coded in Visual Basic and Microsoft Excel.
4. Testing Approach Considerations
Adequate testing will be done before and after client use. The following requirements are essential to a successful end-product:
▪ Testing will be performed using data supplied by the client. The client has provided one week of system load data which shall be utilized for the purpose of testing.
▪ Accuracy of testing will be confirmed by comparing the results produced by the software to results provided by the faculty advisor. Hand calculations will be performed for a basic situation involving only a few monotonic and non-monotonic units. This “base case” will help guarantee that the algorithm is performing the correct calculations before the project team uses it with a detailed case. This step will help make the team aware of problems so that they can be resolved.
▪ With the client’s consent, the project will be tested by users outside of the project team before the final testing submission of the program.
▪ After initial testing is performed, software will be produced for final testing in client’s facilities. Any discrepancies between results obtained will be discussed and any necessary modifications to the algorithm shall be completed.
5. Recommendations Regarding Project Continuation or Modification
This section includes the team recommendation regarding project continuation at this point in the schedule.
The team will continue with the project as originally planned. The scope of the project is adequate considering the time commitments the team has projected for the project. The deliverable schedules have been met up to this point in the project. The team feels capable of completing the project.
9 Detailed Design
The modification of the current software can be broken down into a number of different parts. These modules will be individually coded or designed, and tested in Microsoft Excel before being combined for the complete program. By using this method the project team hopes to speed the process of modification by assigning parts to each individual rather than tackling them as a whole. Each modification should have the ability to run with the current program and combining each modification should only involve the changing of destination cells in Microsoft Excel. This will cut down on the amount of end-product testing time necessary since the individual functions will be tested before their final combined implementation.
The following sub-sections are divided into the five main parts where the project team will concentrate their efforts. Each part will go into detail on how the current software will be modified to fulfill the client’s needs.
6. Unit Commitment Page
The existing unit commitment page will be updated to have added features and functionality. The following items will be made to make the unit commitment page more functional. The unit commitment page will recalculate the maximum generation, the reserve, the foot room and the minimum generation based on the generation requirement and unit commitment for each of the 168 hours. The calculations will be made using excel formulas for quick updates based on real-time changes in the unit commitment table. The calculations will be made using IF statements within the Excel sheet for each hour of the week. The IF statements will check if there is a 1 or 0 (or blank in the spot for each hour of the week., and for a 0 (or a blank) the IF statement considers the generator as off/unavailable, and for a 1 the IF statement considers the generator as on/dispatchable and gets the generator limits from the generator limits page for the given hour. After the IF statements gets the generator limits for each hour, it then calculates the maximum generation, the reserve, the foot room and the minimum generation. The maximum generation is the sum of all the generators maximum capabilities for each generator committed in the given hour for the week. Reserve is the maximum generation minus the generation requirement for each given hour of the week. Foot room is the generation requirement minus the minimum generation for each given hour of the week. Minimum generation is the sum of all the generators minimum capabilities for each generator committed in the given hour for the week. See Figure 4a. There will also be an option to fully restore any changes in the unit commitment page back to the original unit commitment pattern. There will also be an option to make the current unit commitment page into the new the default unit commitment pattern.
The unit commitment page will contain a check to ensure that each generator’s up and down times is still respected after any changes made in the unit commitment page. The check will be an Excel formula for quick updates based on real-time changes in the unit commitment page. The formula contained in the sheet checks the number of sequential ones the in the table for each generator and the number of sequential zeroes in the table. It then calculates what the up times are for each generator and the down times for each generator for the given unit commitment pattern in the table. It then checks these up and down times against the given minimum up and down times from the up and down time sheet. If there is a violation for the minimum given commitment pattern for any of the generators, it will be noted in the last column of the unit commitment page. The individual hours that contain the violation for any of the generators will also be marked in orange so that the user will be able to tell where the up and down time violations are within the unit commitment table. See Figure 4b.
All of the different input data can be found in several different sheets within the workbook and all data is both displayable and printable. In addition the fuel costs can be found in a separate text file provided by the client and the input sheet of the Excel workbook. The inputs such as the generator minimum and maximum limits per hour can be found in the Gen Limits sheet and any changes made in the sheet would be reflected in the data displayed at the top of the unit commitment page. All of the data in the Gen Limits sheet is inputted by the user and is not inputted from an external file. The generator up and down times are found in the Up Down Time sheet and any changes made in the sheet would be reflected in the data displayed to the far right in the unit commitment page. All of the data in the Up Down Time sheet is inputted by the user and is not inputted from an external file. The load data input is found in the Load Data sheet and any changes made in the sheet would be reflected in the data displayed at the top of the unit commitment page. All of the data in the Load Data sheet is inputted by the user and is not inputted from an external file.
[pic]
Figure 4a: The Updated Unit Commitment Page
[pic]
Figure 4b: The Updated Unit Commitment Page
7. Output Page
The output data will be recorded into three separate Excel workbooks, one work book for generator output, one for generator cost, and one for fuel use. See Figures 5, 6, and 7. Each output workbook will contain the following data at the top of each: maximum capability, reserve, total generation, foot room, and minimum capability for each of the 168 hours. All of these will be calculated within the Excel Marco and will be displayed after each time the Macro is run. After the first run new data will be displayed in red to distinguish between the first run and each consecutive run. See Figures 5, 6, and 7. All of the changes in the output page will be implemented within the Visual Basic code, in each subroutine that generates the output pages. The existing code will be modified to display the output pages that look like Figures 5, 6, and 7. The color coding for each run will be implemented within the Visual Basic code, in each subroutine that generates the output pages. The existing code will be modified and new subroutines will be written to achieve the color coding previously explained.
[pic]
Figure 5: The Generator Output Page
[pic]
Figure 6: The Generator Cost Page
[pic]
Figure 7: The Fuel Use Page
8. Usability
A client requirement for the software is that any user with adequate knowledge of economic dispatch should be able to easily operate the software without having to research the instruction manual prior to execution. In the current program this is not possible; descriptions are rare and vague, if given; there’s no order or steps necessary for a proper dispatch, and there are no instructions for how a user should input their data. These problems will be corrected through the use of a main menu. The main menu will serve as the “traffic cop” for the entire program. It will give step-by-step instructions for proper execution and will include links to external files where even more detailed instructions will be available for the user.
Figure 8 is a flowchart for how the main menu will be structured.
[pic]
Upon opening the software, one will be at the beginning of the main menu. The menu will start off with a quick description of how it is operated and where one can find troubleshooting help if an error persists. On the flowchart, the first object that one comes across is “1st Time Since Opening?” bubble. This is not actually a user prompt or menu option instead it is a flag that will be set after the software has been completely executed once. This will be described in greater detail later in this section. For now it will be assumed that the software is being ran for the first time. The user will now encounter a series clearly numbered sets that will walk them through their first execution.
All of the following steps follow along with Figure 8.
Main Menu Step 1: Excel Add-Ins
There are several Microsoft Excel add-ins and tool-packs that are absolutely necessary for the execution of the software. These objects must be added-in for every computer where the software is used. Once they are added to a computer, the properties will save and shouldn’t need to be added again; however, the corresponding error message and fix will be noted in the troubleshooter, for the case where the enhancements aren’t save. On this step the user will be prompted whether the software has been run on this computer or not. If not, they will be asked to follow a number of instructions from an external file.
Main Menu Step 2: Generator Data .txt File
The program reads in the generators names, I/O, and MW vs. IHR from an external text file. This step will have two hyperlinks attached to it. The first will go to an external file which will go into detail on how the user’s generator data text file should be formatted. The second hyperlink will be the default generator data text file. From these two hyperlinks, the user has the option to format their own text file or modify the default to their standards.
Main Menu Step 3: Generator Constraints
Generator constraints refer to the hourly maximum and minimum power limits for each generator. This step will tell the user how to modify the generator limits worksheet and then hyperlink them to the appropriate worksheet.
Main Menu Step 4: Unit Commitment
The unit commitment chart is where the client applies the appropriate status code for each generator. These status codes are listed in Section 2.6.2. The menu will inform the user of the generator status codes and then hyperlink them to the unit commitment page for data entry. The unit commitment will be one of the most user modified worksheets in the program. Because there is a high risk that it will become modified to the point where it is not producing the desired results, there will be a reset to default button. By clicking the button the unit commitment pattern will change back to the default (setting the default will be covered later in this section).
The reset button will be designed by adding a new excel worksheet to store all the default unit commitment values. An independent macro will then be written to first store all the default generator names into a data array, and then store the commitment pattern into another data array. The original unit commitment worksheet will then be called and both data arrays will be uploaded to their appropriate locations. All data checking and verification will then be performed as it was done before, in the code and inside the unit commitment worksheet.
Main Menu Step 5: CT/ HRSG Relationship
In this step the user is instructed how the CT/ HRSG relationship worksheet is formatted and of what an appropriate data entry consists. This step will include a hyperlink to the appropriate worksheet.
Main Menu Step 6: Displays
By using a series of scroll down TRUE/ FALSE menus, the user will have the ability to choose numerous output display options. By turning off unwanted outputs the user will not have to sort through extra worksheets to find the desired data, and the software will execute in less time.
Main Menu Step 7: Execution
After the menu has walked the user through all the appropriate steps, the user will be prompted to execute the program. Execution will occur through the clicking of a large button.
After the program is run for the first time, the menu will allow the user to go to a secondary menu. This menu will be an opposite color scheme from the main to make it unmistakable from the main, and will be located on a completely different worksheet. Since the program has already been stepped through, the instructions on this menu will be less descriptive, but will still include links to the original if further instructions are wanted.
Secondary Menu Step 1: Set Unit Commitment to Default
After the program run is complete, the unit commitment pattern will still be stored in memory as a data array. If the user liked the output results they’ll have the option to click a button, which will store the unit commitment pattern corresponding with that output as the new default pattern.
Secondary Menu Step 2: Range of Hours
Many times it is not necessary to run the program for the entire 168 hours. The secondary menu will first ask the user if they want to specify an start day/hour and end day/hour or simply a start/end hour. After specifying this two new lists will appear corresponding to the desired start and end. The use of scroll down lists will alleviate the menu of user input errors.
Secondary Menu Step 3: User Data
The secondary menu will tell the user to set their inputs on the appropriate worksheets (steps two through five on the main menu). Only the links to each worksheet will be displayed. If the user requires more instructions, they can click the hyperlink back to the main menu.
Secondary Menu Step 4: Changed Data?
Once the program run is complete, all the data is already stored in memory as data arrays. If there’s a worksheet that is unchanged it doesn’t need to be reloaded. The secondary menu will have a series of scroll down TRUE/ FALSE lists prompting the user whether the generator data text file, unit commitment pattern, generator constraints, or CT/ HRSG relationships have changed. If they’re false when the program is again executed, those data loading sections will be skipped.
Secondary Menu Step 5: Secondary Execution
The final part of the secondary menu will be a secondary execution button. By clicking the secondary execution button it will allow all the original data to be displayed wherever there is not new output data to replace it.
[pic]
[pic]
Figures 9a and 9b are a prototype for the main menu. The secondary menu will closely resemble the main menu; however, the color scheme will be opposite (red background, white lines and hyperlinks. The menus will adhere to the client requirement and be professional looking and aesthetically pleasing.
9. Overall Structure of the Software
In the current software, when the “Execute” button is pressed the program solves economic dispatch solutions for the 168 hours of the week. However, in many cases, there are only a range of hours which the user wants dispatched. Running the entire program for only a few specific hours is a waste of time. To allow for the software to run for only a designated set of hours, a few modifications have to be made to the existing program.
After the program has run completely through once all of the data (generator limits, unit commitment pattern, and MW vs. IHR for each generator) will all still be stored in global data arrays and stored in memory. By using a scroll down menu, the user will have the ability to choose if these values have changed. The user will also specify a range of hours for the software to dispatch. Once these options have been selected a “secondary” version of the software may be run. This secondary version will actually be a completely different set of modules; however, the majority of it will be copied from the original. Using a series of IF statements, the program will go through and read in the generator limits and generator characteristics only if the user declares that they have been changed. After being read, they will go through the same data checking as the “main 168-hour program.” If neither data sets have been changed the software will simply skip over them and the data array that is in memory will be used by the rest of the program. Next the unit commitment pattern will be loaded. If the unit commitment pattern has been changed the entire unit commitment data array will be zero padded; this will allow the unit commitment data array whose name and size have already been declared to be used whether the unit commitment table has or hasn’t been changed. Since the user only needs a range of values, to save time, only the status codes for the appropriate range of hours will be loaded and checked for accuracy. Once all of the user inputs have been reloaded into their appropriate data arrays the actual economic dispatch solutions can be solved for using the current algorithm. The way that the current solution algorithm works is it continues to solve for dispatches as long as there is data in the unit commitment array; it has a stop flag when it reaches a columns of blanks. To modify this to fit the client’s needs, the project team will rewrite the code so that it uses a start and stop flag. Only the commitment patterns between the two flags will have dispatches computed. The corresponding outputs or solutions will then be loaded into their data array and outputted to the appropriate output page. In this case, all of the original output values will remain on page and only the user specified range of values will be loaded over the original values. These select values will be loaded onto the output pages by using the same start/ stop flag system as before. All new output values will be color coded for easy distinction (see Sections 3.1.1.2 and 3.2.2 for further clarification).
10. Programmer’s Guide
Below is a sample of how the programmers guide will describe the general solution of the program. The sample is not a complete version of the programmer’s guide instead; it’s only meant to give a brief understanding of the final product. Also contained in it will be a complete commented printout of the code.
___________________________________________________________
Sample Programmer’s Guide
I. Software Overview
The program was developed by creating and testing individual modules and then calling them in specific sequences in order to produce output. The Visual Basic code can be viewed by selecting the Tools/Macro/Visual Basic Editor (alt + F11) in the Excel workbook. The security setting must be set to medium or below in order to view or run macros. This setting can be changed by selecting Tools/Macro/Security, choosing the security level, and then closing and re-opening the workbook. Once in the visual basic editor choose View/Project Explorer. This will open the project explorer. Next choose Sheet1 in the Microsoft Excel Objects subfolder under the VBAProject subheading. This will bring up the program code. The top of the code contains declarations for global variables and custom structures. The middle of the code contains the individual code modules that make up the program. The end of the code contains the ALL_TOTAL_RUN() module which is equivalent to main() in other programming languages. It calls the smaller modules in a specified order to produce the output. Below are some brief descriptions of each section of the main code. For a better understanding of each module, the team recommends that the user read through the comments embedded in the code.
II. Solution Algorithm
The design of the algorithm to supply the optimal dispatch can be broken down into a number of different modules. These modules are individually coded in Microsoft Excel and combined for the complete program. Figure 10 shows the basic break down of the programming modules and the basic order in which they run.
[pic]
Figure 10: Basic Flow of Programming Modules
Data for the power generators is supplied by MidAmerican Energy. This data includes minimum and maximum load values, fuel costs and power generation levels. Heat rate data for each generation level will be supplied in the form of an external file. The algorithm takes the data from an external file, loads it into Excel, and creates the piecewise-linear cost functions for each power generator range. It also determines whether a given unit is a monotonic or non-monotonic generator based upon the piecewise-linear determinations. Given the following example data in Table 3, coefficients for a quadratic equation which describes the fuel I/O curve of the unit can be computed.
|Table 3. Coefficient Computation Example |
| | | |Generator Status |
| |
|Nuke 1 | |
|MW |IHR |I/O |
|100 | 8.0000 | 1,250 |
|125 | 8.2000 | |
|150 | 8.4000 | |
|175 | 8.6000 | |
|195 | 8.7500 | |
|200 | 8.8000 | |
At 100 MW level: [pic]
At 125 MW level: [pic]
It is now possible to continue down through the different MW values calculating the C values and the next corresponding I/O values (calculate C at 125, I/O at 150 etc…).
With regard to the determination of the monotonic versus non-monotonic characteristics of the line units the algorithm need only make a basic observation. If any of the A values for the calculated piecewise-linear functions are negative, the unit is non-monotonic. Otherwise, the unit can be assumed to be monotonic.
The generated values for the units will likely look something like what follows:
|Table 5. Nuke 1 Computed Coefficients |
|Nuke 1 | | | | |
|(MW) Range |A |B |C |I/O |
|100-125 |0.008 |7.2 |450 |1250 |
|125-150 |0.008 |7.2 |450 |1475 |
|150-175 |0.008 |7.2 |450 |1710 |
|175-195 |0.0075 |7.2875 |450 |1955 |
|195-200 |0.01 |6.8 |450 |2156.25 |
The user specifies in the Excel file within the unit commitment page whether or not the unit is available for dispatch. This determination is made through a specific status code in a specific column. The unit commitment page will contain a check to make sure that all generators minimum up and down times are not violated.
After developing the piecewise-linear equations, the algorithm performs a standard lambda search with the monotonic generators that are available (user specified within the unit commitment page). This part of program populates a table for the lowest cost dispatch among the monotonic units at each possible load value (a definable step, default = 1MW). The load value extremes (minimum and maximum for the system) are determined using the sum of the combined generator minimums and maximums. Calculations outside these levels are ignored.
After the monotonic unit table is populated, the algorithm moves on to the non-monotonic power generators. The algorithm uses a seventh-order curve to model the non-monatomic generators. A linear regression is used to get a solvable third-order curve that represents the seventh-order curve. From there the algorithm uses the solver function in Excel to solve the third-order curves for the non-monotonic generators.
At this point the program takes the non-monotonic solutions and the combined monotonic unit table and determines the minimum cost solution for the given load. This calculation runs through the use of a number of loops. Each possible combination of loads from the tables will be checked. If the load value for the combination is not equal to the load specified by the user, no further calculations are completed and the program will immediately move onto the next combination. In the event that the load value is equal to that specified by the user, the algorithm takes the resulting cost value and compares it to the lowest previously calculated value. If this new value is larger, it is not retained and the program continues. If it is smaller than the previous value, it is retained for further comparisons and the program continues.
After all possible combinations have are tested, the smallest cost value (and its resulting load dispatch) are output to the user. Additionally, a complete list of all the minimum cost dispatches are retained for use by the user as an output. Any load dispatches that were not cost optimizing are not included because of the unreasonable length that such a document would have. Figure 11 on the following page describes in more detail how the program flows.
[pic]
Figure 11: Algorithm Flowchart
III. Calling Tree
ALL_TOTAL_RUN
Other_Data_Load
Sheet_Wash
Sheet_Hide
Get_Filename
Input_Data_File
Data_File_To_Input_Page
Data_Check
Empty_All
Gen_Data_Load
Input_To_Commitment
Commitment_Text_Load
Input_to_Gen_Limits
Gen_Limits_Load
Week_Load_Data_Input
Error_generator
Determine_Chars *
Check_For_NMU
Populate_NMU_Tables
Master_NMU
* Executed if no errors exist
IV. Subroutines or Modules
ALL_TOTAL_RUN()
Description: ALL_TOTAL_RUN() is the main module which calls all the other smaller modules. It is the very last module contained in the Visual Basic editor.
Other_Data_Load()
Description: Other_Data_Load() accesses the “Display Sheets” portion of the “Input” worksheet. It gathers user input and sets the following global variables based on if the user wants to view the tables: Disp_Curve, Disp_MU_Lambda, Disp_NMU_Lambda, Disp_Master_MU, Disp_Consol_NMU, and reload. If the user chooses to “TRUE” for either Disp_Master_MU or Disp_Consol_NMU, the user is prompted to enter which hour they would like the tables displayed for (1-168).
Sheet_Wash()
Description: Sheet_Wash() is called in order to erase old data from the last run from certain sheets in the workbook.
Sheet_Hide()
Description: Sheet_Hide() temporarily hides a number of sheets which are then chosen by the user if they wish to view them or not after the program runs. The sheets can be viewed by choosing “TRUE” in the display sheets cells on the “Input” worksheet.
Get_Filename()
Description: Get_Filename() prompts the for the location of the input file to use. The location is then loaded into a string so that it is accessible by the program.
Input_Data_File()
Description: Input_Data_File() opens the input file from the specified path from the Get_Filename module. It loads the data into the data_file array and then closes the input file.
Data_File_To_Input_Page()
Description: Data_File_To_Input_Page() prints the data from the data_file array onto the left side of the “Input” page. This data includes all the necessary data which was contained in the input file.
Data_Check()
Description: Data_Check() provides some preliminary input data verification checks. The following conditions are verified:
• No two units have the same name
• Missing fuel price, I/O value, MW and IHR points
• MW points must be integer values
In the event of an error, the global variables, error_list, error_row, error_col, and is_error are updated, the program stops, and an error is displayed on the “Errors” worksheet.
V. Global Variables
The following is a list of the global variables used throughout the software
Disp_Curve
Data Type: Boolean
Description: Disp_Curve is set by the user if they wish for the curve characteristics (“ABC Checker” worksheet) to be displayed when the program is run.
Disp_MU_Lambda
Data Type: Boolean
Description: Disp_MU_Lambda is set by the user if they wish for the MU Lambda table to be displayed when the program is run.
Disp_NMU_Lambda
Data Type: Boolean
Description: Disp_NMU_Lambda is set by the user if they wish for the NMU Lambda table to be displayed when the program is run.
Disp_Master_MU
Data Type: Boolean
Description: Disp_Master_MU is set by the user if they wish for the Master MU table to be displayed when the program is run.
Disp_Consol_NMU
Data Type: Boolean
Description: Disp_Consol_NMU is set by the user if they wish for the consolidated NMU table to be displayed. This consolidated NMU table is basically the master NMU table.
VI. Custom Data Structures
Type hourly
Description: Stores commitment codes and load values for each of the 168 hours.
.commitment_text(170)
Data Type: String array
Description: Stores commitment code for each hour of the 168 total hours
.load_to_solve(170)
Data Type: Integer array
Description: Stores the load value for the each hour of the 168 total hours
Type Generator
Description: Stores generator data for a single unit
.name
Data Type: String
Description: Stores the name of the generator.
.gen_min(170)
Data Type: Integer array
Description: Stores the generator’s minimum generation value for each hour over a 168-hour period.
.gen_max(170)
Data Type: Integer array
Description: Stores the generator’s maximum generation value for each hour over a 168-hour period.
.nmu
Data Type: Boolean
Description: True if generator exhibits non-monotonic characteristics
.range_min(12)
Data Type: Integer array
Description: Stores the low end of each range of operation.
.range_max(12)
Data Type: Integer array
Description: Stores the high end of each range of operation.
_______________________________________________________________
Resources and Schedules
Knowledge of estimated resource requirements and the project schedule are essential in order to properly evaluate the design report. This section will describe the original and revised estimates for the project’s resources requirements and schedules.
1 Resources Requirements
This section contains the original and revised estimates of personnel resource requirements, other resource requirements, and total financial requirements for the project.
1 Estimated Personnel Effort Requirements
To achieve the best personnel effort estimate, the project timeline has been broken up by tasks which refer to the tasks listed in the project schedule.
These tasks include:
▪ Task 1: Project Definition
▪ Task 2: Technology Considerations and Selection
▪ Task 3: End-Product Design
▪ Task 4: End-Product Prototype Implementation
▪ Task 5: End-Product Testing
▪ Task 6: End-Product Documentation
▪ Task 7: End-Product Demonstration
▪ Task 8: Project Reporting
|Table 6. Original Personnel Effort Resource Requirements |
| |
| |
|Item |Team Hours |Other Hours |Cost |
|Bound Project Plan |0 |0 |$20.00 |
|Printing of Project Poster |0 |0 |$62.00 |
|Bound Design Report |0 |0 |$20.00 |
|Total |0 |0 |$102.00 |
Table 9 shows that material costs will likely result in a savings of $22.24 from previous estimates. It is assumed that the bound design report will require approximately the same cost as the bound project plan.
|Table 9: Revised Other Resource Requirements |
|Item |Team Hours |Other Hours |Cost |
|Bound Project Plan | 0 |0 |$ 8.88 |
|Printing of Project Poster | 12 |0 |$ 62.00 |
|Bound Design Report | 0 |0 |$ 8.88 |
|Revised Total | 12 |0 |$ 79.76 |
2 Estimated Total Financial Requirements
Total financial requirements for the project are divided between material costs and labor costs, as shown in Table 10. Material costs included the costs the printing of deliverables. No labor costs from the team members were included in material costs.
|Table 10: Original Project Cost Estimates |
|Item |W/O Labor |With Labor |
|Bound Project Plan (2) | $ 20.00 | $ 20.00 |
|Poster | $ 62.00 | $ 62.00 |
|Bound Design Report (2) | $ 20.00 | $ 20.00 |
|Bound Final Report (2) | $ 20.00 | $ 20.00 |
|Travel to MidAmerican (3) | $ 157.80 | $ 157.80 |
|Subtotal: | $ 279.80 | $ 279.80 |
|Labor at $10 per hour: | | |
| Ellis, Matthew | | $1,950.00 |
| Fernandez, Nora | | $1,950.00 |
| Hamilton, Jeremy | | $1,950.00 |
| Walter, Robert | | $1,950.00 |
|Subtotal: |$ 0.00 | $7,800.00 |
|Total | $ 279.80 | $8,079.80 |
Table 11 displays the actual printing costs for materials along with revised labor cost estimates. At $10 per hour labor costs, the total projected project cost is $ 8,477.56.
|Table 11: Revised Project Cost Estimates |
|Item |W/O Labor |With Labor |
|Bound Project Plan (2) | $ 8.88 | $ 8.88 |
|Poster | $ 62.00 | $ 182.00 |
|Bound Design Report (2) | $ 8.88 | $ 8.88 |
|Bound Final Report (2) | $ 20.00 | $ 20.00 |
|Travel to MidAmerican (3) | $ 157.80 | $ 157.80 |
|Subtotal: | $ 257.56 | $ 377.56 |
|Labor at $10 per hour: | | |
| Ellis, Matthew | | $2,040.00 |
| Fernandez, Nora | | $2,010.00 |
| Hamilton, Jeremy | | $2,020.00 |
| Walter, Robert | | $2,030.00 |
|Subtotal: |$ 0.00 | $8,100.00 |
|Total | $ 257.56 | $8,477.56 |
2 Schedules
This section describes the schedule for the duration of the project. Figure 12 displays the project team’s original Gantt chart for the project. Figure 13 on the following page is a revised Gantt chart showing various tasks within the project and time commitment estimates for each task.
1 Revised Schedule
Figure 13 documents the revisions the project team made to the original schedule (Figure 12) of the project. The reasons for each change are listed below.
Task#1: Project Definition
The following are changes made to Task #1.
▪ Because of the overall complexity of the initial project, the project team required additional time to review and determine what the best approach is to accomplish the client’s requirements.
▪ Throughout the initial project review, the project team also decided to begin making lists and comments on the functions of each subroutine and also the name and purpose of each data variable. These lists will later be used for a programmer’s guide. The original scope did not have time allotted for this; therefore, additional time was allotted.
Task #2: Technology Consideration
The following are changes made to Task #2.
Due to client requirements and the prior teams’ decisions there were fewer technologies that the project team had to consider. Because of these fewer considerations, the allotted time was drastically shortened.
Task #3: End-Product Design
The following are changes made to Task #3.
▪ More time was allotted to the design process, because many modifications cannot be designed without actually implementing and testing them in Microsoft Excel or Visual Basic.
▪ The subtasks were changed to match the client’s emphasis on a user friendly program rather than computation speed.
▪ The design documentation dates changed to reflect that the entire design process will be reported.
Task #4: Prototype Implementation
The following are changes made to Task #4.
▪ Because the only way to design many of the modifications is through actually implementation, much of the time for this task has switched to Task #3.
▪ The main goal for this task will be in developing a main and secondary menu.
Task #5: End-Product Testing
The following are changes made to Task #5.
▪ After client review of the initial project it was brought to the attention of the project team that many bugs currently exist. The additional time is added to detect and fix all initial bugs as well as any new bugs from the project team’s software modifications.
▪ The testing documentation dates changed to reflect that the entire testing process will be reported.
Task #6: End-Product Documentation
The following are changes made to Task #6.
▪ No changes were made to Task #6.
▪ The programmer’s manual is now part of this task and its initial reporting is part of Task #1. No additional time is necessary.
Task #7: End-Product Demonstration
No changes were made to Task #7.
Task #8: Project Reporting
The following are changes made to Task #8.
▪ The only change to the project reporting was in the dates for the project poster. This is due to a change in the deliverable schedule.
▪ The same amount of time is allotted for the project poster.
[pic]
[pic]
2 Deliverables Schedule
Figures 14 and 15 are the original and updated deliverables schedules, respectively, showing the date of all deliverables for the duration of the project. All deliverables to date have been delivered at the time designated in the schedule. The only revision is the change of deliverable date for the project poster. This decision was made by Iowa State University’s Senior Design faculty as a means to give the project team additional time for the project plan, design report, and project planning.
3 Weekly Schedule – Spring 2006
A tentative weekly schedule was developed for the spring semester of 2006. The schedule is listed below.
January 9 - January 15
The following are project tasks to be completed the week of January 9-15.
▪ Creation of a Graphical User Interface (GUI) including a main and secondary menu in Microsoft Excel using Visual Basic Macros. This week’s focus will on the actual functionality of the menu, rather than the aesthetics. For further details on the GUI, see Sections 3.1.1.3 and 3.2.3.
▪ Write macro to compute up and down times for unit commitment table.
January 16 - January 22
The following are project tasks to be completed the week of January 16-22.
▪ Continue creation of functional prototype of GUI.
▪ Write independent Visual Basic macro to reset the unit commitment worksheet to the default.
▪ Modify unit commitment worksheet to match client specifications as defined in Sections 3.1.1.1 and 3.2.1.
January 23 - January 29
The following are project tasks to be completed the week of January 23-29.
▪ Add a visually appealing overlay to the main and secondary menus (GUI).
▪ Modify the program’s output to match the client specifications as defined in Sections 3.1.1.2 and 3.2.2.
▪ Write an independent macro to set a unit commitment pattern and generator constraints to default, after they produce a user satisfying output
January 30 - February 5
The following are project tasks to be completed the week of January 30-February 5.
▪ Send the prototype of the main and secondary menus to MidAmerican Energy for remarks and criticism.
▪ Modify the program’s output to match the client specifications as defined in Sections 3.1.1.2 and 3.2.2
▪ Begin writing secondary program to run for a user defined range of hours
February 6 - February 12
The following are project tasks to be completed the week of February 6-12.
▪ Make aesthetic and usability changes to the menus corresponding with MidAmerican Energy’s remarks
▪ Continue writing secondary program to run for a user defined range of hours
February 13 - February 19
The following are project tasks to be completed the week of February 13-19.
▪ Development of the project poster to specifications laid out by the Iowa State University Senior Design faculty
▪ Continue writing secondary program to run for a user defined range of hours
▪ Project team testing for the main program, concentrating on data inputting
February 20 - February 26
The following are project tasks to be completed the week of February 20-26.
▪ Final modifications of the project poster to specifications as defined by the Iowa State University Senior Design faculty
▪ Final modifications of the secondary program
▪ Project team testing for the main program, concentrating on data inputting
February 27- March 5
The following are project tasks to be completed the week of February 27-March 5.
▪ Project team testing for the main program, concentration on outputting
▪ Project team testing for the secondary program
March 6 - March 12
The following are project tasks to be completed the week of March 6-12.
▪ Final project team testing to remove any additional bugs
▪ Deliver program to client for testing
March 13 - March 19
The following are project tasks to be completed the week of March 13-19.
▪ Spring Break
March 20 – March 26
The following are project tasks to be completed the week of March 20-26.
▪ Further necessary modifications to program as determined by client testing
▪ Write programmer’s guide to specifications laid out in Sections 3.1.1.5 and 3.2.5
▪ Write user manual detailing operation of program
March 27 – April 2
The following are project tasks to be completed the week of March 27-April 2.
▪ Further necessary modifications to program as determined by client testing
▪ Write programmer’s guide to specifications as defined in Sections 3.1.1.5 and 3.2.5
▪ User manual detailing operation of program
▪ Begin making miscellaneous modifications and additions as defined in Sections 3.1.1.6 and 3.2.6. The project team will perform a full range of tests after every miscellaneous modification or additions is made
April 3 – April 9
The following are project tasks to be completed the week of April 3-9.
▪ Further necessary modifications to program as determined by client testing
▪ Write programmer’s guide to specifications as defined in Sections 3.1.1.5 and 3.2.5
▪ User manual detailing operation of program
▪ Prepare industrial presentation
▪ Begin making miscellaneous modifications and additions as defined in Sections 3.1.1.6 and 3.2.6. The project team will perform a full range of tests after every miscellaneous modification or additions is made
April 10 - April 16
The following are project tasks to be completed the week of April 10-16.
▪ Begin writing the project’s final report
▪ Practice presentation
▪ Begin making miscellaneous modifications and additions as defined in Sections 3.1.1.6 and 3.2.6. The project team will perform a full range of tests after every miscellaneous modification or additions is made
April 17 – April 23
The following are project tasks to be completed the week of April 17-23.
▪ Industrial review - week before final report.
April 24 - April 30
The following are project tasks to be completed the week of April 24-30.
▪ Final report describing success of project
Closure Materials
This section provides contact information and a closing summary.
1 Project Team Information
This section provides contact information for the client contacts, faculty advisors and team members.
1 Client Information:
Alan Oneal
MidAmerican Energy Company
666 Grand Avenue
P.O. Box 657
Des Moines, IA 50303-0657
Office Phone: (515) 252-6449
Email: aroneal@
11. Faculty Advisor:
Dr. John Lamont
324 Town Engineering
Ames, IA 50011-3060
Office Phone: (515) 294-3600
Fax: (515) 294-6760
Email: jwlamont@iastate.edu
12. Student Information:
Matthew Ellis Jeremy Hamilton
Electrical Engineering Electrical Engineering
3304 West St. 29 D Schilletter Village
Ames, IA 50014 Ames, IA 50010
(763) 350-3593 (515) 460-7813
mjellis@iastate.edu jerbud@iastate.edu
Noraima Fernandez Robert Walter
Electrical Engineering Electrical Engineering
1006 S. Dayton #54 3824 Tripp St. #214
Ames, IA 50010 Ames, IA 50014
(515) 441-1447 (515) 971-2597
fernandl@iastate.edu rmwalter@iastate.edu
2 Closing Summary
The project will build upon a software application that will seek to produce the most economical power distribution, with as quick of solution times as possible, between monotonically and non-monotonically increasing generators. The algorithm will be able to handle more generator combinations and will be combined with a more aesthetically pleasing user interface to produce a more usable application. This program will be written in Microsoft Excel using Visual Basic macros and will meet the many outlined requirements. MidAmerican Energy can expect to benefit from this project through a reduction in fuel costs due to improved generator distribution.
-----------------------
Figure 9b: Main Menu
Figure 9a: Main Menu
Figure 8: Menu Structure Flowchart
Figure 12: Original Gantt Chart
Figure 13: Revised Gantt Chart
Figure 15: Updated Deliverables Schedule
Figure 14: Original Deliverables Schedule
Combined Dispatch
NMU
Dispatch
MU
Dispatch
Figure 2. Non-monotonic Incremental Cost Curve
Figure 1. Monotonic Incremental Cost Curve
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.