EPA-600/R-94-017
January 1994
STATE ACID RAIN RESEARCH AND SCREENING SYSTEM
VERSION 1.0 USER'S MANUAL
by
Christopher A. Bogart
Steven J. Epstein
K. Stephen Piper
Alan S. Taylor
RCG/Hagler, Bailly, Inc.
P.O. Drawer O
Boulder, CO 80306
EPA Contract #68-D9-0142
Work Assignments 3-4 Through 3-8
EPA Project Officer: Christopher D. Geron
Air and Energy Engineering Research Laboratory
Research Triangle Park, NC 27711
Prepared for
U.S. ENVIRONMENTAL PROTECTION AGENCY
Office of Research and Development
Washington, DC 20460
-------
NOTICE
This document lias been reviewed in accordance with
U.S. Environmental Protection Agency policy and
approved for publication. Mention of trade names
or commercial products does not constitute endorse-
ment or recommendation for use.
-------
ABSTRACT
The Environmental Protection Agency has overseen the development of a compliance
planning system that has been delivered to over 40 state regulatory commissions. STARRSS
(the STate Acid Rain Research and Screening System) is a PC-based integrated information
and modelling system that was developed to assist commissions and utilities in their
evaluation of acid rain compliance plans. STARRSS gives analysts the ability to:
Evaluate the costs and risks of specific compliance plans
»¦ Develop compliance plans through one of three STARRSS optimization
methodologies.
As a decision support tool, STARRSS uses a multiple-scenario, risk-assessment approach.
The model can use three different user-specified forecasts for most input data items.
Through a Monte Carlo process, STARRSS simulates hundreds of scenarios for a particular
compliance strategy, selecting one of these three values during each scenario, based on user-
specified probabilities. Therefore, a strategy is exposed to the full uncertainty of future
events, such as varying allowance prices, fuel prices, construction costs, or generating unit
operating characteristics. These multiple simulations yield a distribution of cost estimates
that represent the range of possible costs for a compliance strategy. Working with this
distribution, the user can see the level of economic or business risk inherent in a particular
compliance strategy.
Although STARRSS ranks the plans based on the expected value of compliance costs, this is
not meant to imply that the least-cost plan is the best. The risks that STARRSS quantifies
must also be taken into consideration. The level of risk that a utility is willing to bear is a
major factor in the decision to adopt an emissions reduction option. The central objective of
the STARRSS system is not to identify the best compliance strategy for decision-makers, but
to provide a decision-support screening tool that will help organizations identify good
strategies (low cost, combined with acceptable levels of risk) that deserve further detailed
analysis.
STARRSS requires databases representing utility systems for use as input files. To facilitate
the process of database development and refinement, RCG/Hagler Bailly has developed
databases to model all of the major utilities affected under the CAAA. These databases
contain publicly-available information for all of the generating unit data and allowance
allocation data required of STARRSS. Relevant databases have been included with each
STARRSS delivery to serve as a starting point for further database development. State
public utility commissions have received databases for all utilities within their jurisdiction,
including multi-state holding companies and power pools.
i i i
-------
TABLE OF CONTENTS
1.0 INTRODUCTION 1
1.1 HOW TO USE THIS MANUAL 4
2.0 HOW TO INSTALL STARRSS 7
2.1 SYSTEM REQUIREMENTS 7
2.2 THE STARRSS DELIVERY 9
2.3 INSTALLATION (HARD DISK SYSTEM) 10
2.4 INSTALLATION (FLOPPY DISK SYSTEM) 11
2.5 RUNNING STARRSS 12
3.0 GETTING STARTED 13
3.1 MULTIPLE FORECASTS IN STARRSS 18
3.2 THE PROBABILITY POINTERS SCREEN 20
3.3 THE DATA ENTRY PROCESS 22
3.4 THE STARRSS MONTE CARLO APPROACH 28
4.0 FILES 34
4.1 LOADING A DATABASE 35
4.2 SAVING A DATABASE 37
4.3 TEMPORARILY EXIT TO DOS 37
4.4 MEMORY AVAILABLE 37
4.5 QUITTING FROM STARRSS ; 39
\Vf v
-------
TABLE OF CONTENTS
5.0 INPUT DATA: SYSTEM-LEVEL INFO 41
5.1 BASE CASE CONSERVATION/RENEWABLES 43
5.2 INCREMENTAL CONSERVATION/RENEWABLES 47
5.3 MARGINAL ENERGY AND CAPACITY COSTS 51
5.4 ALLOWANCE PURCHASE AND SALE PRICES 53
5.5 ALLOWANCE PARAMETERS 56
5.6 TAX RATE, ESCALATION RATES, AND COST OF CAPITAL . . 59
5.7 PROBABILITIES ASSOCIATED WITH FORECASTS 63
6.0 INPUT DATA: UNIT-LEVEL INFO 66
6.1 DISPLAY/EDIT AFFECTED UNITS 68
6.2 AFFECTED UNIT OPERATING FACTORS 72
6.3 EDIT/DEFINE COMPLIANCE OPTIONS 82
6.4 DISPLAY COMPLIANCE OPTION NAMES 96
6.5 FUEL INPUTS 98
6.6 GENERATING UNIT REDUNDANCE 101
6.7 COMPLIANCE OPTION LINKING 104
6.8 VIEW COMPLIANCE OPTIONS 107
7.0 HOW TO EXECUTE STARRSS 108
7.1 EXECUTION PARAMETERS SCREEN 109
7.2 REPORTING PARAMETERS SCREENS 112
7.3 EVALUATE USER STRATEGIES 116
7.4 DEVELOP STARRSS STRATEGIES (OPTIMIZATION) 122
vi
-------
TABLE OF CONTENTS
8.0 REPORTS, GRAPHS, AND AUXILIARY FILES 128
8.1 REPORTS 130
8.1.1 Reporting Features 131
8.1.2 Warnings Screen 133
8.1.3 Compliance Strategies Total Cost Report 133
8.1.4 Compliance Strategies Detail Report 136
8.1.5 Compliance Option Report bv Strategy 137
8.1.6 Compliance Option Report bv Unit 139
8.1.7 Compliance Option Ranking Report 140
8.1.8 Compliance Strategies Unitized Cost Report 141
8.1.9 Input Summaries 142
8.2 GRAPHS 150
8.2.1 Graphing Features 150
8.2.2 Total Cost of Compliance Strategies 154
8.2.3 Average Unitized Cost ($/ton) 154
8.2.4 Marginal Unitized Cost (S/ton) 154
8.2.5 Purchased Allowances 154
8.2.6 Total Cost of Purchased Allowances 154
8.3 AUXILIARY FILES 155
8.3.1 Print Files 155
8.3.2 Detail Files 155
8.3.3 Raw Data Files 155
9.0 HOW STARRSS WORKS 157
9.1 EVALUATION CALCULATIONS 159
9.1.1 Calculation of Target Reduction 162
9.1.2 Calculation of Costs of Individual Compliance Options 164
9.1.3 Calculation of Impacts of Individual Compliance Options 175
9.1.4 Calculation of Allowance Transactions 180
9.1.5 Calculation of Total Cost of Compliance 180
9.1.6 Calculation of Unitized Costs 181
vi i
-------
TABLE OF CONTENTS
9.2 FULL OPTIMIZATION 182
9.3 HEURISTIC ALGORITHMS 183
9.3.1 Heuristic #1: Multiple Scenario Hill Climbing 184
9.3.2 Heuristic #2: Varying Prioritization 185
10.0 CUSTOMIZED DATABASES 193
10.1 ILLUSTRATIVE DATA 194
10.2 PUBLISHED HISTORICAL INFORMATION 195
10.2.1 Unit Information 195
10.2.2 Fuel Information 197
10.2.3 Research Recommendations 201
10.3 TABLES: DELIVERED DATABASE INFORMATION 202
11.0 DESCRIPTIONS OF COMPLIANCE OPTIONS 204
11.1 POLLUTION CONTROL TECHNOLOGIES 205
11.1.1 Precombustion Coal Cleaning 206
11.1.2 Combustion SO, Reduction Technologies 207
11.1.3 Flue Gas Desulfurization Technologies 209
11.1.4 Reagent Additives 226
11.2 FUEL SWITCHING COMPLIANCE OPTIONS 227
11.3 CONSERVATION COMPLIANCE OPTIONS 229
11.4 OTHER COMPLIANCE ACTIVITY 230
vi i i
-------
TABLE OF CONTENTS
APPENDICES
APPENDIX A: STARRSS Data Requirements A-l
APPENDIX B: STARRSS Warning Messages B-l
APPENDIX C: Troubleshooting C-l
APPENDIX D: Unit Conversions D-l
APPENDIX E: References E-l
FIGURES
Figure Page
Figure 3-1. STARRSS organizational chart 16
Figure 3-2. Zones for forecast selection 29
Figure 8-1. Graph comparing two compliance strategies* 128, 153
* This figure is repeated for the reader's convenience.
ix
-------
TABLES
Table Page
Table 2-1. Files on delivery diskette 9
Table 3-1. Rules of the road 13
Table 3-2. Main Menu 14
Table 3-3. Probabilities Associated with Forecasts screen 20
Table 3-4. System-Level Info submenu .22
Table 3-5. Allowance Purchase Prices screen 23
Table 3-6. Forecasts for data items 30
Table 3-7. Probabilities for forecasts 30
Table 3-8. Selection of values for iteration #1 31
Table 3-9. Selection of values for iteration #2 32
Table 4-1. Main Menu" 34
Table 4-2. Load screen 35
Table 5-1. System-Level Info submenu 41
Table 5-2. Base Case Conservation/Renewables screen 43
Table 5-3. Incremental Conservation/Renewables screen 47
Table 5-4. Marginal Energy Costs screen 51
Table 5-5. Allowance Purchase Prices screen 53
Table 5-6. Allowance Parameters screen 56
* Several tables are repeated for the reader's convenience; e.g., Tables 3-2 and 4-1.
x
-------
TABLES
Table Page
Table 8-16. Graph of Compliance Statistics submenu 150
Table 8-17. Graph of Compliance Statistics - strategies pop-up
menu 151
Table 8-18. Detailed Information Report (a portion) 156
Table 9-1. Calculation of the present value of increased fixed
O&M expenses 169
Table 10-1. STARRSS data items containing illustrative
values 194
Table 10-2. Holding company and operating utility systems included
in STARRSS delivered databases 202
Table 10-3. Units included in STARRSS delivered databases 202
Table 10-4. Phase I allowance calculations for units in delivered
databases 203
Table 10-5. Phase II allowance calculations for units in delivered
databases 203
Table 10-6. Unite in delivered databases for which NADB was used to
calculate capacity factors 203
Table 10-7. Jointly-owned units appearing in delivered databases 203
Table 11-1. Furnace sorbent injection strengths and weaknesses 209
Table 11-2. Furnace sorbent injection cost ranges 209
Table 11-3. Parameters used to develop FGD cost estimates 210
Table 11-4. Conventional limestone strengths and weaknesses 211
Table 11-5. Conventional limestone cost ranges 211
xiii
-------
TABLES
Table Page
Table 11-6. Limestone forced oxidation strengths and weaknesses 212
Table 11-7. Limestone forced oxidation cost ranges 212
Table 11-8. Limestone forced oxidation/by-product strengths and
weaknesses 213
Table 11-9. LSFO/by-product cost ranges 213
Table 11-10. Saarberg-Hoelter strengths and weaknesses 214
Table 11-11. Saarberg-Hoelter cost ranges 214
Table 11-12. Chiyoda-121 strengths and weaknesses 215
Table 11-13. Chiyoda-121 cost ranges 215
Table 11-14. Pure Air advanced FGD strengths and weaknesses 216
Table 11-15. Pure Air advanced FGD cost ranges 216
Table 11-16. Conventional lime strengths and weaknesses 217
Table 11-17. Conventional lime cost ranges 217
Table 11-18. Magnesium enhanced lime strengths and weaknesses 218
Table 11-19. Magnesium enhanced lime cost ranges 218
Table 11-20. Lime spray drying strengths and weaknesses 219
Table 11-21. Lime spray drying cost ranges 219
Table 11-22. Lurgi circulating fluidized bed strengths and weaknesses 220
Table 11-23. Lurgi circulating fluidized bed cost ranges 221
Table 11-24. Soda ash strengths and weaknesses 221
xiv
-------
1.0 INTRODUCTION
The acid rain provisions included in Title IV of the 1990 Clean Air Act Amendments (CAAA)
mandate that many electric utilities substantially curtail their sulfur dioxide (S02) emissions by
1995 ~ with even more stringent environmental limits taking effect in the year 2000.1 These
affected utilities must file compliance plans with the U.S. EPA and state public utility
commissions to indicate how they intend to reduce their S02 emissions to allowable levels. As
they review these compliance plans, state regulators will play a critical role in determining the
success of the CAAA. Whether they are asked to formally pre-approve compliance plans or
not, commissions will have considerable influence over utilities' compliance decisions.
Therefore, in determining what constitutes a "good" compliance plan, commissions will have
to address the following questions:
~ Is the utility's preferred plan the least-cost solution?
* What other compliance strategies should the utility be considering?
~ Are the utility's assumptions about control costs reasonable?
~ Has the utility performed a thorough analysis of how changes in technology costs
and fuel/allowance market prices may affect different compliance strategies?
~ How risky is the utility's preferred plan?
~ Can this risk be mitigated, and how much would such mitigation cost?
~ Should the utility be a buyer or a seller in the SOz allowance market — and to
what extent?
~ What is the value of flexibility (in terms of being able to change strategies if
future circumstances warrant)?
~ What is the value of implementing a diverse set of compliance options versus a
strategy which focuses on a single compliance option?
STARRSS (the STate Acid Rain Research and Screening System) is an integrated database and
modelling system that is designed to assist the U.S. EPA and state regulatory commissions in
answering these questions.
1 An excellent presentation of the details and issues surrounding Title IV of the CAAA can be found in
reference 1 (Appendix E).
1
-------
STARRSS is a screening tool that is based on scenario analysis and risk management
techniques. Designed to ran quickly on a personal computer (an IBM PC AT or IBM-
compatible PC with an 80286 processor or better), STARRSS focuses on the comprehensive
analysis of many compliance strategies. Of particular interest is how these strategies are
affected by uncertainty and market volatility. Therefore, as a screening system, STARRSS has
been designed for breadth rather than depth. STARRSS was developed to identify compliance
strategies that deserve further, more-detailed analysis.
Considering the immediacy of the needs for such a system, (Phase I compliance plans are due
in 1993), the development schedule for STARRSS has been divided into two stages. Version
1 is a simplified version that was made available in mid-1992. A Version 2 of the program will
incorporate more sophisticated algorithms such as full production cost modelling and specific
year-by-year analysis capabilities.
Version 1 STARRSS offers users three distinct capabilities:
1) The ability to research or verify the costs and operating impacts for compliance
options at affected generating units;
2) The ability to evaluate and compare the costs and risks associated with specific
compliance strategies; and
3) The ability to develop, evaluate and compare a set of suggested compliance
strategies that are generated by an "optimization" process.
The term "optimization" is used loosely in the context of STARRSS. True compliance planning
optimization would entail much greater data requirements and computing power than is needed
for the STARRSS level of screening analysis. In addition, an optimization algorithm will only
determine the "best" strategy based on pre-specified input assumptions. Considering the
uncertainties that surround compliance planning, no one strategy can be declared "optimal."
Also, since political and regulatory pressures can influence the adoption of various compliance
strategies, true optimization based on one set of economic assumptions would be myopic.
2
-------
TERMINOLOGY
An affected unit refers to any of the almost 2000 generating units that will be given
emissions allowances during Phase I or Phase II of the acid rain program. Many units in
the country do not emit S02 or are too small to be targeted by the CAAA and are
therefore "unaffected units."
A compliance option is an individual course of action that the owner of an affected unit
can take (e.g., scrubbing or fuel-switching at a particular unit, pursuing a qualified
conservation program, purchasing allowances).
A compliance strategy is a collection of compliance options that will bring the utility
into compliance with the CAAA regulations.
The STARRSS optimization approach selects a set of top plans from a list of potentially billions
of compliance strategies. STARRSS then evaluates these top plans under a range of economic
and operational uncertainties (such as changing fuel prices, allowance prices, and generating unit
operations). Instead of developing a deterministic value for the total cost of a particular
compliance strategy (i.e., one in which all input assumptions are fixed), STARRSS presents a
distribution of compliance costs for each strategy and an associated expected value. The
expected value is the average of the cost distribution; it provides a comprehensive consideration
of all of the different possible economic outcomes and their likelihood of occurring. The cost
distribution also provides the user with an estimation of the level of risk associated with a
strategy.
For example, a STARRSS analysis of Strategy A may have an expected value of $2 billion,
plus or minus $0.5 billion. In other words, considering potential fluctuations in the fuel and
allowance markets and other parameters, Strategy A is likely to cost between $1.5 billion and
$2.5 billion. Strategy B has a cost of $2.1 billion, plus or minus $0.1 billion. If one simply
chose the optimal strategy based on a comparison of the plans' expected value for compliance
costs, then one would pick Strategy A as the best plan. However, Strategy B is less riskv.
because has less variance in its total costs. A utility or state commission may want to choose
Strategy B, realizing that the likely economic exposure is capped at $2.2 billion, whereas there
may be a substantial probability that Strategy A could cost as much as $2.5 billion.
STARRSS give users the flexibility to compare the likely outcome for a variety of strategies.
3
-------
STARRSS* PRIMARY OBJECTIVE
The central objective of the STARRSS system is not to identify the best
compliance strategy for decision-makers, but to provide a decision-support
screening tool that will help organizations identify good strategies (i.e., low cost,
combined with acceptable levels of risk) that deserve further detailed analysis.
A Word of Caution
Compliance planning is a very complex task. Although every effort has been made to make
STARRSS as "user-friendly" as possible, the system is rather data-intensive, by necessity.
Compliance planning requires a great deal of information. However, while experimenting and
becoming acquainted with the system, the user might want to define compliance options with
just a few pieces of information. Specifically, the user might want to defer the entering of
multiple-forecast estimates (High, Medium, and Low) for any data items; instead, the user
should only input a Medium estimate at first.
1.1 HOW TO USE THIS MANUAL
This STARRSS User's Manual is organized in the following fashion:
Chapter 2 discusses the Installation of the system.
Chapter 3 helps the user in "Getting Started" and understanding STARRSS. This section
discusses keyboard conventions (i.e., how to move around the STARRSS menu system,
how to work within the STARRSS screens, etc.) as well as the program's multiple-
scenario Monte Carlo approach to compliance planning.
Chapter 4 discusses the basics of using STARRSS databases (loading, saving, quitting
from STARRSS, etc.).
Chapters 5 and 6 describe all of the STARRSS inputs on an input screen by input screen
basis. Chapter 5 discusses system-level information, and Chapter 6 describes unit-level
information.
Chapter 7 shows how to execute the program.
4
-------
Chapter 8 shows the reporting and graphical features in STARRSS. It also discusses
various auxiliary files that can be produced during a STARRSS execution and exported
to other programs (e.g., Lotus 1-2-3, Harvard Graphics, SAS).
Chapter 9 explains how STARRSS woiks, describing how STARRSS uses the input data
and how the output results are calculated.
Chapter 10 discusses what is contained in the delivered databases. The references for
all information are clearly documented, as are any calculations that were performed to
generate input information. Chapter 10 includes a complete listing of all of the
'Illustrative" data values (such as forecasted allowance prices) that are in the database(s).
It is especially critical that the user change these values, because they have been input
into STARRSS merely to provide reasonable numbers while the user is learning how to
run the system. As is the case for all information in the delivered database(s), but
especially for these illustrative values, neither EPA norRCG/Hagler, Bailly recommend
the use of these numbere.
Chapter 11 provides a background presentation of the various compliance options that
are available to utilities, primarily focusing on a description of pollution control
technologies (their operating characteristics, ranges of costs, etc.). Chapter 11 does not
represent a balanced or exhaustive list of possible compliance options.
Recommended Reading for New STARRSS Users
RECOMMENDED READING
Ins fallen
Chapter 2 (Installing STARRSS)
Usen
Chapter 3 (Getting Started/Understanding STARRSS)
Chapter 4 (Files)
Chapter 9 (How STARRSS Woiks)
Chapter 7 (Execution)
5
-------
Chapter 2 (Installation) is an essential starting point for installing STARRSS onto a user's PC.
A basic level of understanding of PCs and DOS (IBM's Disk Operating System) is assumed.
If the user is not familiar with PCs, he or she should seek out the assistance of the system
operator.
Once STARRSS is installed, the user should at least read Chapter 3 (Getting
Started/Understanding STARRSS); the information contained in this chapter will provide the
user with the basic knowledge of how to move around the system and input/modify data values.
Chapter 4 will show the user how to load and save databases. The user cannot do anything in
STARRSS without loading a database fiist.
Chapter 9 (How STARRSS Works) provides the reader with an understanding of how
STARRSS calculates all of the costs and impacts of a compliance strategy. Chapter 7
(Execution) is required for understanding how to run the program.
STARRSS has been designed to be as "user-friendly" as possible. The system has an on-line
Help facility (accessed by pressing the F1 key). However, there is no substitute for reading Ml
of Chapters 5 and 6 (the chapters that describe input data) prior to invoking STARRSS.
Chapter 10 (Customized Databases) should be the next stop, since the user should be aware of
how the information in the delivered database(s) was developed. The dangers of using the
"illustrative" data cannot be overemphasized. As soon as the user feels comfortable with
STARRSS, he or she should change the illustrative data values to those that are endorsed by
his or her organization.
Chapter 11 (Compliance Option Descriptions) is a good resource for those who want a cursory
description of pollution control technologies and other compliance options. Particularly since
it identifies the strengths and weaknesses of different options, Chapter 11 can provide users with
a strong background in various qualitative aspects of compliance planning as well as the
quantitative issues.
Chapter 8 (Reports) is a convenient reference resource for explaining specific output report
elements.
Lastly, several appendices (for listing data requirements, explaining warning messages, trouble-
shooting) have been included in this manual.
In reading through various chapters, the user will encounter some redundant statements. This
redundancy is intentional. The STARRSS User's Manual has been organized to make each
section as self-contained as possible. This should make it easier to use as a reference resource.
6
-------
2.0 HOW TO INSTALL STARRSS
STARRSS is a PC-based modelling system. It is designed to run on an IBM or IBM-
compatible personal computer (PC) with an 80286 processor or better. STARRSS is executed
from the standard PC DOS operating system. If the user is not familiar with PCs and/or PC
DOS commands, he or she should seek the assistance of the computer system operator.
2.1 SYSTEM REQUIREMENTS
REQUIRED HARDWARE
IBM PC AT or IBM-compatible with an 80286 processor or better
500,000 bytes of available core memory (RAM)
Although most PCs have at least 512,000 bytes of RAM, often some of that core memory is
used by DOS and other computer system features (e.g., electronic mail, network
communications). These other features may have to be temporarily removed from the PC's
core memory in order to provide STARRSS with the necessary memory. This can be done
by copying and editing the PC's CONFIG.SYS file; the user should consult his or her
computer system manager for details.
Technically, STARRSS may not require the full 500,000 bytes of core memory. The
program itself is only 342,000 bytes, but it also needs room to pull in databases and perform
calculations. The amount of additional memory that these activities may require will depend
on the size of the database and the nature of the study. Therefore the 500,000-byte
requirement is not hard and fast. If the user's PC has less than 500,000 bytes of available
memory, the system's installation and testing can still proceed. However, the user should
remain aware of the potential for PC-memory-related problems and should monitor the
system's memory requirements. The details about this process can be found in Chapter 4
(see Section 4.4, Memory Available).
SPECIAL NOTE
Do not invoke STARRSS from within other programs (e.g., Windows, Lotus 1-2-3).
Because of the memory constraints, STARRSS should be invoked from DOS only.
7
-------
Expanded/Extended Memory
Some PCs have "expanded" or "extended" memory. STARRSS Version 1 cannot use either
one; however, STARRSS Version 2 will be able to use one or both of these capabilities.
RECOMMENDED HARDWARE
~
Hard disk1 (with at least 1 Megabvte of disk space reserved for STARRSS.
databases and output files)
>
Color monitor: not essential, but a significant plus when viewing 1
STARRSS' graphs 1
~ Math coprocessor: not essential for Version 1, but will make a
tremendous difference in execution speed with Version 2
1 Although the program can be run from a floppy disk, it will run much faster if It is run from a hard disk.
8
-------
2.2 THE STARRSS DELIVERY
STARRSS is provided on a single high-density (1.2 Megabyte) floppy diskette, found in the
front flap of this User's Manual. The diskette contains several files that are described in Table
2-1 below.
Table 2-1. Files on Deliveiy Diskette
Filename
Description j
INSTALL.BAT
Installation Batch File
STARRSS.EXE
The STARRSS program
I .SDB
Assorted Delivered Databases
.BGI
Assorted Graphics Interface Files
STARRSS.HLP
STARRSS Help File
FILES .LST
List of STARRSS Files
(delivery files, as well as those
produced during STARRSS execution)
9
-------
2.3 INSTALLATION (HARD DISK SYSTEM)
The following is a synopsis of the STARRSS installation process.
Installation Instructions - Hard Disk System |
~ Check available disk space on hard disk I
(Must have at least 1 Megabyte free)
~ Place diskette in floppy disk drive
~ Change directory to the floppy disk drive
(type "a:")
~ Type "install" to run the installation program
I
~ Remove deliveiy diskette from floppy disk drive and store it
in a safe place
* Change directory to the hard disk drive
(itype "c:")
~ Change location to STARRSS directory
(type "cd stanss")
~ Type "stanss" to start the program
The user should make sure that there is at least 1 Megabyte (i.e., 1 million bytes) of available
space on the hard disk (usually referenced as the "C" drive2). STARRSS itself does not need
this much memory; the installation and execution of the system will probably work fine with
half of that. However, without a minimum of 1 Megabyte of available space on the hard disk,
the user is likely to be plagued by situations where a STARRSS run is terminated because of
insufficient memory, especially when generating several sets of output reports from different
runs.
2
All instructions in this user documentation will assume this convention; If the user's PC is configured differently, the "C:\" should merely be
replaced with the appropriate letter or pathname in all documented instructions. References as to what the user should type are always in bold
characters.
10
-------
To check the available disk space, type "dir" at the C:> prompt. At the bottom of the listing
of files and directories, DOS will display the number of bytes of available disk space.
After verifying that enough memory is available, the user places the delivered diskette in the
floppy disk drive, change the directory to the floppy disk drive, and type the following:
A:>install
This will invoke an installation program that will set up everything in a C:\STARRSS directory,
by default. If the user wants STARRSS to reside in a different directoiy, he or she must
include the disk drive (or pathname) of this location on the same line where he or she types
"install" (e.g., A:>install c:\acidrain). In this case, the installation program will create that
directory and install STARRSS there.
If the user does not specify anything on the install command line, the installation program will
create a main directory called C:\STARRSS and a BGI subdirectory called C:\STARRSS\BGI.
It will copy the STARRSS program, delivered databases, and "HELP" file, and will list of all
STARRSS files (FILES.LST) into the main directory. All of the STARRSS output will be
written in this directory, unless the user specifies otherwise (see Reporting Parameters, page
112). The BGI subdirectory will contain a set of graphic interface files which are needed for
STARRSS' graphics capabilities.
If the directory specified by the user (either directly or by default) already exists, the installation
program will overwrite some of it Specifically, the installation program will overwrite the
STARRSS program itself, the BGI files, and the HELP file. If it finds any existing STARRSS
databases in the directory, it will stop the installation process. None of the databases on the
delivery diskette will be copied to the directory. The user will then be returned to DOS and
will be free to list and copy any of the specific databases from the delivered diskette through
the standard DOS commands. If the user is starting out with a "fresh" PC, there should be no
complications.
Once the installation program is finished, the user should change the directory back to the hard
disk drive (e.g., type "c:"). The delivery diskette should be removed from the floppy disk drive
and stored in a safe place.
2.4 INSTALLATION (FLOPPY DISK SYSTEM)
It is recommended that STARRSS be run on a PC that has a hard disk. However, if this cannot
be arranged, STARRSS can be run from a floppy disk, but it is much slower.
If there is no hard disk available, then there is nothing to install. However, the PC must be
capable of reading high-density floppy diskettes. STARRSS will not fit on a low-density
(sometimes called double density) diskette.
11
-------
Before executing STARRSS from a floppy disk system, the user/installer should make a backup
copy of the delivered diskette and store that diskette in a safe place. If the user does not know
how to copy diskettes, the system manager should be consulted. In order to run STARRSS, the
"write-protect" tab/label must not be on the diskette. In other words, STARRSS needs to be
able to write reports to the diskette.
To start the program, the user merely has to insert the STARRSS diskette in the floppy disk
drive and type "STARRSS":
A:>starrss
If the PC cannot read the diskette, check to make sure that the PC can indeed read high-density
diskettes.
2.5 RUNNING STARRSS
Once the installation process is complete, the user is ready to invoke (start) STARRSS by going
to the STARRSS directory and typing "starrss."
RUNNING THE PROGRAM
C:>ed starrss (.. .to move to the appropriate directory)
C:\STARRSS>starrss (...to start the program)
This will bring up the STARRSS "banner" screen. If it does not, check to make sure that a file
named "stanss.exe" is in the current directory. If not, then: (1) the user may not be in the
correct directory, or (2) the program installation process was not successful and must be
repeated.
Details concerning the operation of the system are continued in Chapter 3.
12
-------
3.0 GETTING STARTED
STARRSS is a full-screen, menu-driven modelling tool. Table 3-1 lists some general rules that
apply to moving around this menu-based system.
Table 3-1. Rules of the Road
WHAT TO DO...
... AND HOW TO DO IT j
To go to a specific screen
Move the highlighted cursor to the name
of the screen (which is listed on a |
submenu) and press
To move around any particular screen
Use the Cursor Aitow keys (up, down,
right, and left)
To input or change a data value on an
input screen
Place the cursor on the data field and type
in the new value1 and press
To exit any screen
Press the key
To move between "connected" screens
9 (what is meant by "connected" will be seen
J shortly)
Use and
[ To request HELP!
Press the F1 key
At the bottom of each screen, the user will find a line of abbreviated reminders and instructions
about special features (i.e., use of the PC's Function Keys) that are specific to that screen.
Some of the Function Keys (i.e., F1 through F10) allow the user to locate information, jump
to other screens, etc. Those specific Function Keys will be discussed during the description of
those screens.
This now value will be automatically stored in the STARRSS database that resides In the PC's core memory; however, the database should
be saved (see discussion In Chapter 4) if the user wishes to incorporate this data change Into the STARRSS database that is In the PC's permanent
disk storage.
13
-------
FIRST THINGS FIRST: STARTING THE PROGRAM
To invoke STARRSS, go to the directory where the program is located and type
"starrss." If the installation program was used, then STARRSS will probably be in the
C:\STARRSS directory, and the user should type the following:
C:>cd starres
(...to move to the appropriate directory)
C:\STARRS S>starrss
(...to start the program)
This command will load the STARRSS.EXE file into the PC's core memory. The user is now
ready to utilize STARRSS; the system's "banner" screen (which is shown on the title page of
this User's Manual) will be displayed. The system will instruct the user to wait for a second,
since this is the time during which STARRSS will make a few trial mathematical calculations
to determine the speed of the user's PC. As the user will see later, STARRSS will use this
information to forecast how long particular analyses will take to execute. After STARRSS has
finished its trial calculations, the user should strike any key to leave the banner screen.
After the banner screen, the user will see the Main Menu, displayed below as Table 3-2:
Table 3-2. Main Menu
Files system-Level Info unit-Level Info Kxecute Reports
I.
Load
s
Save
M
Memory Available
~
Temporarily exit to DOS
Q
Quit
| Fl Help | ENTER make selection |
Along the top part of the screen, the user will see five submenu categories from which to select.
Each category is described in detail in the following five chapters.
14
-------
~ Files
Addresses file management issues:
databases, saving databases, etc.
[see Chapter 4]
loading (retrieving)
Accesses input data that is not unit-specific: conservation
programs, allowance prices, system marginal costs,
discount rates, tax rates, etc.
[see Chapter 5]
Accesses input data that is unit-specific: capacities, heat
rates, allowance allocations, compliance option costs and
impacts (for scrubbing, fuel-switching, repowering, etc.)
[see Chapter 6]
Accesses screens for running STARRSS (Phase I or Phase
II, Evaluations or Optimizations)
[see Chapter 7]
Accesses output reports and graphs
[see Chapter 8]
What's a Submenu?
A submenu is a "box" of selections that is viewed and accessed by placing the highlighted
cursor on one of the five STARRSS categories. The user can move the cursor back and forth
between these categories using the left and right cursor arrow keys. As the cursor is moved
from one category to another, a "submenu" is displayed under each category.
A STARRSS "organizational chart" is depicted in Figure 3-1; it provides an overview of all of
the STARRSS selections. Each selection represents (and provides access to) a screen or set of
screens that contain the program's inputs, outputs, or execution commands.
Before going to any of the submenu selections in STARRSS, the user mast load a
database. The user cannot do anything in STARRSS before loading a database.
~ System-Level Info
~ Unit-Level Info
~ Execute
* Reports
15
-------
Figure 3-1. STARRSS Organizational Chart
Filoa
L
Load
S
Save
M
Memory available
D
Temporarily Exit to DOS
Q
Quit
System-Level info
B Base Case Conservation/Renewables
I Incremental Conservation/Renewables
E Marginal Energy Costs
C Marginal Capacity Costs
P Allowance Purchase Prices
S Allowance Sale Prices
A Allowance Parameters
T Tax Hate, Escalation Rates and Cost of Capital
F Probabilities Associated with Forecasts
unit-Laval Info
A Display/Edit Affected Units
0 Affected Unit Operating Factors
E Edit/Define Compliance Options
N Display Compliance Option Names
F Fuel Inputs
R Generating Unit Redundance
L Compliance Option Linking
V View Compliance Options
Exacuta
Summarize and Execute I
Select Compliance Options
User Strategies
Develop STARRSS Strategies
(Execute) «
X Execution Parameters
P Reporting Parameters
E Evaluate User Strategies —
D Develop STARRSS Strategies
Raports
W Warnings
T Compliance Strategies Total Cost Report
D Compliance Strategies Detail Report
G Graph of Compliance Statistics
S Compliance Option Report by Strategy
U Compliance Option Report by Unit
R Compliance Option Ranking Report
z Compliance Strategies Unitized Cost Report
I Input Summaries
Total Cost of Compliance Strategies
Average Unitized Cost ($/ton)
Marginal Unitized Cost (S/ton)
Purchased Allowances
Total Cost of Purchased Allowances
Compliance
Strategies
List
Generating Unit Operating Factors
Display Generating units
Retirement and Commission Years
Option Life, Efficiency, and Fuel
Compliance Option Costs
Option Derate and Overrides
Fuels
16
-------
Choosing Selections
In front of each selection in the STARRSS submenus, the user will find a letter. The user can choose
a selection by either of two methods: 1) type the letter of the desired selection, or 2) position the cursor
over the selection and press .
A HELPful Note: Information Bar and Help Facility
As mentioned earlier, at the bottom of each STARRSS screen, the user will notice a line
of information that provides assistance instructions. One of the two instructions on the
Main Menu informs the user that STARRSS has a Help facility. By typing F1 from any
STARRSS screen, the user can access this Help facility. Help will display several
paragraphs of information pertaining to the screen from which it was "called." The other
notation at the bottom of the Main Menu ("ENTER make selection") merely reminds the
user to press to select from the submenu.
Before exploring all of the STARRSS screens in the subsequent chapters, it is essential that the user
becomes acquainted with the program's general methodology. The remainder of this chapter presents
information on:
(1) the multiple forecasts used in STARRSS,
(2) the system of user-specified probability distributions,
(3) the data entry process, and
(4) the program's Monte Carlo simulation approach.
17
-------
3.1 MULTIPLE FORECASTS IN STARRSS
One of the most important and valuable aspects of STARRSS is its multiple forecast/scenario approach
to compliance planning. As mentioned in Chapter 1, STARRSS allows a user to evaluate and determine
the cost of compliance plans under a large variety of different economic and operational circumstances.
By using several values for each data item, STARRSS can reveal how the cost of a compliance strategy
would vary under different assumptions for fuel costs, unit operations, allowance prices, etc. STARRSS
can run hundreds of different simulations and expose a specific compliance strategy to many different
combinations of events. Therefore, to provide STARRSS with the necessary range of information,
virtually all of the program's data inputs are entered in the form of three distinct forecasts. The user will
see references to Low, Medium, and High forecasts on almost all of the data screens.
There are actually four pieces of information that are required to represent these triple forecasts; three
of those entries are the different forecasts themselves (Low, Medium, and High), and the last is a
Probability Pointer, which designates a probability distribution for the three forecasted values.
Use of Probability Pointers
The user must provide STARRSS with an estimate of the likelihood (in the form of a percentage) that
each particular forecast will come about. These percentages must add up to 100%. The percentages will
be used by STARRSS in the development of different, specific scenarios. For example, a user might
expect allowance prices to start out at $400/allowance in the first year of an analysis, but could also see
prices starting as low as $300/allowance or as high as $500/allowance. The user would then enter these
three values for the different forecasts and designate specific percentages that would be associated with
each of the three forecasts. These percentages would represent the expected "probability of occurrence"
for each of the forecasts. For instance, the user might specify a 30%-50%-20% probability distribution
for the Low, Medium, and High forecasts, respectively. This would cause STARRSS to use the $300
allowance price in 30% of its scenarios, $400/allowance in 50% of the cases, and the $500 price in the
remaining 20% of the scenarios. A STARRSS input convention was adopted to make data entry less
cumbersome and to keep the input screens less cluttered. Instead of having the user input six numbers
for each data item (three for the forecasts and three for the probabilities associated with the forecasts),
the user can "reference" a probability distribution with a single number: the Probability Pointer. A
Probability Pointer is a number between 0 and 99. The distribution itself is defined on a separate screen
(see page 20). A Probability Pointer merely "points" to this information. Thus, to represent the above
example, the user would enter the following four pieces of information on the allowance price screen:
$300 for the Low forecast, $400 for the Medium forecast, $500 for the High forecast, and a Probability
Pointer of, say, 17 — where the 17th probability distribution was input (on a different screen) as a 30%-
50%-20% distribution. As mentioned above, each probability distribution must sum to 100%.
The terms Low, Medium, and High (for the forecasts) do not constrict the actual data values in any way;
the terms are nothing more than labels. There is no requirement that the High value be greater than the
Medium, or the Medium greater than the Low. For all intents and purposes, STARRSS views the three
forecasts as Forecast #1, #2, and #3.
As will be discussed in detail below (see page 32), dependence between different data forecasts can be
modelled in STARRSS. For example, one might believe that low-sulfur fuel prices and allowance prices
will move in tandem (i.e., when fuel prices are high, allowance prices will be high, and when fuel prices
18
-------
are low, allowance prices also will be low). This dependence can be represented by having both sets
of forecasts point to the same probability pointer. Another more advanced feature (probability pointer
linking) can also be used; this process "links" two or more probability distributions (see page 21).
The user is not required to input multiple forecasts for any data item
If the user does not wish to use the multiple-scenario capabilities in STARRSS or does not have multiple
estimates for a particular data item, a single value may be specified in the Medium forecast. Simply
leave the Probability Pointer set to its default value of zero. The Probability Pointer #0 has been
internally fixed as a 0%-100%-0% distribution; therefore, for data items that have the Probability Pointer
so designated, STARRSS will only use the Medium forecast in all of its scenarios.
19
-------
3.2 THE PROBABILITY POINTERS SCREEN
Table 3-3. Probabilities Associated with Forecasts screen
Probabilities Associated with Forecasts -- Screen 1 of 7
Probabilities in each row must stun to 100%
Probability
Pointer
Link Number
LOW
MEDIUM
HIGH
0
0
0.0
100.0
0.0
1
0
25.0
50.0
25.0
2
0
10.0
50.0
40.0
3
1
30.0
50.0
20.0
4
4
40.0
40.0
20.0
5
4
5.0
90.0
5.0
6
5
15.0
65.0
20.0
7
6
50.0
30.0
20.0
8
7
20.0
30.0
50.0
9
7
10.0
20.0
70.0
10
8
15.0
70.0
15.0
11
8
25.0
50.0
25.0
12
4
33.0
34.0
33.0
13
4
10.0
80.0
10.0
14
.4
40.0
40.0
20.0
Enter
number
F1 Help | | ESC menu
The Probability Pointers screen (shown in Table 3-3 above) is crucial to the STARRSS scenario analysis
process. As described above, the data items on this screen will determine the likelihood of occurrence
of the Low, Medium, or High forecast of any given data item during a STARRSS scenario. Along with
probability distributions, the inputs to this screen will also define dependency relationships between
forecasts. To ensure the best use of the STARRSS scenario analysis process, the user will need to
consider carefully the probabilities he or she would like to associate with different data items, as well
as which data items should be strictly dependent, which should be loosely dependent, and which should
be independent. Strict dependence is accomplished by giving two data items the same Probability
Pointer. This would ensure that whenever STARRSS selects the Low forecast for one data item, for
example, the second data item would also have its Low forecast selected. The mechanics of this process
are explained below.
The Probability Pointers screen can be found under the System-Level Info submenu; the selection is
titled "Probabilities Associated with Forecasts" and will be discussed more in Chapter 5 (see page 63).
The 100 Probability Pointers in STARRSS (numbered 0 through 99) are listed on seven screens
(accessed by and ); however, the user is by no means required to use all one
hundred pointers. In most STARRSS applications, the user will not need any more than a dozen or so
pointers. As can be seen in Table 3-3, the Probability Pointer reference numbers are listed down the
left-hand side of the screen. The numbers in this column are fixed (i.e., the cursor will not move into
that column, and therefore the user cannot change them) and they are in ascending order. The associated
probability distributions are on the right-hand side of the screen. These are the values that the user must
input or modify (the delivered databases will have the same 0%-100%-0% probability distribution
described for each Probability Pointer). Each row of probabilities must sum to 100%. If this is not the
case, STARRSS will not let die user exit this screen. Instead, upon pressing the key, the user
20
-------
will see a "pop-up" window that reports which Probability Pointer has a set of probabilities that do not
add up to 100%.
As mentioned earlier, Probability Pointer #0 has a permanently fixed probability distribution of 0%-
100%-0%. Therefore, anytime that the user does not wish to define multiple forecasts for a data item,
he or she may simply input a Medium forecast and leave the Probability Pointer set to zero. STARRSS
will then overlook any information placed in the Low and High forecast fields, using the Medium value
in all simulations.
Between the Probability Pointer and its probability distribution is another data item that the user can
change: the Link Number. The Link Number "links" two or more probability distributions. This is a
more advanced form of the probability dependence issue that was alluded to earlier. Strict dependence
between two data items (for example, low-sulfur coal prices and allowance prices) can be modelled by
simply designating the same Probability Pointer for both data items. For instance, assume that the user
designated a particular low-sulfur coal price forecast as being $1.20, $1.40, and $1.60/MMBTU for the
Low, Medium, and High forecasts, respectively. Likewise, assume that allowance prices of $300, $400,
and $500 were similarly defined and that both data items were given a Probability Pointer of 3. From
Table 3-3, the user can see that the probability distribution for this pointer is 30%-50%-20%. By giving
both of these data items the same Probability Pointer, the user has ensured that when STARRSS selects
the $1.20/MMBTU coal price for one of its scenarios, it will also select the $300 allowance price every
time. STARRSS will never select $1.20/MMBTU and the $400 or $500 allowance prices at the same
time.
To model "loose" dependence between data items, the user can "link" Probability Pointers. To
understand the linking of Probability Pointers, the mechanics of the STARRSS scenario
development/forecast selection process is explained in the following section.
21
-------
3.3 THE DATA ENTRY PROCESS
The STARRSS data entry process is fairly straightforward. The Allowance Purchase Prices screen
(found under the System-Level Info category2) will be used as an example.
To get to this screen from the Main Menu, the user should place the cursor on the System-Level Info
category; the user will see a list of input data screens. These screens contain information that pertains
to the entire utility system or to the utility's compliance planning situation in general (e.g., data on
conservation programs, allowance prices, tax rates). Table 3-4 below shows the System-Level Info
submenu.
The submenu lists all of the input screens that are under this category. The user can select or access any
of these screens by typing the specific letter that is to the left of the selection or by using the up and
down Cuisor Arrow keys to place the cursor on the desired selection and pressing . Exiting a
screen is done by pressing the key; this will return the user to the Main Menu.
General Data Entry Example: Allowance Purchase Prices screen
The A llowance Purchase Prices screen (accessed from the Main Menu by pressing "P") allows the user
to define year-by-year forecasts for the expected price of allowances. An example of the A llowance
Purchase Price screen can be seen in Table 3-5 below.
As was seen earlier, STARRSS is organized tn a "top down" hierarchy, in that the five top-level categories have submenus that display the
list of possible selections that can be made under each category. Most of these selections provide access to screens or other menus.
Table 3-4. System-Level Info submenu
Files System-Level Info unit-Level Info Execute
Reports
B Base Case Conservation/Renewables
i Incremental Conservation/Renewables
B Marginal Energy Costs
C Marginal Capacity Costs
p Allowance Purchase Prices
S Allowance Sale Prices
A Allowance Parameters
T Tax Rate, Escalation Rates and Cost of Capital
F Probabilities Associated with Forecasts
ENTER make selection
22
-------
Table 3-5. Allowance Purchase Prices screen
—— = Allowance Purchase Prices — Screen 1 of 3 = -
Market for BUYING Allowances Units: $/allowance
Probability Pointer: 3
Forecasts LOW MEDIUM HIGH
Purchase Price
Premium (%): 1.10 1.00 1.00
Growth Growth Growth
Year Price Rate <%} Price Rate (%) Price Rate (%)
1992 300.0 3.50 400.0 4.00 500.0 4.00
1993
1994
1995
1996
1997
1998
1999
2000
2001
Enter number
Fl Help | Ctrl-F fill | ESC menu
The screen's layout is duplicated on many different input screens throughout STARRSS. Starting about
halfway down the screen, the annual price forecasts are arranged vertically and are grouped into Low,
Medium and High forecasts across the screen. The screen displays the first ten years of the forecast,
as depicted by the column of years on the left-hand side of the screen. The user can view/access later
years of the forecasts by pressing .
23
-------
A Note About Nominal versus Constant Dollars
The user can enter price data in terms of either nominal or constant dollars. Nominal
dollars reflect the total cost of an item in any particular year in question and therefore
include the effect of inflation. Constant/real dollars do not include inflationary
assumptions.
However, the user must be careful to remain consistent throughout the STARRSS data
system. For example, if the user chooses to input data items in constant/real terms, all
escalation rates and cost of capital rates must be in real terms (i.e., with inflation taken
out) and all price/cost forecasts must be in terms of a single year's dollar (usually the
study base year).
At the top of the A llowance Purchase Price screen, the user can see a reference to (1) how many screens
this particular selection has, and (2) which of those screens the user is in. In this case, the user is in
Screen 1 of 3. Screen 2 of 3 has the years 2002 to 2011; Screen 3 of 3 has the years 2012 to 2019.
The time frame of the forecast (and hence, the number of screens required to represent the allowance
price forecasts and other annual data items) is determined by the number of years represented in the
STARRSS database. This is controlled by the database's Base Fear and End Year (two user-specified
data items that are discussed in Chapter 5; see page 59).
For any of the three price forecasts, the user need not input every year's value. STARRSS has specific
conventions that make data entry faster and easier.
Cany-Forward Conventions and Growth Rates
The user will note in Table 3-5 above that there are two columns for data entry under each forecast:
a field for prices and a field for growth rates. The use of growth rates is a flexible and fast approach
to entering data. As one option, the user can simply type in numbers in the price field. Any fields in
the column that are left blank will "carry-forward" the value from the previous year. Thus, if the user
entered 300.0 in 1992 and nothing else, that would designate an allowance price forecast that was flat
(at $300/allowance for each year of the study). Of course, if the user wished to vary this estimate year
by year, different values could be entered for each year.
The second column of entries specifies growth rates. Using the growth rates data field can simplify data
entry considerably. For example, if the user designated "3.50" for the 1992 growth rate, the 1993
allowance price would be 3.5% greater than the 1992 price unless a value had already been input for
the 1993 price. The user may change forecast values or growth rates for any year of the study. The
growth rate will escalate the current year's value into the next year's value and will continue this pattern
from year to year until (1) a new growth rate is specified, or (2) a new data value is specified for the
allowance price. In the latter case, the new price will "prevail" in that year and all subsequent years
(unless there are entries in later years).
24
-------
For all STARRSS screens, the carry-forward and growth rate processes can be summarized with the
following:
1) If any annual field is left blank, STARRSS will carry-forward the previous year's
information; this applies to data values and growth rates;
2) If a growth rate is specified, STARRSS will use it to escalate the current year's value up
to the next year's value, provided that the field for the next year's value is blank;
3) A "carried-forward" growth rate is automatically reset to 0% in the year that a user-
specified value is entered.
In reference to this last point, imagine that the user entered $312.0 in 1994 for the Low forecast of
allowance prices in Table 3-5 above. Since the low> forecast starts out with $300.0 at a 3.5% growth
rate in 1992, the values that STARRSS would use would be:
1992
$300.00
1993
$310.50
1994 - on
$312.00
Without another growth rate specified for 1994 (or any later year), STARRSS would assume that the
low forecast was meant to stay at $312.0 for all subsequent years.
The user is encouraged to use the carry-forward and growth rate features as much as possible. If
values are directly input for each year, the size ("i.e.. memory requirements^ of the STARRSS
database will increase. The more fields that can be left blank, the smaller the STARRSS database
will be, reducing the possibility of problems with insufficient memory.
Fill function
Along the bottom of all STARRSS screens is a line of instructional/assistance information. At the
bottom of this particular screen (Table 3-5), the user will see the term "Ctrl-F fill." By holding
down the Control (Ctrl) key and striking "F," the user will cause STARRSS to fill in all of the blank
fields on the screen with the appropriate numbers. This way, the user can quickly check that all
values are carrying forward and/or escalating as intended. The user can page down through
subsequent screens to observe the carry forward/escalation effects in later years of the study.
The filled values are merely temporary: the fill function does not permanently input this information
into a screen. When the user strikes any other key, the screen will be cleared of all filled values.
When STARRSS is executed, the system will automatically fill in all of the forecasted data items for
use in its calculations. Again, whenever possible, the user should try to use a few long-term growth
rates to describe annual data in STARRSS for all of the years of a study rather than filling all of the
annual values in the data screens by hand. This will save the user time and will conserve computer
memory.
25
-------
Incidentally, when the Fill function is executed, STARRSS will calculate and display all of the
implicit growth rates, whether they were directly entered by the user or were implied by specific data
value entries. In other words, if the user input allowance prices of $500, $550, and $600 for one of
the forecasts for the years 1992 through 1994, then STARRSS would display 10%3 and 9.09%4 as the
growth rates for 1992 and 1993, respectively.
Moving Around STARRSS - Using Selection Lists (F2)
In exploring and using STARRSS, the user will encounter input data screens that are unit-specific, fuel-
specific, etc. In other words, each unit or fuel has its own specific screen of information. For example,
in working with information about generating units, one of the screens that the user will utilize is the
Affected Unit Operating Factors screen. This screen has multiple pages of information far each unit.
Upon selecting this screen, the user will be placed in the first screen for the first unit in the database.
The user can use the and keys to move between the multiple screens for this
particular generating unit. However, in order to move to another generating unit's operating information,
the user must do one of two things, both of which are listed on the instruction bar at the bottom of the
screen and involve the use of the computer's function keys.
One option is to place the cursor on the Unit Name field and press F2 (Select). A pop-up window will
appear which will display the database's internal list of generating units. By moving the cursor to the
desired unit name and pressing , STARRSS will display all of that unit's current operational
information on the screen.
Data Items that have Selection Lists
How to Use Selection Lists
Generating Units
Fuel Contracts
Conservation/Renewable Programs
Unit-specific Compliance Options
Compliance Option Links
User-Specified Compliance Strategies
Place the cursor on the Name field (e.g.,
Generating Unit Name, Fuel Name).
Press F2. A pop-up window will display
the Selection List.
Place the cuisoron the desired selection.
Press .
Another option is to press F8 to move forward through STARRSS' internal list of generating units. This
is the same list that is displayed in the F2 selection process above, but in this case, the list is not
displayed. Each time the user strikes F8, STARRSS will advance to the next unit in the database's list,
displaying all of that unit's current information on the screen. By pressing F7, the user can move
3
10% = [550-500^500
*9.09% - (600-550J/550
26
-------
backward through this list and access information for previous units. The user should be careful to note
the instruction bar at the bottom of each screen; some screens have two different data items with internal
lists. In these cases, the next/previous capability may be activated with the F9/F10 keys as well as the
F7/F8 keys (see the Edit/Define Compliance Options screen on page 82 for an example).
The general data entry features of carry-forward conventions, growth rates, "filling," and Selection Lists
can be seen on many screens throughout STARRSS. With this knowledge of data entry conventions and
a general understanding of the STARRSS multiple forecast approach, the user should be well-equipped
to work with the program. The next five chapters of the User's Manual address each of the five
categories on the Main Menu, starting with the Files category in Chapter 4.
27
-------
3.4 THE STARRSS MONTE CARLO APPROACH
As mentioned in Chapter 1, one of the strengths of the STARRSS program is its multiple-scenario,
Monte Carlo approach to compliance planning. "Monte Carlo" merely refers to a methodology whereby
multiple simulations of a process are performed; for each simulation, a different set of assumptions is
used. STARRSS allows the user to evaluate the cost of compliance strategies under hundreds of
different assumptions about future economic and operational situations. STARRSS does this by running
hundreds of simulations, where the input assumptions for each data item in each simulation are
temporarily fixed at one of the three data item's forecast values (the Low, Medium, or High forecast).
STARRSS then "prices out" the compliance strategy based on all of those fixed input assumptions and
stores the information. It then runs through the forecast selection process for another
simulation/iteration, choosing a whole new set of input assumptions and determining the cost of the
compliance plan under those new assumptions. Jt stores this cost information and repeats the process.
The number of simulations is controlled by the user and is defined on the execution screens (see Chapter
7, page 119). By the end of the process, STARRSS has stored hundreds of different values, each of
which reflects the cost of the particular compliance strategy under many different combinations of input
assumptions. How STARRSS chooses these combinations of input assumptions is known as the forecast
selection process and is described below.
The heart of forecast selection is a random number generator. However, STARRSS does not randomly
select each iteration's set of input assumptions; the probability distributions that the user defines are the
primary determinants of what input assumptions are used in the iterations (and how often they are used).
Yet, the selection process for each scenario iteration begins with a random number generator.
During each scenario iteration, STARRSS will generate a random number (between 1 and 100) for each
Link Number on the Probabilities A ssociated with Forecasts screen, starting with Link #0. That random
number will be used to select the forecasted value (Low, Medium, or High) for each data item that
"points" to a probability distribution which has a Link Number of 0. STARRSS first identifies which
Probability Pointers have a Link Number of 0. This subset of pointers have been "linked" by the user.
Therefore, within the context of a single iteration, STARRSS will use the same random number to
dictate which of the three forecasted "modes" each pointer is in. As will be seen below, this does not
necessarily mean that two linked pointers will always be in the same mode (e.g., the High forecast).
STARRSS's use of the randomly generated number to select a pointer's mode is fairly straightforward.
For each Probability Pointer, STARRSS "stacks" the Low, Medium, and High forecasts' probabilities on
a continuous scale from 1 to 100 and thereby defines "zones" of numbers that corresponded to the Low,
Medium, or High situations. The size or width of each zone is determined by its probability percentage -
- the larger the percentage, the larger the zone. Therefore, for Probability Pointer #3 in Table 3-5 above
(which has a 30%-50%-20% distribution), the Low zone would be from 1 to 30, the Medium zone from
31 to 80, and the High zone would be from 81 to 100, as depicted in Figure 3-2 below:
28
-------
Figure 3-2. Zones for Forecast Selection
1 30 80 100
I 1 1 1
Low zone Medium zone High zone
Defining such zones ensures that a random number between 1 and 100 would have a 30% chance of
falling in the Low zone, a 50% chance of being in the Medium zone, and a 20% chance of being in the
High zone — the exact probability distribution defined by the user for Probability Pointer #3.
Assume now that, during a given scenario iteration, STARRSS' random number generator outputs the
number "35" for use in selecting the forecast mode for Probability Pointer #3. This value would fall in
the Medium zone, so STARRSS would select the Medium forecast. Any data item that pointed to
Probability Pointer #3 would be set to its Medium forecast value for this particular scenario Iteration.
STARRSS would perform the same process with all other Probability Pointers (and their associated data
items) to determine which forecast should be used for all of the data items in the database. STARRSS
would then calculate the cost of the compliance strategy for this particular scenario iteration.
For the next scenario iteration, the random number generator might output the number "93" for pointer
#3. This would put it in the High range. The next iteration might see a random number of" 17," leading
to the selection of the Low forecast value for all data items that pointed to pointer #3. In actuality,
STARRSS does not generate a random number for each Probability Pointer, rather, as mentioned earlier,
it generates one for each Link Number. Therefore, for two or more pointers that have the same Link
Number, STARRSS will use the same random number (within a particular iteration) to determine the
pointers' modes.
29
-------
Simulation Example
Although the complete forecast process may sound complicated, it is actually fairly simple. For
example, assume that the user had specified the following information (displayed in Tables 3-6 and 3-7
below) in the STARRSS database:
Table 3-6. Forecasts for Data Items
Data Item
Low
Medium
High
Probability fl
Pointer |
High-Sulfur Coal Price ($/MMBTU)
0.00
1.10
0.00
0 I
Low-Sulfur Coal Price (S/MMBTU)
1.20
1.40
1.60
1 I
Allowance Price ($)
300
400
500
2 1
Scrubber Capital Cost ($M)
500
525
530
3 I
Table 3-7. Probabilities for Forecasts
Probability
Link
Low
Medium
High
Pointer
Number
0
0
0.0%
100.0%
0.0%
1
0
25.0%
50.0%
25.0%
2
0
10.0%
50.0%
40.0%
3
1
30.0%
50.0%
20.0%
Note that the High-Sulfur Coal Price has a Probability Pointer of 0 (which has a 0%-100%-0%
distribution); therefore, there is no need to specify Low and High prices since the user has indicated that
the Medium price should be used in all of the STARRSS iterations. Note also that Probability Pointers
#0, #1, and #2 are linked, in that they all have a Link Number of 0. Since there are only two Link
Numbers, STARRSS will only generate two random numbers for each iteration.
30
-------
Iteration $ 1
Assume that STARRSS generates two random numbers (say, 17 and 54). The first one is used to dictate
the modes for all Probability Pointers with a Link Number of 0 (namely, pointers #0, #1, and #2). The
second one applies to Probability Pointers with a Link Number of 1 (namely, pointer #3). Through the
procedure described above, STARRSS determines which values will be used in Iteration #1 for each of
the four data items (as displayed in Table 3-8 below).
Table 3-8. Selection of Values for Iteration #1
Random Number
Pointer
Mode
Data Item
Value
17
#0
Medium
HS Coal Price
$1.10
17
#1
Low
LS Coal Price
$1.20
17
#2
Medium
Allowance Price
$400
I 54
#3
Medium
Scrubber Capital Cost
$525M
STARRSS will use the values in the right-hand column to calculate the cost of a particular compliance
strategy. Note that even though the top three data items are ked, they did not end up in the same
forecast mode. Because of its specific probability distribution (#1), the Low-Sulfur Coal Price ended
up being set to its Low value.
If the strategy involved fuel-switching at a particular generating unit that currently burned the High-
Sulfur Coal but could burn the Low-Sulfur Coal, STARRSS would price out that part of the strategy
based on a $0.10/MMBTU price differential ($1.20/MMBTU - $1.10/MMBTU) between the two fuels.
If the strategy involved buying allowances, those allowances would be priced at $400 apiece. Finally,
if the strategy involved the construction of the scrubber that is included in this example, then that
scrubber's capital costs would be $525 million. STARRSS will process all of this information through
standard present value techniques and determine the compliance strategy's total present value cost.
Chapter 9 provides the details of these calculations. This iteration's results are stored, and STARRSS
proceeds to the next iteration.
Iteration #2
Assume the random number generator now produces the following two numbers: 72 and 29. The
results of the forecast selection process are listed in Table 3-9 below:
31
-------
Table 3-9. Selection of Values for Iteration #2
Random Number
Pointer
Mode
Data Item
Value
72
#0
Medium
HS Coal Price
$1.10
72
#1
Medium
LS Coal Price
$1.40
72
#2
High
Allowance Price
$500
29
#3
Low
Scrubber Capital Cost
$500M
Again, STARRSS will price out the cost of compliance (in present value terms) for a particular
compliance strategy using the selected values for the data items. The process will continue for as many
iterations as the user specifies (up to 999; see Chapter 7, page 119 for details).
Through repeated iterations, the total cost of a particular compliance strategy will assume many different
values (one for each iteration) that will reflect the strategy's cost under various combinations of economic
and operational events. This process is called a Monte Carlo simulation. The cost from any single
iteration may not represent the strategy's expected cost. However, if the user runs this type of simulation
through enough iterations, the distribution of the costs can yield two important results. First, the
"expected value" (or average) of the cost distribution provides a better indication of the likely cost of
a compliance strategy than a "static" estimate that is predicated on a fixed set of. economic and
operational assumptions. Second, the range or variance of the distribution of costs provides the user with
an idea of the level of economic risk that is inherent in the compliance strategy.
Probability Dependence
Returning to the discussion of probability distributions, the user must consider the dependence that
different data items may have on each other. Generally speaking, there are three different levels of
dependence that can be represented in STARRSS: strict dependence, loose dependence, and
independence.
Strict Dependence: two or more data items are judged to always move together. When one is high, they
are all high; when one is low, they are all low. The user should give these data items the same
Probability Pointer.
Loose Dependence: two or more data items are judged to generally move together. This is a minor
distinction, but it allows the user to define different probability distributions for each data item. Loose
dependence can then be reflected by linking those Probability Pointers-, this is done by giving them all
the same Link Number. Of course, if two linked Probability Pointers have the same probability
distributions (e.g., 30%-50%-20%), they are redundant; the user may as well just use the first pointer.
Independence: two or more data items show no "connection" in the values that they may assume. Many
variables in STARRSS can be classified as independent. For example, while the S02 removal efficiency
of a scrubber is based on the capabilities of the technology and the quality of the design and
construction, it is unlikely to be affected by the price of allowances, the price of natural gas, or a host
32
-------
of other data items in STARRSS. Therefore, the user should be careful to specify different, unlinked
Probability Pointers for all variables that are deemed to be independent.
The user should consider the dependent/independent nature of all of the STARRSS data inputs and
sketch out those relationships before defining the Probability Pointers in the pointer screen and
specifying them throughout the STARRSS database.
33
-------
4.0 FILES
Table 4-1 below shows the Main Menu and the Files submenu; this is where STARRSS puts
the user when the program is started up.
Table 4-1. Main Menu
| Files system level Info unit level Info Execute Reports
I.
Load
s
Save
H
Memory available
D
Temporarily Exit to DOS
Q
Quit
Fl Help | ENTER make selection |
The submenu shows that the Files categoiy can be used to:
*¦ Load a database,
~ Save a database,
~ Request information on the Memory Available in the PC's core
memory,
* Temporarily Exit to DOS without quitting from the program, or
*¦ Quit from the program.
§ Before going to any of the other submenu selections in STARRSS, the user must load a
j database. The user cannot do anything in STARRSS before loading a database.
34
-------
4.1 LOADING A DATABASE
To load a database, the user must select the Load command in the Files submenu. STARRSS
will search the current directory for all STARRSS databases and display these files in a "pop-up"
window (shown in Table 4-2 below).
Table 4-2. Load screen
riles
System-Level Info
L Load
S Save
M Memory Avail
D Temporarily
Q Quit
unit-Level Info
-database to load
Execute
Reports
Search Pattern
C:\STARRSS\*.SDB
Files— ~=:
GENERIC.SDB
UTILITY1.SDB
UTILITY2.SDB
UTILITY3.SDB
ZBACKUP.SDB
¦Directories
BGI
OK
Cancel
GENERIC.SDB 08/27/92 2:00pm 26866
Fl Help
| ENTER select database
D change directory
STARRSS databases are identified by the filename extension "SDB." In other words, every
STARRSS database must be named .SDB, where can be any eight-
character name that the user desires.
To select a particular database, the user simply positions the cursor on the database name and
presses .
The pop-up window will disappear and, for a second or two, STARRSS will flash a message
on the screen that it is loading a database. Once a database is loaded, the user can proceed to
examine and modify existing data, run the program, and/or view results. If the user has loaded
the wrong database (or simply wishes to view a different database), a new database can be
loaded by repeating the above process. The previously-loaded database will be cleared from
the PC's core memory and the new one will be pulled in. There is no need to exit from
STARRSS.
If the user does decide to load another database (after having updated the current one with new
data), the user must realize that —
35
-------
Loading a new database into STARRSS will clear out the current database without
saving it
Selecting Databases from Other Directories
If the user wants to use a STARRSS database that is not in the current directory, the user may
instruct STARRSS to search for databases in a new directory location. By typing a "D," the
user will cause the cursor to jump over to the directory box in the pop-up window. This box
lists the subdirectories that are under the current directory where STARRSS resides. By
selecting one of these subdirectories, the user can search for STARRSS databases in that new
location. For example, the user may execute STARRSS from the C:\STARRSS directory but
have databases in the C:\STARRSS\DATA subdirectory. In this case, the user would type "D"
and select the DATA subdirectory. STARRSS would then search for databases in the new
location, display all that it found, and return the cursor to the database list. The selection
will take the user up one level in the PC's directory hierarchy (similar to the "cd command
in DOS).
As an alternative to the above procedure, the user can type an "S" and cause the cursor to jump
up to the top field in the pop-up window. This field is used to specify the complete directory
pathname in which STARRSS will search for databases. The user can modify this pathname
to instruct STARRSS to search for databases in a new location.
A Shortcut
While invoking STARRSS from DOS, the user can take a shortcut to the above process
and type the name of the desired database (e.g., utility.sdb) on the same line as "starrss":
C:\STARRSS>starrss utility .sdb
This shortcut will bring up the banner screen. As always, the user will have to strike a
key to get to the Mean Menu; however, at this point, STARRSS will automatically load
the desired database.
36
-------
4.2
SAVING A DATABASE
When the user instructs STARRSS to save a database (by selecting Save), the system will save
a copy of the currently loaded database 12 disk. STARRSS will pop-up a window, prompting
the user for the database's pathname and filename (e.g., C:\STARRSS\DATA\UTILITY.SDB).
As a default, STARRSS will display the current database name and location. If the user wants
to save any modifications back into the original database, he or she can merely press .
STARRSS will interrupt to alert the user that this database already exists and will ask whether
or not the user wants to overwrite it. If the user does, he or she should type "Y." This will
permanently change the original database. If the user wants to preserve the original database,
then a different database name must be specified.
Whenever STARRSS is executed, the program will automatically create a database named
ZBACKUP.SDB in the current directory. Should STARRSS abort during execution, this safety
feature will provide the user with a database that includes all of the data changes that have been
made up to that point. However, the user should note that this database will be overwritten
every time STARRSS is executed.
A STARRSS database contains all of the input information for a particular utility or system of
utilities (i.e., holding companies, power pools) as well as parameters that control the execution
of a study. Output results, on the other hand, are not part of the database. Instead, output files
are automatically saved onto the same directory from which STARRSS is executed. The user
can direct these files to another location, such as C:\STARRSS\REPORTS (see the Reporting
Parameters screen, page 112). Regardless, these files will have the same "root name" as the
database. In other words, running STARRSS with a database called UTILITY. SDB will
generate a series of output files that are called UTILITY.XXX (where XXX represents a variety
of filename extensions).
4.3 TEMPORARILY EXIT TO DOS
If the user wishes to exit STARRSS temporarily in order to perform tasks in DOS (e.g., copying
files, listing files in directories), he or she does not need to quit from STARRSS. Instead, by
typing "D" (the Temporarily Exit to DOS selection) under the Files category, the user can work
in the DOS environment without quitting STARRSS. However, the user cannot run other
programs (e.g., Lotus 1-2-3, etc.) at the same time that STARRSS is residing in the PC's core
memory. To return to STARRSS, the user must type "exit"
4.4 MEMORY AVAILABLE
Particularly when working with large databases, the user may want to investigate how much
room is available in the PC's core memory. The core memory is different from the hard
37
-------
disk or floppy disk memory. A PC's core memory is where the machine does all of its
processing. Therefore, the user must have enough core memory to accommodate;
(1) the STARRSS program (Version 1 is about 346,000 bytes),
(2) any particular STARRSS database, and
(3) extra "room" for temporaiy files that are created during the execution of the
program.
Every effort has been made to reduce STARRSS' memory requirements and ensure that the
program can be executed within a memory limit of 500,000 bytes. The potential size of the
database is not limited, however, and the user's PC may not have enough core memory to
handle large systems. Also, the user's PC may have other programs that stay resident within
the PC's memory during STARRSS execution. Particularly if the user anticipates analyzing
large systems, he or she should make every effort to provide STARRSS with as much core
memory as possible.
PC Memory Considerations
The user should not invoke STARRSS from within other programs (e.g., Windows,
Lotus 1-2-3, etc.)- STARRSS should be invoked from DOS only.
Also, the user may have to remove some of the PC's core resident software applications
(sometimes called TSRs) such as electronic mail systems, menu software, and
modem/communication packages. If TSRs are a problem, they can be removed fairly
easily by editing the PC's system set-up files. To do this, the user's system manager
should be consulted. He or she may be able to establish a dual configuration process
that would allow the user to have the best of both worlds. Prior to invoking STARRSS,
the user could run a procedure that used a new set of system configuration files. After
each STARRSS session, the user could run another procedure that would put the TSRs
back into the PC's core memory.
By placing the cursor on the Memory Available selection and pressing , the user can
assess how much core memory is left at that time. A pop-up window will be displayed that
shows how much memory is currently available on the user's PC as well as how much will be
required to execute different types of runs in STARRSS. There are four different types of runs
that a user can instruct STARRSS to perform: an evaluation of user-specified compliance
strategies, and three different optimization processes (Full Enumeration, Hueristic #1, and
Heuristic #2). All four execution processes are described in Chapters 7 and 9. The Memory
38
-------
Available display window shows the amount of core memory that will be required for each of
these execution processes.
By selecting Memory Available before loading a database, the user can determine how much
memory the program itself has taken up and how much is left for the database and execution
processes. If the program aborts during the loading of a database with an "insufficient memory"
warning, the database is probably too large. To check this, follow these instructions:
(1) Reboot the PC;
(2) Check the size of the database in question (by typing "dir" while in DOS) and
note the number of bytes that it takes up on the PC's disk memory; this will be
very close to the amount of core memory that it will take up;
(3) Invoke STARRSS;
(4) Select Memory A vailable and compare the number of bytes available to the size
of the database (determined from Step 2).
If a database loads smoothly but insufficient memory occurs while executing STARRSS, the
above process should be followed in addition to the following step:
(5) Select Memory Available again after loading the database to see how much
memory is left for STARRSS' temporary execution files.
As mentioned above, the program presents estimates of the amount of memory that will be
required to execute each of the four STARRSS execution processes (the main evaluator and the
three optimizers). If the user's PC does not have enough memory for the desired execution, the
user must either reduce the size of the database or get more memory installed in the PC. Again,
the user should check to make sure that TSRs (e.g., electronic mail systems, menu software,
modem/communication packages) are not permanendy residing in the PC's core memory and
consuming an inordinate amount of memory.
4.5 QUITTING FROM STARRSS
The user can exit STARRSS by selecting Quit under the Files submenu. Alternatively, the user
may type ALT-X (i.e., hold down the ALT key and type "X") from anywhere in the STARRSS
system. In either case, the program will prompt the user with a question to verify that the user
intends to exit STARRSS. Typing "N" will keep the user in STARRSS; typing "Y" will cause
the program to quit and will return the user to DOS. Any reports that have been generated
through executing STARRSS will already be on disk and therefore are automatically "saved."
However —
39
-------
Any changes to the database itself (i.e., input information and execution parameters)
must be saved prior to leaving STARRSS if the user wishes to preserve them.
Otherwise, those changes will be lost.1
1 If the user is familiar with other PC programs (such as Lotus 1-2-3), he or she will note that STARRSS
follows the same standard file handling conventions. If one retrieves a spreadsheet, makes some temporary
changes, and exits Lotus 1-2-3 without saving the spreadsheet, the changes are lost. Also, when one retrieves
a new spreadsheet, it wipes out whatever was already in core. STARRSS works the same way.
40
-------
5.0 INPUT DATA: SYSTEM-LEVEL INFO
STARRSS is organized in a "top down" hierarchy, that is, the five top-level categories have
submenus that display the list of possible selections under each category. Most of these
selections represent (and provide access to) another menu, a screen, or a set of screens.
After placing the cursor on the System-Level Info selection, the user will see a list of submenus
for entering system-level input data (i.e., information that pertains to the entire utility system
or to the utility's compliance planning situation in general: data on conservation programs,
allowance prices, tax rates, cost of capital rates, etc.). Table 5-1 below shows the System-Level
Info submenu.
Table 5-1. System-Level Info submenu
Files
system-Level Info
tmit-Level Info
Execute
Reports
B Base Case Conservation/Renewables
I Incremental Conservation/Renewables
s Marginal Energy Costs
c Marginal Capacity Costs
P Allowance Purchase Prices
s Allowance Sale Prices
A Allowance Parameters
T Tax Rate, Escalation Rates and Cost of Capital
r Probabilities Associated with Forecasts
F1 Help
ENTER make selection
As is the case on all of the STARRSS submenus, the user can access any of the screens by
typing the letter that is to the left of the selection or by using the up and down Cursor Arrow
keys to place the cursor on the desired selection and pressing . The user can exit
screen by pressing the key, which will return the user to the Main Menu.
41
-------
A Note About Nominal versus Constant Dollars
Many of the screens in the System-Level Info category contain annual cost and price
information. The user can enter these data in either nominal or constant dollars.
Nominal dollars reflect the total cost of an item in any particular year in question and
therefore include the effect of inflation. Constant/real dollars do not include inflationary
assumptions.
However, the user must be careful to remain consistent throughout the STARRSS data
system. For example, if the user chooses to input data items in constant/real terms, all
escalation rates and cost of capital rates must be in real terms (i.e., with inflation taken
out) and all price/cost forecasts must be in terms of a single year's dollar (usually the
study base year).
Base Case veisus Incremental
Before exploring the various screens in the System-Level Info submenu, a clear distinction must
be made between "base case" data items (existing/current) and "incremental" data items
(options/alternatives). Base case values should reflect current or projected standard operations.
These values should represent a projection of how things would have been had the CAAA not
been enacted. This establishes a base case that is a reference point from which the utility will
make decisions that will bring it into compliance with the CAAA. The STARRSS incremental
data items refer to the different alternatives that a utility has open to it in order to comply.
With these data items, the user will define possible compliance options (e.g., increased
conservation, unit-specific compliance activities). However, in order to have a reference point
from which to judge the cost-effectiveness of these alternative operations, STARRSS must have
information on how the utility's system is currently expected to operate without the
implementation of any compliance options (i.e., the "base case").
Saving Databases
If the user wishes to save the data that has been entered during a STARRSS session, he or she
must formally save the database (by selecting Save in the Files submenu) prior to ending the
session. STARRSS will not automatically store the new information.
42
-------
5.1 BASE CASE CONSERVATION/RENEWABLES
Table 5-2. Base Case Conservation/Renewables screen
Base Case Conservation/Renewables — Screen 1 of 3
Aggregation of planned conservation programs
LOW MEDIUM
System Marginal S02 Emissions (lbs/MWH)
3.2
Expected MWH Savings
Probability Pointer: 3
Growth
Year MWH Rate (%)
1992 100000 2.00
1993
1994
1995
1996
1997
1998
1999
2000
2001
3.3
MWH
110000
Growth
Rate (%)
2.10
Enter number
HIGH Prob. Ptr
3.4
MWH
120000
Growth
Rate (%)
2.40
F1 Help
F2 Select
Ctrl-F fill
ESC menu
The Base Case Conservation/Renewables screen (Table 5-2 above) is used to model
conservation and renewable energy programs that the utility plans to undertake regardless of
acid tain compliance activity.
The screen uses a layout that is similar to the Allowance Purchase Prices screen that was
discussed in Chapter 3 (see page 23); this format is duplicated on many different input screens
throughout STARRSS. Starting about halfway down the screen, the annual energy savings
forecasts are arranged vertically and are grouped into Low, Medium and High forecasts across
the screen. The screen displays the first ten years of the forecast, as depicted by the column
of years on the left-hand side of the screen. The user can view/access later years of the
forecasts by pressing the key. At the top of the screen, the user can see a
reference to (1) how many screens this particular selection has, and (2) which of those screens
the user is in. In this case, the user is in Screen 1 of 3. Screen 2 of 3 has the years 2002 to
2011; Screen 3 of 3 has the years 2012 to 2019. The time frame of the forecast (and hence,
the number of screens required to represent the energy savings forecasts and other STARRSS
annual data items) is determined by the number of years modelled in the STARRSS database.
This is controlled by the database's Base Year and End Year (two user-specified data items that
are discussed later — see page 59).
43
-------
The data inputs on this screen represent an aggregate of planned energy savings from DSM
programs and planned generation from renewable energy.1 "Planned" refers to the program
information represented on this screen that includes those programs that the utility expects to
pursue for non-compliance reasons (i.e., because of cost effectiveness, regulatory mandate, etc.).
In other words, these conservation programs are part of the utility's "base case." It is presumed
that they would have been implemented even if the 1990 Clean Air Act Amendments had never
been passed. In order to reduce the memory requirements for STARRSS, the information for
all "base case" conservation programs is entered on a single screen (i.e., all such programs must
be added together). A different screen (the Incremental Conservation/Renewables screen,
displayed later on page 47) provides for the modelling of additional individual programs that
could be implemented in the future to reduce S02 emissions. Presumably, such programs are
not cost-effective on a purely economic basis (or they would have been implemented already);
however, now the CAAA may have tipped the balance for these programs.
The inputs for the Base Case Conservation/Renew ables screen fall into essentially two
categories: an estimate of marginal S02 emissions, and a forecast of expected MWH savings.
System Marginal S02 Emissions
The System Marginal S02 Emissions refers to the expected long-range S02 emissions reduction
that is likely to be achieved for each MWH saved by the conservation programs. Since
STARRSS Version 1 does not have a system dispatch capability, the user must provide some
insight into how much S02 the conservation programs are likely to reduce. This is a function
of:
~ What hours of the day or year the conservation programs are expected to achieve
their energy savings?
~ What units are expected to be the marginal generating resources during those
hours?
~ What emissions rates are expected from those units?
If the program only reduced generation from gas-fired peaking units, the marginal S02
emissions rate would be nearly zero. If intermediate coal-fired generation were curtailed, the
marginal S02 emissions rate would be well above zero.
For the sake of clarity, the explanations in this section will only focus on conservation programs; however, since the same screens are used
for modelling renewable energy projects, everything that Is discussed in this section is equally applicable to renewable resources.
44
-------
The uncertain nature of the SOz emissions reduction that could be attributed to conservation
makes it particularly suitable for a scenario representation. As depicted on the screen displayed
above (see Table 5-2), the user may specify a low, medium, and high estimate for the marginal
S02 emissions rate (along with a probability pointer for the forecasts).
Suggested Procedure: System Marginal S02 Emissions
Use an existing dispatch simulation model under three different operating scenarios (e.g.,
low, medium, and high load growth cases and/or varying levels of conservation) to run
simulations with and without the conservation programs. Calculate the average annual
system S02 emissions (in lbs.) for all six cases. Calculate the difference in average
emissions between the "with" and "without" cases for each of the three scenarios and
divide these emissions by the average annual MWH conservation savings.
Expected MWH Savings
The Expected MWH Savings data item is an annual forecast of the aggregated energy savings
from all of the "base case" conservation programs. Neither the peak reduction benefits nor the
time of day/seasonal impacts of the energy savings are modelled in STARRSS Version 1;
instead, the compliance effects of these conservation programs are assessed by using the MWH
savings only. These savings values should represent reduced generator loads and should
therefore include the effects of transmission and distribution losses. In other words, 100,000
MWHs of savings at the meter could translate into a 107,000 MWH reduction in generation
requirements (assuming line losses of about 6.5%), and the user should input the 107,000 MWH
number.
As can be seen on the instructional line at the bottom of the screen, this screen has the standard
"Fill" function that was discussed in Chapter 3 (see page 26).
The conservation programs represented on this screen may mean the utility can receive bonus
allowances from EPA's conservation and renewable allowance reserve. The EPA will distribute
bonus allowances only for programs that achieve savings from 1992 through 1994 for Phase-I-
affected utilities and 1992 through 1999 for Phase-II-affected utilities. These savings must
come from measures that were implemented or installed after 1991. For example, a high
efficiency air conditioner installed in 1991 will result in energy savings for many years;
however, these savings will not be eligible for EPA's bonus allowances and should not be
included in the STARRSS input data. The energy savings entered on the conservation screen
should only represent the savings from conservation measures that were put in place after 1991.
45
-------
The EPA bonus allowances will be discussed in more detail later (see the Allowance Parameters
screen, page 56).
46
-------
5.2 INCREMENTAL C0NS1RVATION/RENEWABLES
Table 5-3. Incremental Conservation/Renewables screen
Incremental Conservation Programs/Renewables -- Page 1 of 1 =-==—
Name: RESIDENT 1 Description: Residential: Hi-Effic. Appliance Rebates
Start Year: 1992
FORECASTS Probability
LOW MEDIUM HIGH Pointer
Expected Energy Savings
in 1992 (MWH): 5000 6000 7000 4
Escalation Rate (%): 2.00 2.00 2.40 2
System Marginal S02
Emissions (LBS/MWH): 5.00 6.00 7.00 7
Annual Costs {1992 $/MWH): 40.000 41.000 42.000 8
Escalation Rate (%): 5.00 5.10 5.30 4
Annual Avoided
Utility Costs (1992 $'/MWH) : 39.700 40.500 41.800 8
Escalation Rate (%): 5.00 5.10 5.30 4
Enter text
PI Help | F2 Select | F4 delete program | F9/F10 prev/next program
The Incremental Conservation/Renewables screen (shown in Table 5-3 above) is used to model
conservation programs for evaluation as specific compliance options. They are not part of the
utility's "base case." These are individual programs or clusters of programs that are not
currently implemented (or scheduled to be implemented) but which now may be worthy of
further consideration in light of the Clean Air Act requirements. Before the Clean Air Act,
these programs may have not been cost-effective (i.e., the costs of the programs were not
believed to exceed the avoided costs). Now that the utility's S02 emissions probably need to
be curtailed (and EPA is providing bonus allowances as an incentive for implementing
conservation/ renewable resources), these conservation programs may have some additional
benefits that should be factored into the cost-effectiveness tests. STARRSS allows the user to
explore and quantify these additional benefits.
Program Name
The first data item in this screen is the program Name; this is merely a label to identify the
conservation program on other screens and on STARRSS output reports. It can be anything that
the user wants, but it cannot exceed ten characters.
47
-------
Program Description
The program Description is a longer label (of 40 characters) that can be used to more fully
describe a program. Like the program Name, it appears on some of the STARRSS output
reports.
Start Year
Underneath the Name and Description is the Start Year of the incremental conservation
program. Every compliance option in STARRSS has a Start Year to indicate when the activity
will begin affecting the utility's operations. This permits the user to investigate the costs and
benefits of delaying or advancing the schedule for any particular compliance option. In
STARRSS Version 1, there is no designated "End Year" for conservation compliance options;
they are assumed to last for the entire length of the study.
Expected Energy Savings and System Marginal S02 Emissions
The Expected Energy Savings and the System Margined S02 Emissions are identical to the data
items described earlier in the Base Case Conservation discussion — with one exception. The
energy savings for a conservation compliance option are only input for the first year of the
program and are escalated throughout the study period based on a user-specified escalation rate.
The escalation rate allows the user to represent a rise or decline in the program's savings over
time (i.e., because of increased or decreased customer participation, persistence or deterioration
of a conservation measure's effectiveness, etc.).
As noted above, conservation programs are assumed to last for the length of the study. Also
noted above, STARRSS Version 1 uses a single, average-year approach to compliance
modelling (which is discussed in detail in Chapter 9), in that it calculates the year-to-year
energy savings of a program and takes the average over the length of the study. Therefore, if
a conservation program is only expected to last for a few years, the user should modify the
first-year savings estimate to cause STARRSS to come up with the appropriate average-year
calculation. For example, assume that a user defines a program in STARRSS as saving
10,000 MWH/year (with 0% escalation). If the program is only going to achieve this level of
savings for 10 years (and then drop to zero), then the average value over 20-year study period
will be 5,000 MWH/year — and that is what the user should enter for first-year savings in the
screen displayed above.
48
-------
Annual Costs
The A nnual Costs entry is where the user estimates the long-term stream of costs that the utility
will bear in order to produce the expected annual savings. These costs include promotional
expenses, rebates, installation costs, incentive payments, and administrative costs. This stream
is input in the form of a first-year estimate (in $/MWH saved) and an escalation rate. There
is no provision in STARRSS Version 1 to distinguish between capital expenditures (that may
be put in rate base) and yearly expenses. The user should approximate the annual revenue
requirements that would occur in the event that a conservation program would involve
substantial capital expenditures.2 The cost entry will be escalated for each year of the study and
multiplied by the expected MWH savings in each year, thereby generating a stream of costs.
Annual Avoided Utility Costs
The A nnual Avoided Utility Costs should reflect the energy- and capacity-related marginal costs
(in $/avoided MWH) of the resources that will not have to be used because of the
implementation of the program.
Entries for The Annual Avoided Utility Costs must be less than the Annual Costs.
This will ensure that each conservation program always has a positive net cost; otherwise, the
program represents an investment the utility should have already undertaken — even if the
program did not reduce any S02 emissions at all. Considering that STARRSS can use any of
the three different forecasted values for both of these data items during its scenario simulations,
the user should ensure that the avoided cost value is always less than the annual cost value by
using the same probability pointer for both entries (and the same probability pointer for both
escalation rates) - as can be seen in the screen displayed in Table 5-3 above.
Since STARRSS uses this information for present value calculations and since the present value of revenue requirements for capital
expenditures is essentially equal to the capital costs themselves (as of the in-service year), then simply considering the capital expenditures as yearly
expenses should be a reasonable approximation. The only discrepancy would be in the tax effects - and this would be minor.
-------
Moving Through the List of Programs
The user should note that the bottom "instruction" line on the incremental conservation screen
displays information about several function keys that have capabilities that are specific to this
screen. The F9 and F10 function keys allow the user to "page" through multiple screens of
information where each single screen contains all of the information that the user can specify
for each individual program. At the top of the screen, the user will see the statement "Page X
of Y." This reference provides a quick means for the user to identify:
(1) the number of programs that have been modelled in the database ("Y"), and
(2) where the user currently is in the list ("X").
By pressing F9, the user will cause STARRSS to move to the previous program; F10 advances
to the next program.
Adding a New Program
To create a new conservation program, the user must press F10 until the end of the list is
reached. A "fresh" conservation screen (i.e., one with all blank fields) will then displayed. The
same thing will occur if the user selects the incremental conservation screen when there are no
programs modelled in the database; in this case, the screen will be referenced as "Page 1 of 1."
Deleting a Program
F4 deletes the current program from the list (after prompting the user with a precautionary
question).
50
-------
5.3
MARGINAL ENERGY AND CAPACITY COSTS
Table 5-4. Marginal Energy Costs screen
Marginal Energy Costs ($/MWH) — Screen 1 of 3
Costs for Replacement Energy
Probability Pointer: 7
Forecasts
Low
Medium
High
Year
1992
Growth
Cost Rate {%)
40.0 5.00
Growth
Cost Rate (%}
50.0 5.00
Growth
Cost Rate (%)
60.0 5.00
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
The next input screens in the System-Level Info submenu are the Marginal Energy Cost screen
(shown in Table 5-4 above) and the Marginal Capacity Cost screen. STARRSS uses the
information on these screens to calculate the additional costs (or benefits) of replacement power
for compliance options that are expected to change the output or capacity of generating units.
In other words, if switching a unit to a low-sulfur coal is expected to change its priority in a
utility's economic dispatch and cause the unit to run less, then STARRSS will calculate how
many fewer MWHs/year the unit is expected to generate. That lost energy will have to be made
up from other resources (e.g., other units on the utility's system, the bulk power market,
additional conservation). The Marginal Energy Cost screen is where the user enters estimates
of the annual costs of this replacement energy.
Although the costs of replacement power are likely to vary from unit to unit, the screening
nature of STARRSS necessitates the use of simplifying approaches. STARRSS uses the same
marginal energy costs and marginal capacity costs for determining replacement power cost for
every generating unit. In order to determine appropriate values for the marginal energy and
capacity cost screens, the user might want to look to the prices faced by a utility in the bulk
power market. This input would reflect the assumption that reductions or increases in any
generating unit's energy and/or capacity would be compensated through purchases or sales in
the bulk power markets. Such an assumption allows the user to specify a forecast for marginal
energy and capacity costs that can be applied to the entire system. The modelling of the
Enter number
F1 Help
Ctrl-F fill
ESC menu
51
-------
generating unit operational changes (such as capacity derates and changes in utilization) is
discussed in detail in the description of the Edit/Define Compliance Options screen in Chapter
6 (see page 82).
Data Entry
The screen's layout is similar to the A llowance Purchase Prices screen, with three forecasts of
year-to-year values (arranged vertically) and definable growth rates to facilitate data entry.
Likewise, this screen has the same "Fill" function capability as was discussed in Chapter 3 (see
page 26).
Marginal Capacity Cost Screen
The information on the Marginal Capacity Cost screen is virtually identical, with the obvious
difference that the values on the energy cost screen are entered in $/MWH while those on the
capacity cost screen are entered in $/kW.
52
-------
5.4 ALLOWANCE PURCHASE AND SALE PRICES
Table 5-5, Allowance Purchase Prices screen
Allowance Purchase Prices — Screen 1 of 3
Market for BUYING Allowances
Units: $/allowance
Probability Pointer: 3
Forecasts
LOW
MEDIUM
HIGH
Purchase Price
Premium (%): 1.10
1.00
1.00
Year
1992
Growth
Price Rate (%)
300.0 3.50
Growth
Price' Rate (%)
400.0 4.00
Growth
Price Rate (%)
500.0 4.00
1993
1994
1995
1996
199?
1996
1999
2000
2001
The Allowance Purchase Prices screen (shown in Table 5-5 above) allows the user to define
year-by-year forecasts for the expected price of allowances. This screen was examined in
Chapter 3 in the discussion of data entry conventions (see page 23); therefore, the discussion
here will focus on those issues that were not addressed in Chapter 3.
Buying versus Selling Allowances
Toward the top of the screen, the user will see the statement that this screen describes the
Maricet for BUYING Allowances. In STARRSS, the allowance market is modelled in two
distinct segments: the market for purchases and the market for sales. This allows the user to
model the "bid-ask spread" - the differential that often exists between the buying and selling
prices for a commodity. Particularly in illiquid markets, bid-ask spreads can be significant. For
instance, a utility may be able to purchase allowances at $400 apiece but may be unable to sell
them at any price over $350. In STARRSS, then, there are two separate input screens for
allowance prices: the A llowcmce Purchase Prices screen and the A How once Sale Prices screen -
- both accessible through the System-Level Info submenu. Therefore, the user can model
different price forecasts for buying and selling allowances, thereby capturing assumptions about
changing market liquidity over time or different tax treatments of allowance sales. Since both
Enter number
F1 Help
Ctrl-F fill
ESC menu
53
-------
screens' formats are identical, everything presented in this discussion about the purchase price
screen can be applied to the sale price screen, with a few exceptions discussed below.
Probability Pointer
As was discussed in Chapter 3 (see page 20), the Probability Pointer designates the specific
probability distribution that will be applied to the three allowance price forecasts (Low,
Medium, and High). The Probability Pointer is set to a value of three in the Table 5-5 example
screen above; this designates a particular distribution with Low-Medium-High probabilities of
30%-50%-20%. These probabilities are associated with each of the complete multiyear
forecasts. As STARRSS develops a particular scenario, it will select a complete multiyear
forecast from the three possibilities (Low, Medium, and High). In other words, 30% of the
time, STARRSS will select the Low price forecast for all years sf Ihg study. STARRSS will
not use the probability distribution to select prices from different forecasts for each and every
year.
Price Premium
Specifying a single price for the purchase of allowances in a particular year may not accurately
reflect market circumstances. Depending on the size of the allowance market, a utility may face
different prices for purchasing a few allowances versus purchasing a large number. If a utility
wanted to purchase 100,000 allowances, it might have to pay more than if it only wanted 5,000
allowances. For example, purchasing more and more allowances might require locating more
and more sellers, with each additional seller having progressively higher marginal costs of
compliance. If the allowance market is large enough, a single participant's actions probably will
not affect the price. However, if the market is "thin," the price of purchased allowances could
depend on the quantity. STARRSS permits the user to model this phenomenon through the
Purchase Price Premium, a data item that reflects the percent change in the price of allowances
attributable to the volume of a transaction. For the purpose of determining prices, STARRSS
evaluates allowances in blocks of 10,000. The Purchase Price Premium represents the percent
price increase (i.e., an escalation factor) that would occur for successive blocks of 10,000
allowances. For example, in Table 5-5 above, the Medium forecast has allowances available
for $400 each and a Purchase Price Premium of 1%. Therefore, the first 10,000 allowances
would cost $400/allowance. For the next 10,000 allowances, the price would be $4043; for the
third block, the price would be $408.04.4 The price for each subsequent block of 10,000
allowances would escalate accordingly.
3 $404 = $400 x 101%
4 $408.04 *= $404 x 101%
54
-------
Allowance Sale Prices Screen — Some Differences
In the Allowance Sale Prices screen, the user inputs forecasts for the prices allowances might
sell for, along with growth rates (if desired). Note that the user cannot change the Probability
Pointer in this screen; it is automatically set to the Probability Pointer defined in the A Uowance
Purchase Price screen. This prevents STARRSS from selecting inappropriate combinations of
buying and selling prices during its scenario development. If these price forecasts were not
"linked," STARRSS could potentially develop a nonsensical scenario with purchase prices that
were lower than selling prices. If such a situation existed, organizations could make money by
purchasing allowances at a lower price and selling them for a higher one. Such an unlikely
market situation would never last for long. By the same rationale, the user should be careful
to specify price forecasts in which the purchase price equals or exceeds the sales price in each
of the three states (Low, Medium, and High). STARRSS will generate warnings if this is not
the case. For example, Low-Medium-High buying prices of $300-$400-$500 and selling prices
of $250-$420-$450 would be invalid, since the Medium situation has a selling price that is
greater than the buying price.
Another difference involves the Sale Price Discount. Just as the Purchase Price Premium
(discussed above) allows the user to model the effect on prices of large allowance purchases,
the Sale Price Discount provides the same capability with allowance selling prices. In this case,
however, selling a large quantity of allowances would have the opposite effect on the market,
presumably depressing prices. Therefore, STARRSS will subtract the Sale Price Discount
percentage from 100% and multiply the sale price by this value for successive blocks of 10,000
allowances. For example, if the stated sale price was $300 and the Sale Price Discount was 2%,
then the first 10,000 allowances sold would go for $300 each, the next 10,000 would be $2945,
the next 10,000 would be $288.12®, and so forth.
5 $294 = 1300 x 98%
6 $288.12 - $294 x 98%
55
-------
5.5 ALLOWANCE PARAMETERS
Table 5-6. Allowance Parameters screen
Allowance Parameters
Screen 1 of 3
Bonus Allowance Supply Percentage
LOW
MEDIUM
HIGH
Pointer
Phase I Extension:
50.0
80.0
90.0
7
Cons erva t i on/Renewab1e:
70.0
80.0
100.0
5
j Phase II Repowering:
80.0
90.0
100.0
3
Allocated
Additional
Maximum
Allowed
Year
Allowances
Allowances
Purchases
Sales
1995
207000
0
207000
207000
1996
207000
1997
207000
1998
207000
1999
207000
2000
100630
0
100630
100630
1 2001
100630
2002
100630
!
2003
100630
I
I 2004
100630
|
2005
100630
2006
100630
Enter number
F1 Help
1
Ctrl-F fill
i
ESC menu
; Allowance Parameters screen (shown in Table 5-6 above) allows the user to spec
miscellaneous information about allowance allocations that may affect the outcome of a
STARRSS analysis. The information pertains to three general areas:
1) assumptions about the availability of bonus allowances,
2) allowance allocation adjustments, and
3) constraints over allowance trading activity.
56
-------
Bonus Allowance Supply Percentage
There are three major reserves of bonus allowances that the Clean Air Act Amendments set
aside to reward specific utility compliance activities. Those activities are:
(1) Implementing a pollution control technology at a Phase I unit that achieves a
90% S02 removal efficiency or better,
(2) Achieving energy savings from qualifying conservation programs or renewable
resources, provided that the conservation/renewable measures are implemented
after 1991, and
(3) Repowering a Phase II unit.
It is expected that one or more of these allowance reserves will be oversubscribed. In other
words, just because a utility pursues one of the rewardable activities that does not mean that it
is guaranteed to receive all of the bonus allowances to which it is entitled. The user can model
the uncertainty surrounding the availability of these bonus allowances with Bonus A llowance
Supply Percentage fields. For each compliance option that falls under one of the three bonus
categories, STARRSS approximates the total number of bonus allowances that a utility would
get if there were no oversubscription problem. The Bonus Allowance Supply Percentage is
used to adjust this number. Zero percent means that the user does not expect the utility to get
any bonus allowances at all for implementing that specific compliance option; one hundred
percent means the user expects the utility to get all of the bonus allowances it deserves. For
each category, the user can specify three forecasts for these adjustment percentages (along with
a Probability Pointer).
Allocated Allowances
The A llocated A llowances field on the screen is a calculated field (and therefore cannot be
changed). STARRSS calculates the total number of Phase I or Phase II allowances that a utility
has by adding up the unit allowance allocations depicted on the Display/Edit Affected Units
screen (referenced under the Unit-Level Info screen described in Chapter 6; see page 66).
Additional Allowances
If the user knows of an adjustment that should be made to the utility's total annual allocation
in either Phase I or Phase II (e.g., because of a sale or purchase of allowances), that system-
level adjustment can be made through ike Additional A llowances data item on this screen. This
adjustment can be either positive or negative (to reflect additions or deductions from the utility's
total number of allowances). This data item does not have a probability pointer associated with
57
-------
it, as such adjustments are expected to be fixed. Changes from bonus allowance allocations
may be highly uncertain, but this issue is specifically addressed by the data items described
above. If the adjustment is due to a correction in a generating unit's allocation, that adjustment
should be made directly on the Display/Edit Affected Units screen (see page 68).
The user should note that the, Additional Allowances field uses the carry forward convention;
in other words, an adjustment that is intended for just one particular year most be followed by
a zero in the following year. Otherwise, the adjustment value will carry forward into all
subsequent years.
Allow nee Trading Constraints
The user may also constrain the amount of allowance market activity the utility engages in. The
final two fields of the A llowance Parameters screen determine the absolute maximum level of
annual allowance buying or selling in which the utility may engage. During STARRSS
optimization, the program will discard strategies that violate the constraints. During strategy
evaluation, STARRSS will "flag" any strategies that violate the constraints (see Chapter 8, page
133); however, it will still purchase as many allowances as are required to bring the utility into
compliance, regardless of whether such an action will exceed the user-specified limit on
purchases. In the event that a strategy involves allowance sales that exceed the sales limit,
STARRSS will consider any allowances beyond the limit to have been sold without generating
any revenues (i.e., at an allowance price of zero).
Allowance Banking
An analysis of the banking of allowances requires a year-by-year perspective. This will be
performed in STARRSS Version 2.
58
-------
5.6 TAX RATE, ESCALATION RATES, AND COST OF CAPITAL
Table 5-7. Tax Rate, Escalation Rates, and Cost of Capital screen
= Tax Rate, Escalation Rates, and Cost of Capital — Screen 1 of 3 =
Base Year: 1992 Long-Run Effective Tax Rate (%) 34.00
End Year: 2019 Return on Equity (%) 12.00
Equity Percent of Capital 50.00
Escalation Rates For
Year Cost of Capital Capital Cost Variable O&M Fixed O&M
1992 10.00 5.00 5.00 5.00
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
Enter number
Fl Help | Ctrl-F fill j ESC menu
The Tax Rate, Escalation Rates, and Cost of Capital screen (shown in Table 5-7 above) defines
system-wide financial parameters that will affect the tax accounting and present value
calculations in STARRSS.
Base Year and End Year
The first user inputs to this screen are the Base Year and End Year of the study. These fields
designate the "boundary" years for the STARRSS database, in that no data may be specified for
years earlier than the Base Year or later than the End Year. If the Base Year or End Y ear are
changed, the user will notice that the years that run down the left-hand side of all annual data
screens will change accordingly.
59
-------
The Base Year dictates:
(1) the year's dollars in which all "non-annual" cost data are input, and
(2) the reference year for all present value calculations.
Examples of non-annual data are the compliance option capital costs, increased variable O&M
costs, and fixed O&M costs; these are entered in single fields, rather than in an annual stream
of values such as allowance prices and marginal energy costs. The non-annual data values
should be in Base Year dollars and will be escalated by STARRSS to determine the costs in
future years.
Since a compliance option is meant to represent an action that is being contemplated, rather than
one that has already been performed, no compliance option can have a "Start" year that precedes
the database's Base Year. By the same rationale, no compliance option can have a Start year
that is later than the database's End Y ear.
The difference between the End Year and the Base Year does not detennine the length
of a study during a STARRSS execution.
The length of a run is specified in the Execution Parameters screen of the Execute
submenu. However, STARRSS will not run a study for more years than it has data for.
In other words, STARRSS will not run past the End Year.
Like it sounds, the Long-Run Effective Tax Rate should represent an estimate of the utility's
long-run effective tax rate for federal and state taxes. As this is the effective tax rate, it should
include the effects of deferred taxes. Even though over the "long run" all of these deferred
taxes will be paid, the utility is likely to continue to accrue additional deferred taxes in future
years. Therefore, this estimate should reflect the average current tax liabilities (as a percent of
current taxable income) that the utility is expected to have to pay in each year over the course
of the study.
m
Length of Study
Taxes
60
-------
Return on Equity and Equity Percent of Capital
As described in Chapter 9 (see page 167), STARRSS will use this information in calculating
estimates of the tax benefits of accelerated tax depreciation and the additional tax-related
revenue requirements from equity returns — both for projects with ratebased capital
expenditures.
In order to calculate these tax-related costs and benefits, STARRSS will need some additional
information on the utility's capital structure (as it pertains to the calculation of the utility's
allowed return on ratebase).
The Return on Equity should reflect the expected long-run average percent return given to
common and preferred shareholders (or the latest allowed return on equity, if no forecast is
available).
The Equity Percent of Capital is the percent of the utility's total capital structure that is
represented by common and preferred stock. This information can be obtained from the balance
sheet of the utility's financial statements. STARRSS assumes that the current capital structure
will remain the same over the time span of the study. If the user suspects otherwise, then he
or she should input the average anticipated percent over the length of the study.
The user should not spend too much time and effort on refining these data inputs; STARRSS
is not a financial planning tool. The tax calculations that STARRSS performs are very
approximate and are appropriate for screening purposes only. Therefore, some "ball park"
estimates for the effective tax rate, the return on equity, and the equity percent of capital are
all that are necessary.
Discount Rates
The forecast for the utility's Cost of Capital is used primarily for discounting purposes in the
program's present value calculations, although it is also used in the tax calculations (see Chapter
9, page 167). Most commonly, studies use the utility's average cost of capital as the discount
rate. If the user wishes to use some other discount rate (e.g., the ratepayers' discount rate),
there is nothing sacred about the Cost of Capital data item being the utility's cost of capital.
However, since the data item is used as the utility's cost of capital in the tax calculations, the
user should examine and adjust those calculations if necessary. Through the use of the Detailed
Information Flag (discussed in the Execution Parameters screen, see Chapter 7, page 109), the
user can examine the specific tax numbers. If they are greater or lesser than they should be,
the user can adjust them using the Tax Benefit Multiplier and the Tax Cost Multiplier on the
same Execution Parameters screen.
61
-------
Escalation Rates
Like they sound, the escalation rates for capital costs, fixed operation and maintenance (O&M)
costs and variable O&M costs are used for escalating these various cost components out to the
appropriate years for defined compliance options.
As mentioned above, the user has a choice about defining costs in STARRSS in nominal dollar
terms or constant dollar terms. If the user chooses to express costs in nominal dollars (i.e.,
including inflation), then all rates (escalation, cost of capital, etc.) must be in nominal terms.
Likewise, a STARRSS analysis that is performed in constant dollar terms must have all rates
in constant/real terms (i.e., with inflation taken out).
62
-------
5.7 PROBABILITIES ASSOCIATED WITH FORECASTS
Table 5-8. Probability Pointers screen
Probabilities Associated with Forecasts -- Screen 1 of 7
Probabilities in each row must sum to 100%
Probability
Pointer
Link Number
LOW
MEDIUM
HIGH
0
0
0.0
100.0
0.0
1
0
25.0
50.0
25.0
2
0
10.0
50.0
40.0
3
1
30.0
50.0
20.0
4
4
40.0
40.0
20.0
5
4
5.0
90.0
5.0
6
5
15.0
65.0
20.0
7
6
50.0
30.0
20.0
8
7
20.0
30.0
50.0
9
7
10.0
20.0
70.0
10
8
15.0
70.0
15.0
11
8
25.0
50.0
25.0
12
4
33.0
34.0
33.0
13
4
10.0
80.0
10.0
14
4
40.0
40.0
20.0
Enter number |
F1 Help | | ESC menu
The Probability Pointers screen (shown in Table 5-8 above) is crucial to the STARRSS scenario
analysis process. The data items on this screen will determine the likelihood of occurrence of
the Low, Medium, or High forecast of any given data item during a STARRSS scenario. Some
of the data inputs on this screen will also define dependency relationships between forecasts.
To ensure the best use of the STARRSS scenario analysis process, the user should
consider carefully the probabilities he or she would like to associate with different data
items, and which data items should be strictly dependent, which should be loosely
dependent, and which should be independent.
Strict dependence is accomplished by giving two data items the same Probability Pointer. This
would ensure that whenever STARRSS selects, for example, the Low forecast for one data item,
it would also select the Low forecast for the second data item. The details of this process are
explained in Chapter 3 (see page 21).
The 100 Probability Pointers in STARRSS (numbered 0 through 99) are listed on seven screens
(accessed by and ); the user, however, is by no means required to use
63
-------
all one hundred. In most STARRSS applications, the user will not need any more than a dozen
or so. Table 5-8 shows that the Probability Pointer reference numbers are listed down the left-
hand side of the screen. The numbers in this column are fixed (i.e., the cursor will not move
into that column) and they are in ascending order. The associated probability distributions are
toward the right-hand side of the screen. These are the values that the user must input or
modify (the delivered databases will have the same 0%-100%-0% probability distribution
described for each Probability Pointer). Each row of probabilities must sum to 100%. If this
is not the case, STARRSS will not let the user exit this screen. Instead, upon pressing the
key, the user will see a "pop-up" window that reports which Probability Pointer has
a set of probabilities that do not add up to 100%.
Probability Pointer #0 has a permanently fixed probability distribution of 0%-100%-0%.
Therefore, anytime that the user does not wish to define multiple forecasts for a data item, he
or she may simply input a Medium forecast and leave the Probability Pointer set to zero.
STARRSS will then overlook any information placed in the Low and High forecast fields, using
the Medium value in all simulations.
Link Number
Between the Probability Pointer and its probability distribution is another data item that the user
can change: the Link Number. The Link Number "links" two or more probability distributions.
This is a more advanced form of the probability dependence issue that was alluded to earlier.
Strict dependence between two data items (for example, low-sulfur coal prices and allowance
prices) can be modelled by simply designating the same Probability Pointer for both data items.
For instance, assume that the user designated a particular low-sulfur coal price forecast as being
$1.20, $1.40, and $1.60/MMBTU for the Low, Medium, and High forecasts, respectively.
Likewise, assume that allowance prices of $300, $400, and $500 were similarly defined and that
both data items were given a Probability Pointer of 3. From Table 5-8, the user can see that
the probability distribution for this pointer is 30%-50%-20%. By giving both of these data
items the same Probability Pointer, the user has ensured that when STARRSS selects the
$1.20/MMBTU coal price for one of its scenarios, it will also select the $300 allowance price
every time. STARRSS will never select $1.20/MMBTU and the $400 or $500 allowance prices
at the same time.
To model "loose" dependence between data items, the user can "link" Probability Pointers.
Generally speaking, there are three different levels of dependence that can be represented in
STARRSS: strict dependence, loose dependence, and independence.
Strict Dependence: two or more data items are judged to always move together. When one is
high, they are all high; when one is low, they are all low. The user should give these data
items the same Probability Pointer.
64
-------
Loose Dependence: two or more data items are judged to generally move together. This is a
minor distinction, but it allows the user to define different probability distributions for each data
item. Loose dependence can then be reflected by linking those Probability Pointers', this is done
by giving them all the same Link Number. Of course, if two linked Probability Pointers have
the same probability distributions (e.g., 30%-50%-20%), they are redundant; the user may as
well just use the first pointer.
Independence: two or more data items show no "connection" in the values that they may
assume. Many variables in STARRSS can be classified as independent. For example, the S02
removal efficiency of a scrubber is based on the capabilities of the technology employed and
the quality of the design and construction. However, a scrubber's removal efficiency is unlikely
to be affected by the price of allowances, the price of natural gas, or a host of other data items
in STARRSS. Therefore, the user should be careful to specify different, unlinked Probability
Pointers for all variables that are deemed to be independent.
The user should consider the dependent/independent nature of all of the STARRSS data
inputs and sketch out those relationships before defining the Probability Pointers in the
pointer screen and throughout the STARRSS database.
65
-------
6.0 INPUT DATA: UNIT-LEVEL INFO
STARRSS is organized in a "top down" hierarchy, that is the five top-level categories seen on
the Main Menu have submenus that display the list of possible selections under each category.
Most of these selections represent (and provide access to) another menu, a screen, or a set of
screens.
After placing the cursor on the Unit-Level Info selection, the user will see a list of submenus
for entering unit- and fuel-specific information (e.g., generating capacities, heat rates, fuel costs,
unit-specific compliance options). The Unit-Level Info submenu is displayed in Table 6-1
below:
Table 6-1. Unit-Level Info submenu
riles system-Level Info unit-Level Info Execute Reports
a Display/Edit Affected Units
O Affected Unit Operating Factors
E Edit/Define Compliance Options
H Display Compliance Option Names
F Fuel Inputs
R Generating Unit Redundance
Zi Compliance Option Linking
V View Compliance Options
F1 Help | ENTER make selection
The submenu lists all of the input screens that are under this category. As is the case on all of
the STARRSS submenus, the user can access any of these screens by typing the letter that is
to the left of the desired selection or by using the up and down Cursor Arrow keys to place the
cursor on the desired selection and pressing . The user can exit a screen by pressing
the key which will return the user to the Main Menu.
Many of the data items discussed in the following pages can be viewed in a condensed format
in the system's Input Summaries (see the discussion in Section 8.1.9).
66
-------
A Note About Nominal versus Constant Dollars
Many of the screens in the System-Level Info category contain annual cost and price
information. The user can enter these data in either nominal or constant dollars.
I Nominal dollars reflect the total cost of an item in any particular year in question and
therefore include the effect of inflation. Constant/real dollars do not include inflationary
assumptions.
However, the user must be careful to remain consistent throughout the STARRSS data
system. For example, if the user chooses to input data items in constant/real terms, all
escalation rates and cost of capital rates must be in real terms (i.e., with inflation taken
out) and all price/cost forecasts must be in terms of a single year's dollar (usually the
study base year).
Base Case versus Incremental
Before exploring the various screens in the Unit-Level Info submenu, a clear distinction must
be made between "base case" data items (existing/current) and "incremental" data items
(options/alternatives). Base case values should reflect current or projected standard operations.
These values should represent a projection of how things would have been had the CAAA not
been enacted. This establishes a base case which is a reference point from which the utility will
make decisions that will bring it into compliance with the CAAA. The STARRSS incremental
data items refer to the different alternatives that a utility has open to it in order to comply.
With these data items, the user will define possible compliance options (e.g., fuel-switching,
reduced utilization, boiler efficiency/heat rate improvements, scrubbing) However, in order to
have a reference point from which to judge the cost-effectiveness of these alternative operations,
STARRSS must have information on how the system's generating units are currently expected
to operate without the implementation of my compliance options (i.e., the "base case").
Saving Databases
If the user wishes to save the data that has been entered during a STARRSS session, he or she
must formally save the database (by selecting Save in the Files submenu) prior to ending the
session. STARRSS will not automatically store the new information.
67
-------
6.1 DISPLAY/EDIT AFFECTED UNITS
Table 6-2. Display/Edit Affected Units screen
Affected Units Screen 1 of 1
Database Name: SULFUR POWER & LIGHT
Baseline Calculated
Unit
Capacity
Heat
Heat
S02 Emis.
Allowances
Name
(MW)
Rate
{TBTUs)
(tons)
Phasel
PhaselI
BIGCOAL 1
650.
0
10000
26
.700
75293
36500
14000
BIGCOAL 2
650.
0
10000
27
.300
84761
37000
14500
MEDCOAL 1
350.
0
10500
32
.320
44656
44000
17500
MEDCOAL 2
350.
0
10600
32
.800
46244
44500
18000
MEDCOAL 3
350.
0
10400
32.
.860
44424
45000
18000
MEDCOAL 4
350.
0
10400
32.
.260
7984
0
17500
SMALLOIL 1
50.
0
13800
0,
.370
77
0
200
SMALLOIL 2
50.
0
13600
0.
.640
115
0
330
SMALLOIL 3
80.
0
13500
1,
.040
171
0
600
Enter text
F1 Help | | ESC menu
The Display/Edit Affected Units screen (shown in Table 6-2 above) is one of two screens that
contain the majority of the unit-specific information in STARRS S (the other one is the A ffected
Unit Operating Factors screen, described later). Both screens contain information about the
generating units' base case operating characteristics.
Database Name
At the top of the screen is the Database Name. This is not the same as the STARRSS
database's DOS filename (which has the .SDB filename extension and is discussed in Chapters
2 and 4). Instead, this is an internal 40-character name that will appear on all reports.
Typically, the user might specify the name of the utility that is being modelled or reference a
unique aspect about the analysis for which the database has been developed (e.g., "Analysis of
Substitution Units," "Low Inflation Case").
The rest of the screen contains unit-specific data. The information contained in the delivered
databases came from publicly available sources and is discussed in Chapter 10.
Unit Name
The Unit Name field is where the user enters a 10-character label that will be used throughout
68
-------
the system to reference each generating unit. The Unit Name can only be changed on this
screen.
Capacity
The Capacity data item should reflect the generating unit's flet dependable capacity (in MWs).
A unit's net capacity is different from its nameplate or gross capacity in that it accounts for the
unit's power that is consumed internally at the plant (to power fans, pumps, etc.).
Heat Rate
This data item should represent the generating unit's average net heat rate (in BTU/kWh). This
can be calculated by taking the unit's average annual fuel consumption (in BTU) and dividing
by the unit's average annual net generation (in kWhs). Naturally, a unit's average heat rate may
vaiy depending on how the utility dispatches the unit. STARRSS Version 2 will be able to
incorporate these circumstances into an analysis because it will have system dispatch capabilities
and will dynamically calculate all of these values (while using user-specified incremental heat
rates at different unit loading points). However, for Version 1, the user must estimate each
unit's expected average annual heat rate.
Baseline Heat
The Baseline Heat data item is the generating unit's average 1985-1987 fuel consumption (in
trillion BTU), as reported in the National Allowance Database, Version 2.1. This is used by
STARRSS in certain bonus allowance calculations, and in some cases for the basis of
allowances allocated because of Reduced Utilization or Phase I Substitution plans (see
Chapter 11, Section 11.4).
Calculated S02 Emissions
The Calculated S02 Emissions field is "grayed out" on the screen, since it cannot be changed
by the user. It is the generating unit's projected annual S02 emissions (in tons/year) and is
calculated through the following Equation 6-1:
69
-------
Emissions = Cap * HeatRate * CapFaet * 8760 hrs * FuelS02 * (1 - ExRem) (6-1)
where:
Cap
Heatrate
CapFaet
8760 hours
FuelS02
ExRem
unit's capacity (in MWs)
unit's average heat rate (in MBTU/MWh, achieved by
dividing the STARRS S input by 1000)
unit's average weighted capacity factor (calculated across
all years and all three forecasts from the Affected Unit
Operating Factors screen)
the number of hours in a year
the S02 emissions rate attributable to the fuel or fuel blend
that is consumed at the unit
the SOz removal efficiency of the unit's existing pollution
control equipment, if any exists (see the Affected Unit
Operating Factors screen)
Phase I and Phase II Allowances
The Phase I and Phase IIA llowances fields represent the net annual allowance allocations for
each generating unit. As described in Chapter 10, the allocations depicted in the delivered
database(s) have come from the National Allowance Database, Version 2.1 (Environmental
Protection Agency, Allowance Branch, Acid Rain Division, June, 1992).
The net Phase I allocations are calculated from the Table A allowances (found in the CAAA)
and are adjusted upward for the section 404(a)(3) allowances (for units in Illinois, Indiana, and
Ohio) and downward to reflect the withholding of 2.8% of the allowances for the EPA Sales
and Auction Reserves.
Similarly, the Phase II allocations included in the delivered database(s) are calculated from the
published basic allocations and are adjusted upward for the section 405(a)(3) allowances (for
units in ten particular states) and downward for the Sales and Auction Reserves. STARRSS
assumes that the value that is input for a unit's Phase II allocation applies indefinitely from the
year 2000 on. However, a unit's allocation is likely to change after 2009, when specific
provisions in the CAAA expire. The Phase II allowance allocations depicted in the STARRSS
delivered database(s) are applicable to the 2000-2009 time frame. If the user determines that
the post-2009 changes will be significant, then he or she can
70
-------
make a system-level adjustment (on the Allowance Parameters screen under the System-Level
Info category; see page 56) that is equal to the sum of the individual unit adjustments.
Neither of the allowance allocation values entered on the Display/Edit Affected Units screen
should include bonus allowances from the three categories that are modelled on the A llowance
Parameters screen (under the System-Level Info category). First of all, this could lead to
double-counting. Second, the allowance allocations on the unit screen are fixed/flat for every
year of Phase I (1995-1999) and Phase II (2000-on), while the bonus allocations will involve
different year-to-year allotments. If the user wants to model a known distribution of bonus
allowances, this is best modelled at a system-level as A dditional A llowances on the A llowance
Parameters screen.
Adding, Moving, and Deleting Units
To add, move, or delete an affected unit from the database, the user must first go to the
Affected Unit Operating Factors screen (see pages 72-81).
71
-------
6.2 AFFECTED UNIT OPERATING FACTORS
Table 6-3. Affected Unit Operating Factors screen #1
Affected Unit Operating Factors -- Screen 1 of 3
Unit Name: BIGCOAL 1
Commission Date: 1978
Control Technology
Removal Efficiency
Variable O&M ($/MWH)
Retirement Date: 2025
Fuel 1
Fuel 2
Fuel 3
LOW
0.0
4.00
MEDIUM
0.0
4.50
Existing Fuel Blend
CQAL-IIiLN
HIGH
0.0
6.00
Percent
100.0
Probability
Pointer
0
10
F1 Help
F2 Select
F4 delete
F7/F8 prev/next
F3 Move Unit
The Affected Unit Operating Factors screen is the second of the two principal screens for
defining generating unit information. It contains information on each unit's following operating
characteristics:
Commission and Retirement Dates
Existing Pollution Control Systems
Current Variable O&M Costs
Current Fuel or Fuel Blend Consumed
Projected Utilization (Annual Capacity Factors)
The Affected Unit Operating Factors screen has multiple "pages," the first of which is displayed
in Table 6-3 above.
From this screen the user can add, move or delete units from the system (see pages 78-81).
72
-------
Unit Name
By placing the cursor on the Unit Name field and pressing F2, the user can access a full pop-up
selection list of all of the affected units modelled in the STARRS S database. An example of
this pop-up selection list is shown in Table 6-4 below.
Table 6-4. Affected Unit Operating Factors screen with pop-up selection list
-- •—Affected Unit Operating Factors -- Screen 1 of 3 -~=::—¦= -¦¦¦
Unit Name:
Commission
Control Tec
Removal Eff
Variable 0&
Select a Unit
BIGCOAL 1
BIGCOAL 2
MEDCOAL 1
MEDCOAL 2
MEDCOAL 3
MEDCOAL 4
SMALLOIL 1
SMALLOIL 2
SMALLOIL 3
Add a Unit
— —
Retirement Date: 2025
OW
.0
.0
MEDIUM
0.0
4.5
HIGH
0.0
6.0
Probability
Pointer
0
10
Existing Fuel Blend Percent
Fuel 1: COAL-ILLN 100.0
Fuel 2:
Fuel 3 :
F1 Help | F2 Select | F4 delete | F7/F8 prev/next | F3 Move Unit
Although the cursor can be placed on this field, the name of a unit cannot be changed on this
screen; that is done on the Display /Edit A ffected Units screen.
Commission and Retirement Dates
The Commission and Retirement Dates define the period of commercial operation for a unit.
Commissionings are assumed to occur on January 1 of the specified year, and retirements on
December 31 of the specified year. This means that a unit is assumed to operate through the
full year of either its commission or retirement year. STARRSS will only calculate a unit's
generation, emissions, and operating costs during the years of the unit's operating life. There
is no need for the user to make any other adjustments in the STARRSS database (i.e., zeroing
out fixed costs or projected capacity factors after retirement, etc.).
The data items on this screen represent the base case situation. In other words, if the user
wants to explore the possible life-extension orrepowering of a power plant, the Retirement Date
73
-------
on this screen should nai be changed. Instead, the user should identify this alternative as a
compliance option (discussed later on the Edit/Define Compliance Option screen, see page 82).
On this other screen the user can depict "new" commission or retirement dates (along with any
capital or operating costs that may be required to affect such a change).
The default values included in the delivered database(s) are the years 1900 for commissionings
and 2100 for retirements. This ensures that no affected units would be inadvertendy removed
from service in any initial STARRSS analyses. However, the user should modify these
assumptions to account for the actual commissionings or retirements that are expected to occur
within the time frame of any studies.
Control Technology Removal Efficiency
Some affected units already have scrubbers or other pollution control technologies installed on
them (because of State Implementation Plan requirements, New Source Performance Standards
that have applied to units that have come on-line in the last decade, etc.). These existing
systems are modelled with this screen's Control Technology Removal Efficiency data item. The
user should be careful not to confuse the modelling of these existing systems with that of
potential compliance projects. The latter are modelled on the Edit/Define Compliance Options
screen since they represent options that a utility could implement but has not yet undertaken.
The control technologies that are modelled on the Affected Unit Operating Factors screen are
part of the base case and are assumed to already be in operation.
To model an existing system, the user should merely specify the S02 removal efficiency of the
existing pollution control equipment (in percent of S02 removed). This value will be used to
reduce the generating unit's base case expected emissions (as calculated in Equation 6-1 in the
previous section). The data item has three forecasts (and an associated probability pointer) to
provide the user with the flexibility to define a range of estimates for the existing system's
performance.
Even though a unit already has existing pollution control equipment it can still be a candidate
for additional compliance activities. Many utilities are examining scrubber upgrades, fuel-
blending, and cofiring options at units that are already scrubbed. Likewise, in STARRSS,
specifying that a unit's emissions are reduced by an existing system does not preclude the user
from defining incremental compliance options on the Edit/Define Compliance Options screen.
The next section (on compliance options) discusses this further.
74
-------
Variable O&M ($/MWH)
As can be seen on the screen (Table 6-3), an affected unit's existing Variable O&M (operating
and maintenance) costs can be modelled as a triple forecast. These values are entered in Base
Y ear dollars/MWH. Each value will be escalated through all of the years of the study by the
system-level variable O&M escalator (see Tax Rate, Escalation Rates, and Cost of Capital
screen, page 59). These costs will be used to determine additional or avoided costs in the event
that a generating unit's utilization changes because of a compliance option.
Existing Fuel Blend
In the Existing Fuel Blend field, the user specifies which fuel or blend of fuels a generating unit
currently consumes. STARRSS allows the user to specify a fuel blend of as many as three
different fuels. Before a fuel can be selected for consumption at a generating unit, the user
must first define it in the Fuel Inputs screen (see page 98). The percentages that are specified
for one or more fuels on this screen should represent the average annual blend (on an MBTU
basis) and must add up to 100%. STARRSS will not let the user leave this screen If any unit's
fuel blend percentages do not add up to 100%.
Altering an Existing Fuel Type Entry
Altering an Existing Fuel Type Entry
Instructions
Results
Place the cursor on top of the existing fuel
I type entry in the Affected Unit Operating
Factor screen and press F2.
STARRSS will display a pop-up selection
list of all of fuels currently defined in the
database.
Move the cursor to the desired selection
and press .
The existing entry will be replaced with
the new selection.
75
-------
Adding a Fuel to the Fuel Blend
Adding a Fuel to the Fuel Blend
Instructions
Results
Place the cursor in the next blank New
Fuel Type field in the A ffected Unit
Operating Factor screen and press F2.
STARRSS will display a pop-up selection
list of all of fuels currently defined in the
database. |
Move the cursor to the desired selection
and press .
The new selection will be added to the fuel I
blend. A new set of percentages may now 1
be defined for the new fuel blend. |
Deleting a Fuel from the Fuel Blend
Deleting a Fuel from the Fuel Blend
Iastructions
Results
Place the cursor on top of the fuel that is
to be deleted in the A ffected Unit
Operating Factor screen and press F2.
STARRSS will display a pop-up selection
list of all of the fuels currently defined in
the database. At the bottom of the list will
be a "(remove fuel from blend)" selection.
Place the cursor on the "(remove fuel from
blend)" selection and press .
STARRSS will take the fuel out of the
fuel blend. The percentages for the
remaining fuel(s) should be readjusted so
that they sum to 100%.
Forecast of Annual Capacity Factors
The A ffected Unit Operating Factors screen has multiple pages. The first page is followed by
a series of screens that contain annual utilization projections for every affected unit. Moving
between these screens is done by using the and keys.
The capacity factors entered on these screens should represent base case circumstances, as
described earlier (see page 67).
76
-------
Since STARRSS Version 1 does not have production costing capabilities, the user must supply
unit capacity factors so that STARRSS can calculate each unit's average annual emissions and
assess each compliance option's cost-effectiveness. In Version 2's dispatch simulation, these
capacity factors will be ignored.
As can be seen in Tabic 6-5 below, the user can define triple forecasts (High, Medium, and
Low) of a unit's capacity factors for every year of the study. STARRSS will "carry forward"
data entries into blank fields; therefore, if the user expects a unit to operate at a relatively
consistent capacity factor over time, he or she can simply enter the capacity factor in the first
year and leave the rest blank. To verify that the correct values are being used in all years, the
user can utilize the Fill function (Ctrl-F) to view a complete picture.
Table 6-5. Affected Unit Operating Factors screen #2
- - ¦¦ — --- Unit Information -- Screen 2 of 3 —=»-.=
Unit Name: BIGCOAL 1
FORECASTS OF ANNUAL CAPACITY FACTORS (%)
Probability Pointer: 7
LOW MEDIUM HIGH
1992 55.0 60.9 65.0
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
Enter number
Fl Help | F2 Select | F4 delete | F7/F8 prev/next | Ctrl-F fill
Adding a Unit
The procedures for adding a unit to the STARRSS database are described below. When the
user follows the procedures, STARRSS will automatically place the unit at the bottom of the
unit list. It is through a subsequent procedure that the user can move the unit to a different
place in the list (see page 79).
77
-------
Adding a Unit
Instructions
Place the cursor on the Unit Name field in
the Affected Unit Operating Factor screen
and press F2.
Place the cursor on the
selection at the bottom of the unit list and
press .
Type in a unit name and press .
Select the fuel or fuel blend that the new
unit will consume (i.e., place the cursor in
the fuel field and press F2).
Specify the new unit's projected capacity
factor (fir t, press to
advance to the second Affected Units
Operating Factors screen).
Press and go to the Display/ Edit
Affected Units screen to input the new
unit's capacity, heat rate, baseline heat, and
Phase I and Phase II allowance allocations.
Results
STARRSS will display a pop-up selection
list of all of the affected units in the
database, as is shown in Table 6-4 on page
73.
STARRSS will ask the user for the name
of the new unit.
This name will be displayed in the screen's
Unit Name field.
STARRSS will not let the user leave the
screen until the new unit's fuel or fuel
blend has been specified.
STARRSS will not let the user leave the
screen until the new unit's projected
capacity factor has been specified.
The user will find the new unit at the
bottom of the list of affected units.
As noted in the above instiuction chart, STARRSS will not let the user leave the screen until
he or she has specified both the fuel (or fuel blend) that the unit will consume and the unit's
projected capacity factor (at least for the Base Year). If the user does not know what these
inputs should be, he or she should enter an educated guess (to satisfy STARRSS so that the user
can exit the screen) and return to this screen with refined estimates at a later date.
Renaming a Unit
A unit's name can only be changed on the Display/Edit Affected Units screen.
78
-------
Moving a Unit within the Unit List
If the user wishes to change the order in which STARRSS displays the generating units in the
system, he or she can move units within the "unit list." This is accomplished one unit at a time.
The procedure is described in the instruction chart on the following page.
Moving unite will not affect any STARRSS calculations. Rearranging the order of the units on
the Display/Edit Affected Units screen is strictly a cosmetic issue. It will only affect the order
of the units on:
1) the Display/Edit Affected Units screen,
2) the internal unit selection list (accessed with the F2 key),
3) the screens on which the user selects options for evaluation or
optimization runs), and
4) the output reports.
RECOMMENDATION
The user should modify the order of the units in a delivered database before proceeding
with the development and refinement of the database.
To move a unit, the user must first delete all of the following items from the database:
~ AH User-Specified Compliance Strategies (see page 117)
~ Ail Generating Unit Redundancies (see page 101)
~ All Compliance Option Linkages (see page 104)
79
-------
Moving a Unit
Instructions
Results
Select the unit to be moved (by placing the
cursor on the Unit Name field in the
Affected Unit Operating Factor screen,
pressing F2, locating the unit on the unit
selection list, and pressing ).
The unit and its operating information will
appear on the screen.
Press F3 (Move).
STARRSS will check to make sure that the
user has complied with the three
requirements listed above. If not,
STARRSS will display a warning message
telling the user that there are still some
strategies, redundancies, or linkages that
have not been deleted. Provided that the
above requirements have been satisfied,
STARRSS will redisplay the pop-up unit
selection list (with the name of the
"moved" unit grayed-out).
Place the cursor on the name of the unit
before which the moved unit should be
placed, and press .
STARRSS will insert the "moved" unit
into its new location in the list.
80
-------
Deleting a Unit
RECOMMENDATION
If there are any units that should not be on the affected unit list, the user should delete
these units before proceeding with the development and refinement of the delivered
database.
To delete a unit, the user must first delete all of the following items from the database;
~ All User-Specified Compliance Strategies (see page 117)
~ AH Generating Unit Redundancies (see page 101)
~ All Compliance Option Linkages (see page 104)
Deleting a Unit
Instructions
Results J
I Select the unit to be deleted (by placing
the cursor on the Unit Name field in the
A ffected Unit Operating Factor screen,
pressing F2, locating the unit on the unit
selection list, and pressing ).
The unit and its operating information will |
appear on the screen.
Press F4 (Delete).
STARRS S will check to make sure that the
user has complied with the three
requirements listed above. If not,
STARRSS will display a warning message
telling the user that there are still some
strategies, redundancies, or linkages that
have not been deleted. Provided that the
above requirements have been satisfied,
STARRSS will question the user to ensure
that he or she truly wants to delete the
current unit.
Press "Y" (to answer "Yes").
STARRSS will delete the unit.
81
-------
6.3 EDIT/DEFINE COMPLIANCE OPTIONS
Table 6-6. Edit/Define Compliance Options screen #1
Generating Unit:
= Compliance Options
BIGCOAL 1
Screen 1 of 3
Compliance Option Descriptor:
Compliance Option Name:
Option Life (in years): 30
Control Technology LOW
Removal Efficiency 88.0
WETFGDl
Wet Limestone Forced Oxidation Scrubber
In-Service Year: 1995
MEDIUM
90.0
HIGH
92.0
Probability
Pointer
5
EXISTING
Type %Blend
COAL-ILLN
100.0
Fuel Type #1
Fuel Type #2
Fuel Type #3
NEW
Type
COAL-ILLN
%Blend
100.0
F2 Select | F4 delete | F7/F8 prev/next unit | F9/F10 prev/next opt.
The primary function of the STARRSS compliance planning system is to evaluate alternative
courses of action. The majority of these compliance options are modelled in one common set
of screens: the Edit/Define Compliance Options screen (the first of which is shown in Table
6-6 above) and the Display Compliance Option Names screen (discussed in the next section).
The Edit/Define Compliance Options screen is actually a set of three screens. Moving between
these screens is done by using the and keys.
The Edit/Define Compliance Options screens and the Display Compliance Option Names
screens are used to model cost and operating information for the following types of compliance
activities1:
Chapter 11 contains descriptions and information on all of these types of compliance options.
82
-------
Compliance Options
Scrubbing (all types of technologies)
Sorbent Injection (and other combustion
technologies)
Fuel-Switching/Blending/Coflring
Repowering
Reduced Utilization
Efficiency Improvements/Upgrades (boiler,
precipitator, existing scrubber, etc.)
Fuel Cleaning
New, Cleaner Resources
STARRSS does not have different screens or special switches for modelling different specific
options from this list. Rather, all of the above compliance options are modelled on the same
screens with the same general set of inputs. However, it is not necessary to use every data item
on the compliance option screen to model each type of compliance option. For example, the
compliance option screen allows the user to define a new fuel or fuel blend that could be
consumed at a particular unit. For the modelling of a scrubbing option, this may not be
applicable; in this case, the user would leave the fuel inputs unchanged.
Generating Unit
The Generating Unit field displays the name of an affected unit for which a compliance option
can be modelled2. In STARRSS terminology, this is known as the "current" unit, since it is the
unit for which the user can currently enter compliance option information.
Although the cursor can be placed on this field, the name of a unit cannot be changed on this screen; that is done on the Display/Edit
Affected Units screen (see previous section).
83
-------
Selecting a Different Unit
1 Selecting a Different Unit
Instructions
Results
Place the cursor in the Generating Unit
field in the Edit/Define Compliance
Options screen and press F2.
The user will be presented with a selection
list of all of the affected units in the
STARRSS database.
I Place the cursor on the name of the desired
1 unit in the selection list and press .
STARRSS will prompt the user to select
the desired compliance option. STARRSS
will pop-up a second selection list which
includes a complete list of all of the
compliance options that are currendy
modelled for the selected unit. If the user
selects any of these, STARRSS will fill the
screen with cost and performance
information for that specific compliance
option at that specific generating unit.
Alternatively, the user can press the F7/F8 keys to move to the previous/next unit in the
STARRSS database.
Compliance Option Descriptor
Like the Generating Unit field, the Compliance Option Descriptor field cannot be edited;
instead, it is used for selecting different compliance options.
84
-------
Selecting a Different Compliance Option for the Current Unit
Selecting a Different Compliance Option for the Current Unit
Instructions
Results
Place the cursor in the Compliance Option
Descriptor field in the Edit/Define
Compliance Options screen and press F2.
The user will be presented with a selection
list of all of the compliance options that
are modelled in the STARRSS database
for the current unit.
Place the cursor on the desired option in
the selection list and press .
STARRSS will fill the screen with cost
and performance information for that
specific compliance option.
Alternatively, the user can press the F9/F10 keys to move to the previous/next compliance
option for the current unit.
85
-------
Defining a New Compliance Option for the Cuirent Unit
Defining a New Compliance Option for the Current Unit
Instructions
Results
Place the cursor in the Compliance Option
Descriptor field in the Edit/Define
Compliance Options screen and press F2.
The user will be presented with a selection
list of all of the compliance options that
are modelled in the STARRSS database
for the current unit. At the bottom of the
list, the user will see an selection. I
Place the cursor on
and press .
STARRSS will display another pop-up
selection list. This one lists those
compliance options that are modelled in
the database (in the Display Compliance
Option Names screen) but are not currently
modelled for the current unit. The user is
free to select one of these other
compliance options or to define an entirely
new option. The latter is done by
selecting the last choice on the selection
list, which is .
Selecting this will transport the user to the
Display Compliance Option Names screen
(which is discussed in the next section).
In this screen the user defines short and
long descriptions for each compliance
option in the database. The user will then
be automatically brought back to the
Edit/Define Compliance Options screen.
The Screen is Largely Blank!
If the user selects a generating unit for which no compliance options have been defined, then
the compliance option screen will be largely blank. Only the two fields discussed above will
be displayed: the Generating Unit field and the Compliance Option Descriptor field, the latter
of which will be blank. By moving the cursor to the Compliance Option Descriptor field and
pressing F2, the user can initiate the "selection list" process that is described in the
preceding instruction charts. After the user selects a compliance option, the screen will be
formatted for data entry (with most of the displayed data values set to zero).
86
-------
Compliance Option Name
The Compliance Option Name is not a field that the user can edit from this screen. It is
determined by the selected Compliance Option Descriptor and comes directly from the Display
Compliance Option Names screen.
Option Life and In-Service Year
The next line in the compliance option screen contains two data items, the Option Life and In-
Service Year. The latter determines the specific year that the compliance option becomes
active; the former dictates how many years the compliance option will last. During the
compliance option's life, STARRSS will calculate the costs and emissions reduction impacts.
For any study years that are prior to the In-Service Year or after the end of the compliance
option's life, STARRSS will assume that there are no costs and no impacts. If a compliance
option's life extends beyond the end of the study period, STARRSS cuts off the annual revenue
requirements and emissions impacts associated with those years that are beyond the end of the
study. Similarly, if the In-Service Year is prior to die beginning of the study, STARRSS will
exclude from its analysis the revenue requirements and emissions impacts of those "pre-study"
years. The details of the cost calculations are discussed in Chapter 9.
Control Technology Removal Efficiency
If the compliance option involves the implementation of a technology that reduces emissions
(e.g., scrubbing, sorbent injection, repowering), the user must specify the Removal Efficiency
of the option. This is the percentage of the unit's existing S02 emissions that will be removed
by the technology. If the generating unit already has existing pollution control equipment, then
STARRSS will use the cross-product of the new technology's removal efficiency and the
existing technology's removal efficiency to calculate the resulting emissions reduction.
For example, assume that a unit currently has pollution control equipment that reduces its
emissions by 50%; its uncontrolled emissions (without the existing system) would be 100,000
tons of S02/year, Therefore, the current "base case" emissions are 50,(XX) tons/year. The utility
that owns the unit is contemplating the installation of a scrubber with a 90% removal efficiency.
STARRSS would calculate the final emissions to be 5,000 tons/year3. The removal efficiencies
would not be additive. If they were, then the scrubber would entirely clean up the remaining
emissions. Instead, STARRSS considers the efficiencies to be multiplicative.
3100,000 tons/year * [1 - 50%] * [1 - 90%]
-------
New Fuel Blend
If the compliance option involves fuel-switching, fuel-blending, or cofiring with natural gas,
then the user must specify the new fuel blend in the lower right-hand area of the screen. On
the left-hand side is a reminder of the unit's existing fuel blend. This cannot be changed on this
screen; it can only be modified from the Affected Unit Operating Factors screen (see page 72).
Altering the New Fuel Blend
Altering the New Fuel Blend |
Instructions
Results
Place the cursor on top of the current fuel
type entry in the Edit/Define Compliance
Options screen and press F2.
STARRSS will display a pop-up selection
list of all of fuels currently defined in the
database.
Move the cursor to the desired selection
and press .
The existing entry will be replaced with
the new selection.
88
-------
Adding a Fuel to the New Fuel Blend
Adding a Fuel to the New Fuel Blend 1
Instructions
Results J
Place the cursor in the next blank New
Fuel Type field in the Edit/Define
Compliance Options screen and press F2.
STARRSS will display a pop-up selection
list of all of fuels currently defined in the
database.
Move the cursor to the desired selection
and press .
The new selection will be added to the fuel
blend. A new set of percentages may now
be defined for the new fuel blend.
Deleting a Fuel from the Fuel Blend
Deleting a Fuel from the Fuel Blend
Instructions
Results
Place the cursor on top of the fuel that is
to be deleted in the Edit/Define
Compliance Options screen and press F2.
STARRSS will display a pop-up selection
list of all of the fuels currendy defined in
the database. At the bottom of the list will
be a "(remove fuel from blend)" selection.
Place the cursor on the "(remove fuel from
blend)" selection and press .
STARRSS will take the fuel out of the
fuel blend. The percentages for the
remaining fuel(s) should be readjusted so
that they sum to 100%.
89
-------
Compliance Costs
The second screen of the set of the Edit/Display Compliance Options screens contains mostly
compliance cost information. As can be seen in Table 6-7 below, the top part of the screen
merely repeats some of the basic information that is input on the first screen. It cannot be
changed on this screen; to do so, the user must return to screen #1 (by pressing ).
The remaining five data items on the screen can be entered as triple forecasts (High, Medium,
and Low), each with an associated probability pointer.
Table 6-7. Edit/Define Compliance Options screen #2
Compliance Options Screen 2 of 3 :^=^=
Generating Unit: BIGC0AL 1
Compliance Option Descriptor:
Compliance Option Name:
Option Life (in years): 30
Capital Costs for
Unit Retrofit (1992 $M):
Increased Non-fuel Variable
O&M Costs (1992 $/MWH):
Increased Annual Fixed
0&M Costs (1992 $M/YR):
Additional Costs (1992 $M/YR)
Escalation (%):
New Capacity Factor (%):
WETFGD1
Wet Limestone Forced Oxidation Scrubber
In-Service Year: 1995
Probability
Pointer
LOW
150.000
1.00
0.350
0.000
0.00
FORECASTS
MEDIUM
160.000
58.0
Enter number
1.10
0.450
0.000
0.00
60.0
HIGH
165.000
1.30
0.580
0.000
0.00
63.0
10
0
F2 Select | F4 delete
F7/F8 prev/next unit
F9/F10 prev/next opt.
Capital Costs for Unit Retrofit
The first of the five principal data items on this screen is the compliance option's projected
capital costs. These should be input in millions of mid-year Base Year dollars and must include
AFUDC (Allowance for Funds Used During Construction, the financial carrying costs of the
construction expenditures). As described in Chapter 9, these costs will be escalated up to the
in-service date (based on the Capital Cost Escalators on the Tax Rate, Escalation Rates, and
Cost of Capital screen). The escalated costs should be equal to the project's book value as of
its in-service date.
90
-------
Increased Non-fuel Variable O&M Costs
The next data item involves the compliance option's Increased Non-fuel Variable O&M Costs.
These costs should be entered in mid-year Base Year dollars/MWH of generation and should
represent the incremental costs of generation that will be incurred as a result of the
implementation of the compliance option. These costs should not include any fuel-price-related
incremental costs, as STARRSS will calculate those costs from other inputs. Also, these costs
should be incremental and therefore should not include any of the unit's standard O&M costs.
This data item will be escalated throughout all of the years of the study (using the Variable
O&M Cost Escalators on the Tax Rate, Escalation Rates and Cost of Capital screen). However,
if the compliance option has a life that is less than the full length of the study, STARRSS will
only consider those costs that will be incurred during the option's active life.
Examples of non-fuel variable O&M compliance costs might be the cost of reagent (for a
scrubbing option), waste disposal (e.g., for scrubber waste or fly ash), or increased water
requirements. This data item should not include the costs of increased power requirements.
If a compliance option is expected to derate a unit's capacity, that should be modelled on the
next screen (Edit/Define Compliance Options screen #3). STARRSS will automatically
calculate the replacement power costs for a compliance option.
Increased Annual Fixed O&M Costs
Like the variable O&M costs, the Increased A nnual Fixed O&M Costs should just represent the
incremental fixed costs of implementing a specific compliance option. They should be
expressed in mid-year Base Y ear millions of dollars/year. They will be escalated throughout
all of the years of the study (using the Fixed O&M Cost Escalators on the Tax Rate, Escalation
Rates and Cost of Capital screen). However, if the compliance option has a life that is less than
the full length of the study, STARRSS will only consider those costs that will be incurred
during the option's active life.
Examples of fixed O&M compliance costs might be the wages of additional personnel who will
be required to operate and maintain an option on an on-going basis (e.g., the operating crew for
a scrubber).
91
-------
Additional Costs
The Additional Costs data item is similar to the Increased Annual Fixed O&M Costs in that it
is expressed in the same terms (millions of dollars/year). However, it is meant to capture any
non-operating expenses (or benefits, which are input as negative values). Such costs might be
external to the utility and could include the societal costs of losing local coal mining jobs or
the costs or benefits of a compliance option's resulting increase or decrease in the emissions of
other, non-S02 pollutants.
New Capacity Factor
The last item on screen #2 is an estimation of the long-term effect that a compliance option's
implementation may have on a generating unit's utilization. For example, if a unit is fuel-
switched to a more expensive compliance coal, its increased cost of generation may change its
placement in the utility's dispatch order and cause it to run less. The user could represent this
situation by entering a value for the New Capacity Factor that is lower than the base case
capacity factor.
The user should leave the New Capacity Factor values at zero if he or she does not
expect the unit's capacity factor to change with the implementation of the compliance
option. STARRSS will use the "base case" capacity factors (entered on the Affected
Unit Operating Factors screen).
It can be very difficult to estimate changes in generating unit utilization brought about by the
implementation of a single compliance option since each unit's capacity factor will be affected
by the options that are implemented at other units. STARRSS Version 2 will eliminate the need
to make such estimations in that it will simulate a utility's dispatch and will dynamically
calculate the new utilization levels of all generating units.
92
-------
Miscellaneous Inputs
Table 6-8. Edit/Define Compliance Options Screen #3
Compliance Options Screen 3 of 3 =====
Generating Unit: BIGCOAL 1
Compliance Option Descriptor:
Compliance Option Name:
Option Life (in years): 30
Capacity Deration (%):
Heat Rate Multiplier:
System Marginal S02
Emissions (LBS/MWH):
Overrides:
Compliance Costs (1992 $/TON)
S02 Removed (Tons):
WETFGD1
Wet Limestone Forced Oxidation Scrubber
In-Service Year: 1995
Probability
Pointer
LOW
3.0
1.0000
24.00
: 0.0
0
Enter number
FORECASTS
MEDIUM HIGH
4.0
1.0000
29.00
0.0
0
5.0
1.0000
35.00
0.0
0
F2 Select
F4 delete
F7/F8 prev/next unit
F9/F10 prev/next opt.
The final Edit/Define Compliance Options screen (shown in Table 6-8 above) contains
miscellaneous data items — namely, user inputs for the effect of the compliance option on the
boiler, and the compliance option overrides.
Capacity Deration
In this field, the user should enter any capacity deration that may be caused by the
implementation of the compliance option. STARRSS uses this input to calculate compliance
costs associated with replacing lost capacity and generation. This input may be negative to
reflect options that increase a generating unit's capacity (e.g., repowering).
The Capacity Deration data item does not affect the STARRSS fuel consumption calculations.
In other words, capacity derations will not translate into decreased fuel consumption. The
rationale for this has come from an investigation of the assumptions that have been used in
several utility compliance filings. A unit is derated by the adoption of a compliance option
frequently because some the unit's capacity is required to power more equipment (such as with
the installation of scrubbers). Such a circumstance translates into a reduction in net generation
but not a reduction in fuel consumption. The unit has less power that it can supply to the
transmission grid, but its fuel consumption is unchanged (all else being equal). If a compliance
93
-------
option is expected to reduce a unit's fuel consumption, the user should model this through an
improvement in the unit's boiler efficiency (see the Heat Rate Multiplier data item, below).
Heat Rate Multiplier
The Heat Rate Multiplier is used to model a change in the unit's boiler efficiency because of
the implementation of the compliance option. For example, fuel-switching to lower quality coal
can result in a loss of boiler efficiency. As it sounds, the Heat Rate Multiplier is used as a
direct multiplier of the unit's base case heat rate. Its default value is one. If the compliance
option improves boiler efficiency, the user may input a value less than one to reflect this.
System Marginal S02 Emissions
This input represents the marginal change in system-wide S02 emissions that will result from
an increase or decrease in the unit's generation by implementation of this compliance option.
Given that a utility must meet its customer load requirements, a decrease in generation at this
unit will have to be offset by an increase in generation at other units. Depending on which
units provide the replacement power (e.g., gas-fired units, coal-fired units, off-system
purchases), this increase in generation may lead to an increase in S02 emissions at some other
plant. STARRSS considers the total impact of a compliance option, both at the affected unit
and throughout the utility system. Therefore, if a compliance option is expected to affect a
unit's capacity or capacity factor, the user must provide STARRSS with information on the
average emissions rate of the units that will provide the marginal generation from elsewhere on
the system. This is the System Marginal S02 Emissions data item (expressed in lbs.
S02/MWh). It will be used to calculate increases (or decreases) in emissions from other
affected units caused by reductions (or increases) in generation from the current unit.
Overrides: Compliance Costs and SOz Removed
If the user already has information on an option's projected costs (in Base Year $/ton of S02
removed) and impact (in average annual tons of S02 emissions reduced), he or she may wish
to bypass all of the STARRSS calculations and use the compliance option "overrides." If the
user inputs values in either of these fields, STARRSS will use these fields and ignore all of the
other cost/impact data items. There is one exception to this. Even if a user has defined
overrides, STARRSS will examine an option's Control Technology Removal Efficiency (on
screen #1) to determine whether the option is eligible for Phase I Extension Bonus allowances
(i.e., if it achieves an S02 removal efficiency equal to or greater than 90%).
If the user does not wish to use the overrides, he or she must leave both of the override input
fields at their default values of zero.
94
-------
Copying a Compliance Option
A user can duplicate any compliance option by following the instructions outlined below. A
compliance option can be duplicated for the same unit (in the event that the user wishes to
define another option with slightly different characteristics) or for a different unit.
Copying a Compliance Option
Instructions
Results
Select and display (on the Edit/Define
Compliance Options screen) the
compliance option that is to be copied.
Press F6.
STARRSS will display a pop-up selection
list of all of the units currently defined in
the database.
I Place the cursor on the unit name of the
I unit to which the compliance option is to
1 be copied. This can be the same unit.
I Press .
STARRSS will display another pop-up
selection list. This one lists those
compliance options that are modelled in
the database (in the Display Compliance
Option Names screen) but are not currently
modelled for the selected unit.
Place the cursor on the option name to
which, the original compliance option's
information is to be copied and press
.
STARRSS will display the new
compliance option.
Although the "copy" function can be very helpful, the user must be careful to make appropriate
changes to (he new option's information (e.g., capital costs, in-service dates, etc.). It is rare to
find compliance options that are perfect duplicates.
95
-------
6.4 DISPLAY COMPLIANCE OPTION NAMES
Table 6-9. Compliance Option Names screen
Compliance Option Names — Screen 1 of 1 —- ¦-¦¦¦ ^
Repowering Construction Period (in Years):
r - Designates Repowering Technology
Descriptor Long Description
(10 chars) (40 chars)
WETFGD1 Wet Limestone Forced Oxidation Scrubber
WETFGD2 Wet Limestone Magnesium Oxide Scrubber
PRBCOAL Switch to Powder River Basin LS Coal
WVCOAL Switch to West Virginia LS Coal
IGCC r Integrated Gasification Combined Cycle
LOWOIL Switch to Low-Sulfur Fuel Oil
Fl Help | F5 delete option | F6 add option | ESC menu
Table 6-9 above shows an example of the Display Compliance Option Names screen. The
Display Compliance Option Names screen provides the user with a list of compliance option
names defined in the database. The primary function of this screen is to provide a labeling
system for compliance options. The user is free to create as many different labels as he or she
wants.
There are two components to each compliance option name: the 10-character Descriptor and
the 40-character Long Description. The Descriptor provides a brief identification of the
compliance option and is used throughout the system whenever space is at a premium. The
Long Description provides a fuller explanation of a compliance activity and is used whenever
possible.
Compliance option names also provide a common label to designate similar or identical
activities at several units, if the user wishes. For example, the user may use the option name
"PRBCOAL" to signify the possibility of fuel switching to Powder River Basin coal. This
compliance activity may be an option at several units. Presumably, the costs and impacts would
differ for each unit implementing the option, but the basic activity may be similar enough to
warrant the same label. Alternatively, the user can keep each compliance options unit-specific,
using a descriptor such as "FGD-BCOAL1" to signify the installation of a flue gas
desulfurization system at "BIGCOAL 1."
96
-------
Re powering Flags
The View Compliance Option Names screen also indicates whether or not options involve
repowering of a unit's existing boiler. In the field at the top of the screen, the Repowering
Construction Period designates the amount of time that any unit must be taken out of service
while its boiler is repowered. This allows STARRS S to calculate the cost and emissions impact
associated with taking the unit out of service during the construction period, along with the
calculation of associated bonus allowances. Another field, the repowering designator, is a
single-character field that is located in front of each compliance option's Long Description. By
pressing the while the cursor is located in this field, the user can toggle the
repowering designator (the letter "r") on or off. If the designator is toggled on, it indicates to
STARRSS that the option is a repowering option according to criteria established in the Clean
Air Act Amendments. For repowering options, STARRSS calculates Phase II Repowering
Bonus allowances and considers the impact on system emissions of having the repowered unit
taken out of service for several years prior to the compliance option's In-Service Y ear. The
period of time that the unit is temporarily out of service is defined by the Repowering
Construction Period noted above.
97
-------
6.5
FUEL INPUTS
Table 6-10. Fuel Inputs screen
Fuel Inputs — Screen 1 of 3
Fuel Type: COAL-ILLN
Description: Illinois Basin High Sulfur Coal
Sulfur Content (Lbs S02/MMBTU): 4.500
Units: Cents/MMBTU
Probability Pointer: 6
Forecasts
LOW
MEDIUM
HIGH
Year
1992
Growth
Cost Rate (%)
120.0 4.00
Growth
Cost Rate {%)
125.0 4.00
Growth
Cost Rate (%)
130.0 4.10
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
Fl Help | Ctrl-F fill | F2 Select | F4 delete fuel | F9/F10 prev/next fuel
The Fuel Inputs screen (shown in Table 6-10 above) is where the user defines all of the fuels
that are currently being consumed by the utility's units, as well as those that potentially could
be consumed. Defining a fuel in STARRSS requires three pieces of information: a fuel
name/label, the fuel's sulfur content, and the fuel's delivered price. In utility operations, the
same fuel can have different delivered prices to different power plants (owing to differences in
transportation costs). Therefore, in STARRSS, the user may have to define one specific type
of fuel as several separate fuels (e.g., PRB-COAL1, PRB-COAL2) to account for the price
differences of consuming this fuel type at different plants.
Fuel Type and Description
The Fuel Type field provides the user with a labelling reference very much like the Unit Names
used to reference generating units. The Description field provides the user with a longer, 40-
character label.
Enter number
98
-------
Selecting a Different Fuel Type
Selecting a Different Fuel Type
Ins tractions
Results
Place the cursor on the Fuel Type field in
the Fuel Inputs screen and press F2.
STARRSS will display a pop-up selection
list of all of fuels currently defined in the
database.
Move the cursor to the desired fuel and
press .
The fuel label, along with associated
emissions rate and price forecasts for that
fuel will appear.
Denning a New Fuel Type
Defining a New Fuel Type
Instructions
Results
Place the cursor on the Fuel Type field in
the Fuel Inputs screen and press F2.
STARRSS will display a pop-up selection
list of all of fuels currently defined in the
database.
Move to the bottom of the list where "add
a new fuel" appears, and press .
A blank template screen will appear, in
which the user can define a new label,
emissions rate, and cost information.
Alternatively, the user can press the F10 key until the end of the STARRSS selection list is
reached. Similarly to the above process, a blank template screen will appear, in which the user
can define a new label, emissions rate, and cost information.
99
-------
Deleting a Fuel Type
STARRSS will not allow a user to delete a fuel if there are any units that consume that fuel in
either their existing fuel blends or in any of their fuel-switching compliance options.
Deleting a Fuel Type
Instructions
Results
Select the fuel that is to be deleted (see
above instructions).
STARRSS will display the fuel and its
associated information on the screen.
Press F4.
STARRSS will check to make sure that the
user has complied with the requirement
noted above. If not, STARRSS will
display a warning message telling the user
the specific unit(s) that still burn that fuel.
Provided that the above requirements have
been satisfied, STARRSS will prompt the
user with a question to ensure that it is the
user's intention to delete the fuel.
Press "Y" (to answer "Yes").
STARRSS will delete the fuel.
Sulfur Content
The term "sulfur content" is something of a misnomer; a better description for this input would
be "expected emissions rate from the consumption of this fuel" (but was shortened to sulfur
content so as to fit on the STARRSS fuel input screen). Technically, a fuel's sulfur content is
the percentage by weight of elemental and organic sulfur that is found in the fuel. However,
for the STARRSS data item, the user should input the SO, emissions rate (in lbs./MMBtu)
which would result from burning the fuel without emissions controls.
Price Forecast
The last fuel input is a triple forecast (High, Medium, and Low) of the fuel's delivered price (in
cents/MMBtu). Similar to the conventions used on other annual price screens, the user may
specify annual price values and/or growth rates. The user may view the values STARRSS
intends to use by pressing .
100
-------
6.6 GENERATING UNIT REDUNDANCE
Table 6-11. Generating Unit Redundance screen
Generating Unit Redundance 1 of 1
Primary Generating Unit: MEDCOAL 1
Redundant Generating Unit(s): MEDCOAL 2
MEDCOAL 3
F1 Help | F2 Select | F4 del redun. | F9/10 prev/next redun.
The Generating Unit Redundance screen (shown in Table 6-11 above) is used to represent units
that are fundamentally identical in size and generating characteristics. Identifying a redundance
will speed (and potentially enhance) STARRSS's optimization processing by allowing it to use
the inputs for one unit at other identical units. For example, assume that MEDCOAL 1,
MEDCOAL 2, and MEDCOAL 3 are identical units and that the user is executing a STARRSS
optimization in which the program has been instructed to find the three top compliance
strategies. If fuel-switching any of these three units was indeed the least-cost strategy,
STARRSS would generate three top strategies that were redundant (namely, fuel-switching
MEDCOAL 1, fuel-switching MEDCOAL 2, and fuel-switching MEDCOAL 3). Since these
three units are the same, the duplication in the results of the STARRSS optimization process
wastes time and space without providing the user with any additional information. If the user
flags these units as redundant units, the STARRSS optimization process will execute more
quickly and will not take up space on the list of top compliance plans with strategies that are
effectively duplications. However, if the user chooses to utilize the unit redundancy features
in STARRSS, the program will ignore all operating and compliance option information for the
redundant units. STARRSS will consider the Redundant Generating Units to be exact carbon-
copies of the Primary Generating Unit (i.e., same capacity, heat rate, capacity factor, compliance
options, etc.). All unit-specific information for the redundant units will still remain in the
database but will be ignored as long as the units are modelled as being redundant.
Primary Generating Unit
This is the generating unit that will be "duplicated."
101
-------
Defining a Primaiy Generating Unit
I Defining a Primary Generating Unit
Instructions
Results
Place the cursor in the Primary Generating
Unit field in the Generating Unit
Redundance screen and press F2.
This will present the user with a pop-up
menu of units in the active database.
Move the cursor to the desired unit and
press .
The unit's name will be placed in the field.
Redundant Generating Unit(s)
The redundant units are those that will be temporarily replaced (during STARRS S execution
processes) with exact copies of the primary generating unit.
Selecting a Redundant Generating Unit
To select a redundant unit, the user should follow the same process as was described to select
the primary unit (described above) except that the user should first place the cursor in the first
blank Redundant Generating Unit field.
A maximum of four redundant units may be defined. Again, STARRSS will not consider
options defined for redundant generating units as long as the redundancy remains in place.
Adding/Defining a New Redundancy
Press the F10 key until the end of the STARRSS selection list is reached. A blank template
screen will appear, in which the user can define a new redundancy.
102
-------
Deleting a Redundancy
Deleting a Redundancy
I Instructions
Results
Select the redundancy that is to be deleted
(by pressing F9/F10 to find the redundancy
to be deleted).
STARRSS will display the redundancy and
its associated information on the screen.
Press F4.
STARRSS will prompt the user with a
question to ensure that it is the user's
intention to delete the redundancy.
Press "Y" (to answer "Yes").
STARRSS will delete the redundancy.
103
-------
6.7 COMPLIANCE OPTION LINKING
Table 6-12. Compliance Option Linking screen
- Compliance Option Linking -- Link 1 of 1
Name of Option Linkage (10 chars): GROUPFGD1
Generating Unit(s): BIGCOAL 1 Technology Type: WETFGD1
BIGCOAL 2 WETFGD1
Group Name (10 chars): BCOAL 1&2
FORECASTS Probability
Reductions in: LOW MEDIUM HIGH Pointer
Capital Costs (1992 $M) : 7.000 8.500 10.000 2
Variable Costs (1992 $/MWH): 0.00 0.00 0.00 0
Annual Fixed Costs (1992 $M) : 0.000 0.000 0.000 0
F1 Help | F2 Select | F4 delete link | F9/F10 prev/next link
There are often economies of scale associated with implementing a compliance option at two
or more units within the same plant For example, if coal handling facilities need to be
modified in order to fuel-switch a unit, those expenditures may not be necessary to fuel-switch
at a second unit within the same plant. The Compliance Option Linking screen (shown in Table
6-12 above) provides the user an opportunity to model this and other situations in which shared
facilities reduces costs per unit.
Each compliance option should be modelled as if it were to be implemented on its own.
However, if economies of scale will reduce the aggregated costs of two or more compliance
options that are implemented at the same time, then the user can reflect these cost savings by
"linking" the options. Defining a compliance option link does not mandate that the options
must be implemented together. It simply instructs STARRSS that there is a cost savings if the
options are implemented together.
104
-------
Name of Option Linkage
The Name of Option Linkage field is where the user can specify a descriptive 10-character label
that will be used to identify the linkage on reports.
Generating Unit(s)
The Generating Unit field is where the user specifies the units at which linked compliance
options can be implemented. A maximum of five units/options may be selected for linking.
Compliance Option
The Compliance Option field is where the user specifies an option (associated with the
generating unit on the same line) that is to be linked with other options.
Group Name
The user may define a brief group name identifying the cluster of generating units that are
involved in the linkage. This name will appear on certain STARRSS reports, along with the
net present value of cost reductions achieved by the linkage.
Reductions in Capital Costs
The first of the three principal data items on this screen is the projected reduction in capital
costs resulting from the linkage. These should be input in millions of mid-year Base Year
dollars.
Reductions in Variable Costs
This data item involves the reduction in each unit's variable O&M costs that will be achieved
by implementing the compliance options together. These cost reductions should be entered in
mid-year Base Year dollars/MWH of generation. Examples of cost reductions might include
maintenance on common facilities (coal handling, dust control, etc.).
105
-------
Reductions in Annual Fixed Costs
This data item should reflect total reductions in fixed costs, in millions of mid-year Base Year
dollars per year resulting from the linkage. Examples of reductions in fixed compliance costs
might be the sharing of an operating crew for scrubbers at two units.
Designating a Compliance Option Linkage
Designating a Compliance Option Linkage J
Instructions
Results J
Place the cursor in the first blank
Generating Unit field in the Compliance
Option Linking screen and press F2.
STARRSS will display a pop-up selection
list of generating units in the active I
database. |
Move the cursor to the desired unit and
press .
The name of the unit will be placed in the
field and STARRSS will display a second
pop-up selection list of all of the
compliance options that are currently
modelled at the selected unit.
Move the cursor to the desired option and
press .
The name of the option will be placed in
the Compliance Option field. The user is
now free to specify the linkages descriptive
labels (the Name of Option Linkage and
the Group Name) and the reductions in
costs that can be achieved by
implementing the options together.
If one or more compliance option linkages are defined in the database, the user can move
between them by pressing the F9/F10 keys (previous/next).
106
-------
6.8 VIEW COMPLIANCE OPTIONS
Table 6-13. View Compliance Options screen
SULFUR POWER & LIGHT
Option
View Compliance Options Screen 1 of 1
Affected
Units
Cons/Renew.
BIGCOAL 1
BIGCOAL 2
MEDCOAL 1
RESIDENT 1
WETFGD1
PRBCOAL
WETFGD2
IGCC
WETFGDl
PRBCOAL
WVCOAL
WVCOAL
Description
Residential: Hi-Effic. Appliance Rebates
Wet Limestone Forced Oxidation Scrubber
Switch to Powder River Basin LS Coal
Wet Limestone Magnesium Oxide Scrubber
Integrated Gasification Combined Cycle
Wet Limestone Forced Oxidation Scrubber
Switch to Powder River Basin LS Coal
Switch to West Virginia LS Coal
Switch to West Virginia LS Coal
F1 Help
ESC menu
In the course of defining compliance options, the user may find it convenient to view an overall
summary of options defined for each unit. The View Compliance Options screen (shown in
Table 6-13 above) provides this opportunity.
Note that incremental conservation and renewable energy programs are also shown on this
screen. This screen is strictly a display screen; there are no data entry inputs (although the user
may make changes in other screens and view this screen to confirm that the desired set of
compliance options have been defined). This screen is similar in format to screens in the
Execute submenu, where the user will combine options into compliance strategies or select
options for STARRSS to consider in its optimization processes.
107
-------
7.0 HOW TO EXECUTE STARRSS
In order to perform a STARRSS run, the user must select the Execute submenu from the Main
Menu. As can be seen in Table 7-1 below, the user has two primary choices:
(1) to examine and evaluate one or more "user-specified" strategies, or
(2) to have STARRSS develop a set of good strategies through one of three different
optimization processes.
Table 7-1. Execute submenu
Files system-Level Info Dnit-Level Info Execute , Reports
I X Execution Parameters
R Reporting Parameters
e Evaluate User Strategies
D Develop STARRSS Strategies
Fl Help | ENTER make selection
Evaluation versus Optimization
The user may either define and evaluate specific compliance strategies or direct STARRSS to
use one of three different optimization processes to determine and evaluate the best compliance
strategies that it can find. On the Execute submenu, the first type of analysis is performed by
selecting Evaluate User-Specified Strategies; the second process is begun by selecting Develop
STARRSS Strategies. Either selection will be followed by a series of screens that enable the
user to specify exactly what will be analyzed during the STARRSS execution.
Before turning to these processes, the Execution Parameters and Report Parameters screens
deserve attention.
108
-------
7.1 EXECUTION PARAMETERS SCREEN
Table 7-2. Execution Parameters screen
== = -- --= Execution Parameters 1 of 1 :==-
Years of Study: 5 Start Year of Study:
^ 1995 (Phase I)
2000 (Phase II)
Detailed Information Flag: 0
(l=on, 0=off)
Discount Costs to Mid-Year? (Y/N): Y
(Y = July 1, N = January 1)
Tax Cost Multiplier: 1.000
Tax Benefit Multiplier: 1.000
Fl Help | | ESC menu
The Execution Parameters screen (shown in Table 7-2 above) allows the user to control various
aspects of the STARRSS execution, the most important of which are the selection of compliance
periods (Phase I or Phase II) and the length of the study.
Phase I or Phase U
The user may select a Phase I or Phase II analysis by moving the cursor to the appropriate
selection in the upper right-hand portion of the screen and pressing the . STARRSS
will display a checkmark to designate the selection. Since this is an "either/or" type of
selection, if the alternate phase had been previously selected, its checkmark will disappear.
Selecting Phase I or Phase II determines the "start year" of the STARRSS analysis — 1995 or
2000, respectively. This is different than the Base Year that is specified on the Tax Rate,
Escalation Rates and Cost of Capital screen. The Base Y ear designates the year in which all
costs are entered in the database and which will be the reference year for all present value
calculations. The Base Year must not come after the start year of the analysis. In other words,
STARRSS will not allow the user to execute a Phase I analysis if the Base Year is later than
1995.
Years of Study
As is described in Chapter 9 (see page 160), a Phase I analysis is based on the supposition that
Phase II never occurs. In other words, a 20-year Phase I run would analyze compliance
109
-------
strategies over the 1995 to 2014 time frame and would only involve those generating units with
non-zero Phase I allowance allocations. A Phase II analysis starts in the year 2000 and
examines all units with Phase II allowance allocations. In either case, the length of the study
period is determined by the Years of Study data item. Since STARRSS Version 1 compresses
its analyses into an average-year framework, an analysis that combined Phase I and Phase II
would entail the simulation of a combined average year that would be nonsensical. This is why
STARRSS will not allow the user to select both Phase I and Phase II for the scope of an
analysis. STARRSS Version 2 will provide a year-by-year analytical capability; this will allow
a user to examine the complete and exact chronology of CAAA compliance requirements.
Phase II-affected units may not be the target of a compliance activity in a Phase I analysis.
STARRSS identifies Phase II-affected as those units, that have Phase II allowances but no Phase
I allowances. If a Phase II-affected unit is to be targeted for emissions reductions during Phase
I, then it will be made a "substitution unit" and will be given Phase I allowances. To model
this in STARRSS, the user should input these Phase I allowances on the Display/Edit Affected
Units screen (under the Unit-Level Info submenu) for this particular unit. STARRSS will then
view this unit as a Phase I-affected unit and will allow it to be addressed in a Phase I analysis
(for a further discussion of Phase I Substitution Plans, see Chapter 11, Page 232).
If the user selects a Phase I analysis, then STARRSS will not allow Phase II units to be
selected for compliance activities.
If the user has previously selected a Phase II analysis, has targeted a Phase II unit in one or
more user-specified strategies (a process that will be described in detail below), and then
attempts to switch to a Phase I analysis, STARRSS will "deactivate" any and all user-specified
strategies that target Phase II unite. In other words, these strategies will stay in the database
for subsequent Phase II analyses but will not be "accessible" for Phase I analyses (quite literally,
STARRSS will not allow the user to position the cursor next to such strategies in the strategy
selection process).
Detailed Information Flag
The Detailed Information Flag enables the user to generate a file (named .DET,
provided that .SDB is the DOS filename for the STARRSS database). This file
provides very detailed information on how STARRSS calculates the costs and S02 reduction
impacts for each compliance option in each evaluated strategy. It should be used with caution
since it can create a massive file of information if the user is not careful. This could potentially
use up all of the user's disk space. To prevent this from happening, the user should never turn
110
-------
this flag on when running many scenario iterations (a process described below). In fact,
STARRSS checks to make sure that this flag is set to zero during large runs; if the flag is
activated, STARRSS will prompt the user with a warning to make sure that the user is aware
that the flag is turned on.
Discount Costs to Mid-Year Flag
STARRSS will automatically discount all costs to the middle of the Base Year (i.e., July 1).
However, if the user wants to discount costs back to the beginning of the Base Year (i.e.,
January 1), the Execution Parameters screen has a flag to instruct STARRSS to perform an
extra six months of discounting: the Discount Costs to Mid-Year flag. If this flag is left as a
"Y", STARRSS will perform the standard process, whereby all present value calculations will
be in mid-year terms. By designating an "N" for this flag, the user will cause STARRSS to
represent such calculations in beginning-of-year terms. Since the Cost of Capita! data item that
is used by STARRSS for present value discounting purposes is always assumed to go from mid-
year to mid-year, STARRSS will assume that the extra six months of discounting will be at the
first year's discount rate. As an example, assume that the user entered the following table of
values for the Cost of Capital on the Tax Rate, Escalation Rates, and Cost of Capital screen:
1992
10% |
1993
11%
1994
11%
1995
12% I
A $100 million expenditure in the middle of 1995 would be discounted back to January of 1992
as $70.3 million — two years (from mid-1993 through mid-1995) at 11%, and a year and a half
(from beginning-1992 through mid-1993) at 10%. The 12% value for 1995 would not be used
in the calculation since it refers to the expected cost of capital from mid-1995 to mid-1996.
Tax Cost and Tax Benefit Multipliers
As is discussed in Chapter 9 (see page 166), STARRSS performs two types of tax calculations
for capital expenditures. One entails the calculation of the tax benefits from accelerated tax
depreciation granted under the current tax code. The other involves an estimation of the tax
costs due to the equity portion of the return that is earned on ratebased expenditures. Both
calculations are approximations for screening purposes only and are not meant to reflect detailed
accounting. In the event that the user wishes to adjust these calculations or turn them off, the
Execution Parameters screen has two multipliers that can be used to accomplish such goals.
To turn off one or both of these calculations, the user can simply set the multiplier(s) to zero.
Ill
-------
7.2 REPORTING PARAMETERS SCREENS
The Reporting Parameters screens are a pair of screens that allow the user to control various
STARRSS reporting functions. These reporting features are under the Execute submenu
(instead of the Reports submenu) because most of these features need to be addressed prior to
executing the program. The first of the screens is shown in Table 7-3 below. To move
between these screens, use the and keys.
Table 7-3. Reporting Parameters - Screen #1
— — — -= Reporting Parameters -- Screen 1 of 2 -• |
Report Title: STARRSS TEST RUN
I Automatically Generate Printer Reports:
^ Compliance Strategies Total Cost Report
Compliance Strategies Unitized Cost Report
Compliance Strategies Detail Report
Compliance Option Report by Strategy
Compliance Option Report by Unit
Compliance Option Ranking Report
Input Summaries
Report and Temporary Files Directory:
C:\STARRSS
Graphics BGI File Directory:
C:\STARRSS\BGI
F1 Help | | ESC menu
Report Title
The user may enter a 40-character report title that will be displayed at the top of each report.
This may be useful in identifying the compliance scenarios and assumptions that go into
different STARRSS analyses.
Automatically Generate Printer Reports
STARRSS can generate two types of output. The first type is represented by the reports that
are displayed on the PC's screen. The second type is an ASCII file that can be sent to a printer.
The user can instruct STARRSS to automatically create printable reports during execution. To
select a report for automatic printing, the user merely places the cursor next to the name of the
desired report and presses the to "toggle" the report feature on; the report feature
can be toggled off by hitting the a second time. A checkmark (V) will appear next
to the report the user has selected. The user may select as many reports for printing as he or
112
-------
she desires. The resulting reports will be placed in a file called .PRT, provided that
.SDB is the DOS filename for the STARRSS database (see Section 8.3.1, Print Files,
for further discussion).
The user cannot print these reports from within STARRSS. The user must print the
ASCII file from DOS through whatever procedures are appropriate for the PC's
printeiynetwork configuration. The user should consult his or her system manager for
details.
Report and Temporary Files Directory
This is the directory location where STARRSS will output all of its report and auxiliary files
from a STARRSS run. By designating different output directory locations for different
databases, a user can keep the PC's individual directories less cluttered and better organized.
STARRSS will not automatically create the designated directoly. The user must do this first
(through the standard DOS make-directory command).
If no directory location is specified in this field, STARRSS will place all output files in the
same directory in which the program itself is located.
Grapltics BGI File Directory
When the user installs STARRSS (see Chapter 2, How to Install STARRSS), the installation
routine automatically creates a STARRSS directory and a STARRSSYBGI subdirectory. The
latter is the default directory for the graphics interface files, a set of files that permit STARRSS
to display graphical results of key outputs (see page 150 for details). If the user places or
moves these "BGI" files to another location, then that new location must be noted in the
Graphics BGI File Directory field in every STARRSS database. Otherwise, the STARRSS
graphics capability will not work.
113
-------
Reporting Parameters Screen #2
The second Reporting Parameters screen (shown in Table 7-4 below) allows the user to control
a variety of other reporting issues.
Table 7-4. Reporting Parameters Screen #2
y— —Reporting Parameters -- Screen 2 of 2 :
Help File Directory: j
C:\STARRSS
Use Compressed Detail Report? (Y/N): N •
Name Optimizer Strategies? (Y/N): Y
Lines per Page: 66
(0 = don't make page breaks)
Enter text
F1 Help | | ESC menu
Help File Directory
Included in the STARRSS delivery is a file named STARRSS.HLP. This is the Help file; its
location must be referenced correctly in each STARRSS database in order for the user to be
able to use the Help facility (activated from within STARRSS by pressing Fl).
The Help File Directory field is where the user must specify the directory location of the Help
file. If the installation program was used, the Help file will be placed in the same directory as
the STARRSS program (e.g., C:\STARRSS). If the program was put in or moved to a directory
other than C:\STARRSS, then the Help File Directory fields in all delivered databases must be
modified.
Compressed Detail Report Flag
The Compliance Strategy Detail Report is one of the system's most important reports, providing
a complete breakdown of all of the compliance options in each compliance strategy that
STARRSS analyzes. The user has the flexibility to control the format of this report. In its
"uncompressed" format, the report provides details about base case conservation, bonus
allowances, and compliance option linkage cost savings. In its "compressed" format, the report
is made a little tighter by dropping these references.
114
-------
If the user enters "Y" in the Compressed Detail Report field, STARRSS will compress the
report, dropping references to base case conservation, option linkages, and bonus allowances.
The base case conservation and option linkages will still be included in STARRSS's analysis
and the report's bottom-line totals, but they will be dropped from the list as individual line
items. Therefore, the list of total costs and impacts will not add up. Also, instead of reporting
bonus allowances on a separate line, STARRSS will include those allowances in the total
impacts for the relevant compliance activities (see Section 8.1.4, Compliance Strategies Detail
Report, for further discussion). The result is a somewhat shorter report that is preferable to
some users.
The default value for this field is "N." The flag does not need to be set prior to execution. The
user is free to change the flag after a STARRSS run to obtain the desired formatting of the
report.
Name Optimizer Strategies Flag
In the course of optimization, STARRSS attaches names to the strategies it develops and ranks
them based on least expected cost. STARRSS will simply attach the names "Plan 1," "Plan 2,"
etc., to each strategy that it saves. However, these names have little significance to the user.
Entering "Y" for this flag will tell STARRSS to attach names to the strategies that it develops
from its optimization processes. The name for each strategy will be a reference to the two
compliance options resulting in the largest S02 tonnage reduction for each strategy. While this
feature provides more descriptive names for STARRSS strategies, it may also create duplicate
names if several strategies use the same top two options. In these cases, the user will have to
view the Compliance Strategy Detail Report and the Compliance Option Report bv Unit to get
a better idea of which options comprise each strategy.
Lines Per Page
As was discussed above, the output from STARRSS can be viewed on the screen and/or sent
to an ASCII file for later printing. The Lines Per Page data item informs the report generator
where to put page breaks in the printable ASCII files it generates. The default value is 66; the
user may wish to change this if the point size on the printer fonts causes awkward breaks in
printed reports.
115
-------
7.3 EVALUATE USER STRATEGIES
As mentioned earlier, one of the two execution options provided in STARRSS allows the user
to define specific compliance strategies that he or she would like to evaluate. STARRSS will
"cost out" these strategies and will report the expected value, standard deviation, and range for
a variety of output results. A detailed explanation of these results can be found in Chapter 8.
By choosing the Evaluate User Strategies selection on the Execute submenu, the user will be
presented with the User Strategy screen (see Table 7-5 below):
Table 7-5. User Strategy screen
Strategy Name:
»SUMMARIZE AND EXECTJTE«
= .-===— User Strategy # 1 of 3
SCRUB BIGCOAL 1 & 2
<1 = ACTIVATED [by hitting Spacebar)
(one per unit)
Affected Units
Cons./Renew.
BIGCOAL 1
BIGCOAL 2
Option
RESIDENT 1
J WETFGD1
PRBCOAL
WETFGD2
IGCC
1 WETFGDl
PRBCOAL
WETFGD2
IGCC
Description
Residential:
Hi-Effic. Appliance Rebates
Wet Limestone Forced Oxidation Scrubber
Switch to Powder River Basin LS Coal
Wet Limestone Magnesium Oxide Scrubber
Integrated Gasification Combined Cycle
Wet Limestone Forced Oxidation Scrubber
Switch to Powder River Basin LS Coal
Wet Limestone Magnesium Oxide Scrubber
Integrated Gasification Combined Cycle
¦-¦¦¦ 1 ¦ = Prespecify User Strategies Screen 1 of 1
Fl Help | F2 Select | F4 delete strategy | F9/F1Q prev/next strategy
The screen provides a list of all of the affected units in the database for which the user has
modelled compliance options. These options are listed under each unit's name. If the list spans
several screens, the and keys can be used to move to different parts
of the list. The user may define a compliance strategy by selecting specific compliance options
at any or all units.
116
-------
Selecting a Compliance Option
J Selecting a Compliance Option
I Instructions
Results
Move the cursor down the User Strategy
screen until the cursor is next to the
desired selection and press the .
A checkmark will appear where the cursor
is placed.
The can be used to "toggle" the checkmark on and off; therefore, to erase a
checkmark, simply place the cursor on the checkmark and press .
The user can only select one compliance option per unit If the user tries to select a
second option for any unit, STARRSS will erase the checkmark from the previously
selected compliance option.
=
If the user wants to perform two different compliance options at a unit, these options should
be combined and modelled as a single option. For example, if the user wanted to represent a
situation where a unit was to be scrubbed and fuel-switched, he or she could model this on the
Edit/Define Compliance Options screen (see Chapter 6, page 82). This combined option would
then show up on the User Strategies screen and could be selected as a single option.
At the top of the list are any incremental conservation programs or renewable energy resources
that are modelled in the database (e.g., "RESIDENT 1" in Table 7-5 above). The user can
either select or not select each of these resources, in that they each represent a compliance
activity in themselves. Below this list is the generating unit list, which may extend onto several
screens (depending on the number of compliance options that are modelled in the database).
Modelling a Specific Compliance Strategy
To model a specific strategy, merely select the desired compliance options and type in an
appropriate Strategy Name at the top of the screen. This second step is not mandatory but is
strongly recommended; otherwise, it will be difficult to tell the strategies apart on many of the
STARRSS reports. There is nothing that the user needs to do to "freeze" or save the strategy;
117
-------
like all of the other STARRSS inputs, it is automatically recorded as it is typed in and can be
changed by the user at any time.
After making any substantive changes to an already-defined strategy, be sure to change
the Strategy Name. Failing to do so could make for some rather confusing reports.
Similar to other multiple-menu input screens, the user-specified strategies are in a list. At the
top of the screen, the user will see a designation of where he or she is in the list, as well as the
number of strategies currently defined in the database (e.g., "User Strategy #1 of 3," as
displayed in Table 7-5 above). As is noted on the instruction line at the bottom of the screen,
pressing the F9 and F10 keys will move the user back and forth, respectively, through this list.
Alternatively, a user can place the cursor on the Strategy Name field and press F2; STARRSS
will display a selection list of the names of all currently defined strategies.
Defining a New Compliance Strategy
To define a new compliance strategy, the user can merely press the F10 key (Next Strategy) to
advance beyond the end of the current list or press F2 and select . This will transfer the user to the
Strategy Summary screen, which, like its name suggests, presents a summary of all of the user-
specified strategies (see Table 7-6 below):
118
-------
Table 7-6. Strategy Summary screen
—-¦== Strategy Summary Screen 1 of 1 —
Number of Scenario Iterations per Strategy: 250
[0 = do not iterate, use mean forecast]
Summary of User Strategies: i/ = ACTIVATED
/ User Strategy #1: SCRUB BIGCOAL 1 & 2
BIGCOAL 1 Wet Limestone Forced Oxidation Scrubber
BIGCOAL 2 Wet Limestone Forced Oxidation Scrubber
/ User Strategy #2: CONSERVE AND SWITCH
RESIDENT 1 Residential: Hi-Effic. Appliance Rebates
BIGCOAL 1 Switch to Powder River Basin LS Coal
BIGCOAL 2 Wet Limestone Magnesium Oxide Scrubber
/ User Strategy #3: SCRUB BIGCOAL 1 (ENHANCED)
BIGCOAL 1 Wet Limestone Magnesium Oxide Scrubber
F1 Help | SPACE check (uncheck) | ESC menu
Each strategy is displayed with its name and a complete list of all compliance options that are
selected for that strategy. The notation of "User Strategy #1" merely reflects where the strategy
is in the list of user-specified strategies and does not indicate anything about the cost, ranking,
or desirability of the strategy.
Just because the user has defined and set-up a strategy does not mean that the strategy must be
evaluated in a STARRSS run. The user has the flexibility to select any combination of
strategies for a particular evaluation. The strategies can be selected very much the same way
that compliance options were selected on the previous screen. The user merely moves the
cursor down the screen to the desired strategies and presses the to place a
checkmark next to them. Pressing the again toggles a checkmark off.
Number of Scenario Iterations
At the top of the screen, the user specifies the Number of Scenario Iterations. This data item
determines the number of different scenarios or situations that will be simulated for each
compliance strategy. By designating a zero, the user can direct STARRSS to only run one
scenario for each strategy; that scenario will use the mean (i.e. weighted average) forecast value
for each and every data item in the database. Otherwise, by specifying a non-zero value for the
Number of Scenario Iterations, the user will indicate how many STARRSS iterations should
occur for each scenario. The term "scenario iteration" refers to the process of (1) selecting
specific data values for each STARRSS data item, and (2) "costing out" a particular compliance
strategy. During each iteration, STARRSS will "randomly" select which forecast (Low,
119
-------
Medium, or High) will be used for each data item during the program's calculation of a
compliance strategy's cost. Although STARRSS uses random numbers to influence its selection
process, the program takes into account the user-specified probabilities associated with the
forecasts for each data item. This process is described in detail in Chapter 3 (see page 28).
As an abbreviated explanation, STARRSS will generate a random number (between 1 and 100)
for each data item. That random number will be used to select each data item's forecasted value
during a scenario iteration. Assume that the user has specified a 30%/50%/20% set of
probabilities to go along with the Low, Medium, and High forecasts for a data item (e.g., the
capital cost for a particular scrubber at a specific generating unit). STARRSS will "stack" the
Low, Medium, and High forecasts' probabilities on a continuous scale from 1 to 100 and
thereby define "zones" of numbers that corresponded to the Low, Medium, or High situations.
Therefore, the Low zone will be from 1 to 30, the Medium zone from 31 to 80, and the High
zone will be from 81 to 100. Defining such zones ensures that a random number between 1
and 100 will have a 30% chance of falling in the Low zone, a 50% chance of being in the
Medium zone, and a 20% chance of. being in the High zone — the exact probability distribution
defined by the user for the specific data item.
Assume now that during a given scenario iteration, STARRSS1 random number generator
outputs the number "35." This would fall in the Medium zone, so STARRSS would select the
Medium forecast value for the capital cost of the particular scrubber in question. STARRSS
would perform the same process with all other data items and determine the cost of the
compliance strategy for this particular scenario Iteration. For the next scenario iteration, the
random number generator might output the number "93." This would put the scrubber capital
costs in the high range. The next iteration might see a random number of "17," leading to the
selection of the Low forecast value for the scrubber's capital cost. Through repeated iterations,
the total cost of a particular compliance strategy will assume many different values (one for
each iteration) that will reflect the strategy's cost under various combinations of economic and
operational events. This is called a Monte Carlo simulation. The cost from any single iteration
may not be representative of the strategy's expected cost. However, if the user runs this type
of simulation through enough iterations, the distribution of the costs can yield two important
results. First, the "expected value" (or average) of the cost distribution provides a better
indication of the likely cost of a compliance strategy than a "static" estimate that is predicated
on a fixed set of economic and operational assumptions. Second, the range or variance of the
distribution of costs provides the user with an idea of the level of economic risk that is inherent
in the compliance strategy.
The Number of Scenario Iterations field on the Strategy Summary screen is where the user
designates how many cost simulations STARRSS will perform for each selected compliance
strategy.
120
-------
RECOMMENDED PROCEDURE
In order to generate a reasonable set of STARRSS simulation results, the user should set
the Number of Scenario Iterations data item to 200 or more.
Except for "test" runs (where the user is merely experimenting with the system), executing
STARRSS for only a few iterations is strongly discouraged. Any conclusions drawn from a
very sparse distribution of results would be virtually worthless. Besides, the STARRSS costing
process is quite fast. Of course, computing speed is machine-dependent; but on a standard PC
286 (without a math coprocessor), processing 200 iterations for an average utility's compliance
strategy takes less than 2 minutes.
Selecting more iterations will provide results that are more refined. The maximum Number of
Scenario Iterations is 999. The user is encouraged to experiment with this data item to assess
the sensitivity of results to the number of iterations and to determine a point of diminishing
returns. For example, for a particular utility system, the user may find that running STARRSS
for any more than 350 iterations does not appreciably change the model's results. However, this
cutoff point will depend on what is being modelled and will differ between databases.
»>EXECUTE«<
The user is now ready to execute STARRSS and evaluate the selected compliance strategies.
Merely position the cursor on »>EXECUTE«< and press . A "pop-up" window will
be displayed in the middle of the screen that will report on where STARRSS is in its
processing. STARRSS will spend a few seconds initializing information and performing "up-
front" calculations that will speed up the processing of the different scenario iterations.
Messages like "Calculating PV (present value) factors" will appear in the pop-up window. As
STARRSS begins costing out the compliance strategies, it will display information about how
far along it is in this task, reporting the percent of the task that has been completed. Once this
display reaches 100%, STARRSS will begin generating reports » a task that is performed in
two passes (as is reported in the pop-up window). The reports (and several auxiliary files) are
stored in the PC's directory from which STARRSS was invoked, unless the user specifies a
different directory for these files (as was discussed earlier with the Report Parameters screen,
Pages 112-113). After these files have been written to disk, STARRSS has completed its
execution and returns the user to the Main Menu. From there, the user can move over to the
Reports area and view the results of the run (see Chapter 8 for details about the STARRSS
reports).
121
-------
7.4 DEVELOP STARRSS STRATEGIES (OPTIMIZATION)
As mentioned earlier, STARRSS can be run in one of two modes:
(1) evaluating specific compliance strategies, and
(2) optimizing and developing its own strategies.
In the latter case, the user is leaving it up to STARRSS to find the best strategies. This process
is initiated by selecting Develop STARRSS Strategies on the Execute submenu. The user will
be presented with the Develop STARRSS Strategies screen displayed in Table 1-1 below.
Table 7-7. Develop STARRSS Strategies screen
i Develop STARRSS Strategies -- Screen 1 of 1
>DEFINE ACTIVE COMPLIANCE OPTIONS<—
Number of Strategies to be Evaluated/Saved: 5
Number of Scenario Iterations per Strategy: 400
[0 = do not iterate; use mean forecast]
Number of Iterations for Heuristic #1: 200
Estimated Execution Time
>EXECUTE FULL OPTIMIZATION -4 minutes
>EXECUTE HEURISTIC SOLUTION #1< -7 minutes
>EXECUTE HEURISTIC SOLUTION #2< -5 minutes
Enter number
F1 Help | | ESC menu
This is the screen from which the user will execute the STARRSS optimization process;
however, for explanatory purposes, a subsequent screen will be described first.
When STARRSS displays the Develop STARRSS Strategies screen, the cursor will
automatically be placed on the —>DEFINE ACTIVE COMPLIANCE OPTIONS<-- field. By
pressing , the user will be presented with a subsequent screen: the Select Compliance
Options screen (as shown in Table 7-8 below).
122
-------
Table 7-8. Select Compliance Options screen
Select Compliance Options Screen 1 of 2
/ = ACTIVATED FOR CONSIDERATION
Optimization time: -19 minutes
Affected
Units
RESIDENT 1
BIGCOAL 1
BIGCOAL 2
Option
4 Do Nothing
4 Implement
/ Do Nothing
4 WETFGD1
4 PRBCOAL
WETFGD2
4 IGCC
4 Do Nothing
4 WETFGDl
4 PRBCOAL
WETFGD2
Description
Do not implement this cons/renew, program
Residential: Hi-Effic. Appliance Rebates
Leave the unit as is
Wet Limestone Forced Oxidation Scrubber
Switch to Powder River Basin LS Coal
Wet Limestone Magnesium Oxide Scrubber
Integrated Gasification Combined Cycle
Leave the unit as is
Wet Limestone Forced Oxidation Scrubber
Switch to Powder River Basin LS Coal
Wet Limestone Magnesium Oxide Scrubber
Fl Help
SPACE check (uncheck)
ESC menu
As the name suggests, this is the screen where the user can select which compliance options
will be available for consideration by the STARRSS optimization process. Similar to the User
Strategy screen described in the previous section (in the discussion of the evaluation of user-
specified strategies), the screen displays a complete listing of all of the compliance options that
are modelled in the database; again, viewing the entire list may require pressing the
and keys. This time, however, the user is not limited to selecting only one
compliance option for a generating unit. Since the user is defining all possible compliance
activities that he or she wants STARRSS to consider in developing a least-cost plan, no such
constraint is necessary. Of course, when STARRSS develops specific strategies, it will not
consider implementing more than one compliance option at any one unit at the same time. For
example, if the user has designated that a unit can be scrubbed or fuel-switched, STARRSS will
not try to implement both at the same time. If scrubbing and fuel-switching simultaneously are
an option, the user must model this as a third, distinct compliance option.
The Select Compliance Options screen lists all of the compliance options that arc modelled in
the database. The screen allows the user to define the subset of compliance options that
STARRSS will consider during the optimization process. Therefore, just because a compliance
option is modelled in the database does not mean that it must be included in the scope of an
optimization run. By the same rationale, the user need not delete compliance options from the
database just to keep them from being considered in a STARRSS run. A STARRSS database
may have many compliance options modelled in it, while the user may choose to select a few
during any particular STARRSS execution.
123
-------
The user can select (or unselect) any particular compliance option using the same "checkmark"
process that has been discussed on previous screens. Simply place the cursor next to the
desired compliance option and press the . The will "toggle" a
checkmark on and off, designating the option as having been selected or unselected,
respectively.
At the top of the screen, the user will see an estimation of the time that STARRSS will take
to perform a Full Optimization run for all of the selected compliance options. A Full
Optimization run considers every possible combination of selected compliance options.
Naturally, the more options that a user selects, the more combinations that are possible, and the
longer the process will take. In fact, the "size" of the optimization problem increases
exponentially as more and more options are selected. If the user wishes to examine many
compliance options at many generating units, the Full Optimization may take too long. In this
case, the user can pick one of two heuristic methodologies that are much faster. However, they
take shortcuts and cannot be guaranteed to produce ihe optimal compliance strategy. In any
case, the results from a heuristic optimization run could be used to determine which compliance
options should be considered in a Full Optimization run. All three optimization processes are
discussed briefly at the end of this chapter and in detail in Chapter 9 (see discussion beginning
page 182).
To determine the Full Optimization time estimate, STARRSS monitors which compliance
options have been selected and automatically changes the estimate every time the list is
modified. STARRSS determines the time estimate by combining the information on which
options the user has selected with its knowledge of the speed of the user's computer — which
it obtains by running some trial calculations at the beginning of the session (when the user first
invokes STARRSS).
Do Nothing
One important difference exists between the list of compliance options on the evaluation's User
Strategies screen and the list on the optimization's Select Compliance Options screen; the latter
includes the option of "doing nothing." In most compliance decisions, this is always an implicit
option. In some, however, it is not. For example, in some states, the legislature has required
that some utilities scrub specific units. The utilities are free to select the scrubbing technology
they want to employ, but they must scrub. Therefore, "doing nothing" at these units is not an
option. In order to make sure that STARRSS develops a set of desirable compliance strategies
that each include the mandatory scrubbing of these units, the user must have a means of
"forcing the program's hand." This is done by unselecting the Do Nothing option (i.e., toggle
the checkmark off, using the ). The user may model and activate several different
scrubbing technologies, and since the Do Nothing option is deactivated, STARRSS will be
forced to pick one of the technologies. As another example, perhaps a utility has already made
a firm decision regarding compliance at a specific unit but is still exploring additional measures
124
-------
at other units to come into system-wide compliance. To model this situation, the user can
activate that specific option at the particular unit and deactivate all other options for that unit
(including the Do Nothing option). This will ensure that the fixed decision is "imbedded" in
each and every strategy that STARRSS considers in its optimization process. Essentially, that
fixed decision becomes a foundation from which STARRSS will build different compliance
strategies.
By pressing the key, the user will return to the Develop ST A RRSS Strategies screen
(displayed previously in Table 7-7 and repeated on the following page), from which the
optimization run is executed.
The three different optimization approaches are listed in the lower portion of the screen. n
estimate of the execution time for each of the approaches appears on the right. The accuracy
of these estimates is not guaranteed. It is impossible to predict the actual time that any of the
optimization processes will take. Their execution times are dependent on various "decisions"
that are made during the optimization process. The outcomes of these decisions cannot be
known prior to the optimization run. Therefore, the time estimates are merely meant to provide
the user with a ball park approximation (plus or minus 50%). If the size of the optimization
problem is small enough, it is entirely likely that the Full Optimization will be faster than the
heuristic algorithms. However, as the number of compliance options increases, the heuristic
approaches can offer considerable time savings relative to the Full Optimization process and can
provide some insights into which compliance options are cost-effective and which are not.
An optimization run is initiated by moving the cursor to one of the three EXECUTE selections
and pressing . Prior to doing that, the user should consider the optimization parameters
that are displayed in the upper portion of the screen.
125
-------
Table 7-7. Develop STARRSS Strategies screen
Develop STARRSS Strategies — Screen 1 of 1 =
>DEFINE ACTIVE COMPLIANCE OPTIONS<--
Number of Strategies to be Evaluated/Saved: 5
Number of Scenario Iterations per Strategy: 400
[0 = do not iterate; use mean forecast]
Number of Iterations for Heuristic #1:
200
Estimated Execution Time
-->EXECOTE FULL OPTIMIZATION*:--
4 minutes
-->EXECUTE HEURISTIC SOLUTION #!<--
-7 minutes
>EXECUTE HEURISTIC SOLUTION #2<
-5 minutes
Enter number
F1 Help
ESC menu
Optimization Parameters
In all three processes, STARRSS will develop a set of top strategies. As was discussed in
Chapter 1, there is no truly optimal compliance strategy because different strategies have
different levels of risk associated with them. Judging compliance strategies purely on the
basis of least-cost (with no regard for their potential economic risks) ignores a major part
of the planning decision. Different individuals and organizations have different tolerances for
risk. Some may want the least-cost solution, even if it comes with considerable risks.
Others may be willing to pay a premium (similar to insurance) to have a lower-risk plan. The
cost/risk trade-off is a decision-making issue that STARRSS can help the user explore and
understand. However, the program will not judge or determine the appropriate trade-off for the
user. Only the user can make that decision.
Therefore, in its optimization processes, STARRSS will not search for the optimal plan. Rather,
the system will identify a set of top low-cost compliance strategies that warrant further analysis.
The number of compliance strategies that will be saved (and subsequently sent through the
multiple-scenario evaluation process) are determined by the data item: Number of Strategies
to be Evaluated/Saved. Although this value can be any positive number up to 99, the user
should probably keep the number below 20 for most runs. Saving and evaluating too many
strategies can take a great deal of run time, consume inordinate amounts of disk memory, and
clutter the STARRSS reports.
126
-------
Optimization and Heuristic Processes
In all three optimization processes (i.e., Full Optimization, Heuristic #1, and Heuristic #2), the
same general sequence of events occur. The discussion here is supplemented by a more detailed
explanation in Chapter 9 (see page 182). First, STARRSS develops a master list of different
compliance strategies. Each time the program develops a strategy, STARRSS costs out the
strategy (based on the mean value of each input data item), and places the strategy in its
appropriate position in the list such that the costs are ranked in ascending order. Depending on
the optimization process selected, this procedure may consider billions of different compliance
strategies.
Next, STARRSS takes the top, lowest-cost "X" number of plans (where "X" is the user-
designated Number of Strategies to be Evaluated/Saved) and runs them through the full
multiple-scenario evaluation process.
The Number of Scenario Iterations per Strategy works the same way that it does on the
Evaluate User Strategies screen; it designates the number of iterations that will be performed
for each compliance strategy during this evaluation phase of the optimization run.
The last optimization parameter, the Number of Iterations for Heuristic #/, pertains only to the
first heuristic optimization process. It is explained in more detail in Chapter 9 (see page 184).
Generally, a number in the range of 50 yields good results in a reasonable execution time.
127
-------
8.0 REPORTS, GRAPHS, AND AUXILIARY FILES
STARRSS has three reporting capabilities.
First, the program provides the user with a half dozen different reports that display
output information from a STARRSS run, as well as several reports summarizing the
STARRSS' inputs.
Second, STARRSS can depict several key outputs in a graphical representation.
Third, several auxiliaiy files are generated that can provide more detailed information
and/or can be imported into other programs (e.g., Lotus 1-2-3).
All three of these capabilities are discussed in this chapter. The chapter's first section reviews
the STARRSS reports and discusses exactly how each output is calculated. The second section
examines the graphical features in STARRSS, and the third section covers the auxiliary files.
An example of one of the types of graphs that STARRSS can produce is shown in Figure 8-1
below:
Figure 8-1. Graph Comparing Two Compliance Strategies
Comparison of Total Cost Distributions
t«f T*| Coapttliei StrtttgtM
J J
31
21
IS
11
I
III
ill
+ 5
-------
but also carries much greater volatility in costs than the "Scrub BigCoal 1" strategy.
Before exploring the program's graphical and reporting capabilities, however, the user must
understand the general report generation process.
As mentioned in Chapter 4 (Section 4.2, Saving a Database), STARRSS will generate output
flies that have the same root name as the STARRSS database. In other words, if the user loads
a database called .SDB and runs STARRSS, a set of files will be created with the
names .XXX, where XXX stands for a variety of filename extensions. These files will
be either on the user's floppy disk (if STARRSS was invoked from the floppy disk) or on the
user's hard disk (if, as is recommended, STARRSS is run from the hard disk). By default, the
files will be placed in the same directory where STARRSS resides, although the user can
designate another location for these files. This report relocation feature is discussed in the
Report Parameters section (see Section 7.2); it should be used because it will help the user keep
the main STARRSS directory better organized.
Where Are My Reports?
To avoid potentially frustrating situations, the user should understand the specific process that
STARRSS uses when it displays output reports. If the user wants to view a particular report,
he or she can merely select it from the Report submenu by typing the letter that is to the left
of the report name or by placing the cursor on the report name and pressing .
STARRSS will search in the relevant directory for the specific file that contains information for
that report.
In determining the name of the report file that it must search for, STARRSS takes the
root name of the current database and adds the appropriate extension.
Therefore, suppose that a user loaded a database called UTILITY.SDB, ran STARRSS,
subsequently loaded a new database called UTILITY2.SDB, and then tried to view the reports
from the initial STARRSS execution. STARRSS would complain that it could not find any
report files. This is because it would be looking for files that matched the current STARRSS
database (UTILITY2.SDB). Since the user has not run STARRSS with that database, no report
files exist that have the UTILITY2 root name.
-------
If the user wants to view reports that were generated from a previous run, the user must
load the STARRSS database that was associated with those reports (i.e., that has the
same root name).
The user should be aware, however, that just because a database and a set of reports have the
same root name, the results in the reports do not always come from an execution of that
database. A user could load a database, make some data changes (e.g., change the forecasts of
allowance prices), run STARRSS (and thereby generate report files), and quit from STARRSS
without saving the database. The report files and the original database would have the same
root name. Therefore, during a subsequent STARRSS session, the user could load the database
and view the reports; however, the user would no! be able to reproduce the results displayed
in the reports by rerunning STARRSS with the original database (since that database would not
include the data changes). The user may want to routinely save databases just before executing
STARRSS so that this type of discontinuity is prevented. In addition, if the user is examining
multiple cases, he/she may want to save the database each time and to make sure that a different
root name is designated for each case.
To recap, there are two critical points to remember:
1) When reports are generated (by running STARRSS), the system will give the
report files the same root name as the current database. If reports with this root
name already exist, they will be overwritten.
2) When reports are requested (by selecting them on the Reports submenu),
STARRSS will look for report files with the same root name as the current
database.
With a little planning, the user should have no problem with running STARRSS and viewing
the results. In the event that the user would like to see results that were produced during a
previous session, he or she has to first load the database with the same root name.
8.1 REPORTS
The output results of a STARRSS execution can be viewed by moving the cursor to the final
category of the Main Menu, the Reports submenu. This submenu (shown in Table 8-1 below)
provides the user with access to all of the system's output reports, input summaries, and
graphical capabilities.
130
-------
Table 8-1. Reports Submenu
Piles
System-Level Info Unit-Level Info Execute Reports
w Warnings
T Compliance Strategies Total Cost Report
D Compliance Strategies Detail Report
~ Graph of Compliance Statistics
s Compliance Option Report by Strategy
u Compliance Option Report by Unit
R Compliance Option Ranking Report
z Compliance Strategies Unitized Cost Report
z Input Summaries
F1 Help
| ENTER make selection
Before exploring each of the reports, the user should be aware of some basic reporting features.
8.1.1 Reporting Features
As mentioned earlier in the chapter, STARRSS produces files that contain the output results
from the STARRSS execution process. These files are in ASCII format. Although they can
be imported into word-processing systems or sent directly to a printer in their current form, they
do not include any descriptive notations (titles, column headings, etc.) and would be difficult
to interpret. STARRSS provides the user with a specific process for generating fully-formatted
reports that can be sent to a printer. These printable reports will still be in ASCII format but
will include all of the descriptive notations that the user sees on the computer screen when
viewing the reports from within STARRSS.
Printable Reports
Users may prefer to generate printable reports in order to view STARRSS results, for several
reasons. First, printing out a copy gives the user a permanent, hard-copy version. Second,
when viewing a report on a computer screen, the user is limited to seeing only a few dozen
lines at a time. Printed reports give the user a full page of text. (The user can control the
number of lines generated between page breaks on the printer reports — see Section 7.2, Report
Parameters screen.)
All desired reports will be clustered into one file, called .PRT, where .SDB is
the name of the current STARRSS database. The file of printable reports is created through one
131
-------
of two procedures. One is to view reports in STARRSS through the conventional process (i.e.,
selecting them one at a time from the Reports submenu). When the user sees a report that he
or she would like to have printed out, he or she can merely press the F3 key. If the printable
report file does not already exist, pressing F3 will create the file and put a fully-formatted
version of the report that is on the screen into the file. If the printable report file does already
exist, STARRSS will ask the user if the new report should be appended to the information that
is already in the file or if the new report should overwrite the existing file.
A second way to create a printable reports file is for the user to designate which reports should
be included in the file prior to execution. This is done on the Report Parameters screen (see
Section 7.2).
Printing the Printable Reports File
Neither of the two methods that the user can select to create the printable report file
actually causes die file to be printed.
To print out the ACSII printable reports file, the user must issue a print command from the
DOS environment. PC print protocols and printer configurations are machine-specific. Since
the printing process is different from one machine to the next, it would have been difficult and
problematic to design a STARRSS PRINT capability. If the user does not know how to print
ASCT files from his or her PC, the user must consult his or her computer system's manager.
However, most PCs have a fairly straightforward procedure for printing ASCII files from within
the DOS environment.
Automatic Advance
One last feature deserves note before proceeding to the individual reports. For all of the input
data and execution screens, the user had to press in order to exit a screen. This is
still a valid exit procedure for the report screens; however, another option exists. If the user
presses , STARRSS will exit the current report and automatically move the cursor
selection to the next report. If the user wishes to view that report, he or she merely has to press
again. This feature allows the user to quickly advance through the listing of reports
without the inconvenience of typing different keystrokes. This feature is only available in the
Reports category.
132
-------
8.1.2 Warnings Screen
The Warnings selection is at the top of the list in the Reports submenu. At the beginning of
a STARRSS execution, the program will check all of the appropriate data inputs and stop if it
finds any information that must be changed or clarified. It will display a pop-up window that
will alert the user that one or more warnings have occurred and the execution has been stopped.
Provided that the data has passed this initial set of checks, STARRSS may still encounter
unusual calculations or occurrences during the execution. These will also generate warning
messages. In this case, STARRSS will display a pop-up window at the end of the execution
to notify the user that problems were encountered. Regardless of whether or not the problems
occurred during the data check phase or during full execution, STARRSS will store the warning
message(s) in the Warnings report. This was placed at the top of the Report submenu because
it is the first screen that the user should always check. If warnings have been generated, the
results displayed in the subsequent reports may be invalid. The user should identify the nature
of the problem, correct it, and rerun the execution.
Many of the warning messages are self-explanatory. However, since they were designed to be
brief and to fit on one line, some may require further explanation. Appendix B contains a full
listing and description of every possible STARRSS warning message.
8.1.3 Compliance Strategies Total Cost Report
The Compliance Strategies Total Cost Report ranks each compliance strategy according to
expected cost, one of the fundamental criteria that compliance planners seek to minimize. The
report also lists information about the standard deviation of costs, as well as allowance
transactions used by each strategy to achieve the target reduction. An example of the
Compliance Strategies Total Cost Report is presented below.
133
-------
Table 8-2. Compliance Strategies Total Cost Report
Compliance Strategies Total Cost Report
SULFUR POWER & LIGHT
Target Reduction 88363 Tons
Evaluated 9/10/1992 at 16:22; Phase I (1995-1999) run with 250 iterations
Plan
Rank
Expected Value Allowance Transactions
of Total Cost Purchase Costs Purchases/(Sales) # of
($ million) ($ million) (tons of S02) Options
1 SWITCH AT BIGCOAL 1 & 2
203 [ 92] (28) [ 14]
(21152) [ 8833] 2
2 SCRUB BIGCOAL 1 (ENHANCED)
213 [ 17] (12) [ 14]
(9109) [10083] 1
3 SCRUB BIGCOAL 1 & 2
215
[ 59]
(128) [ 40] (100293) [17026] 2
-- End of Data
{) = Negative Values [] = Standard Deviation
* = Allowance transactions meet or exceed user-specified limits
ESC Main Menu j PgUp/PgDn View Report | F3 Print Report
Database Name and Execution Statistics
At the top of every STARRSS report, the user will find the Database Name (as input on the
Display/Edit Affected Units screen ~ e.g., SULFUR POWER & LIGHT) and the execution
statistics (namely, the date and time of execution, Phase I or Phase II run, the range of years
in the study, and the number of iterations).
Target Reduction
In the upper right-hand corner of each STARRSS report, the user will find the Target
Reduction. This is the expected value of the projected average annual difference between the
utility's current S02 emissions and its allowance allocation.
The leftmost column of this report displays the rank given to each compliance strategy, based
on the least expected cost. As the table above demonstrates, strategies are listed in rank order.
The Strategy Name (that the user specified in the User Strategies screen) appears next to the
rank.
Plan Rank
134
-------
Expected Value of Total Cost
The next column over lists the Expected Value of the Total Cost, which is calculated as the
average of the distribution of costs that were derived from the multiple scenario iterations of
the execution simulation. The total cost is the present value of all compliance costs over the
course of the study.
The standard deviation of the total cost is shown in brackets to the right of the total cost. This
measures quantitatively the risk of each compliance strategy.
Allowance Transactions
The Allowance Transactions associated with each compliance strategy are reported in two
respects:
(1) the expected purchase costs (dollars), and
(2) the expected annual volume (number of allowances).
The purchase cost value represents the present value of the cost of allowance transactions
throughout the study period (expressed in millions of dollars). A value in parentheses indicates
revenues from sales (i.e., "negative purchases").
Purchase volume refers to the average annual number of allowances purchased (and is expressed
in tons of S02 per year); values in parentheses again represent sales volume.
The standard deviation for both of these values is provided in brackets to the right of the value.
If the expected value of the number of annual allowances transacted exceeds the limitations
specified by the user in the A llowance Parameters screen, an asterisk will appear next to the
annual tonnage value in the Purchases column.
Number of Options
The Number of Options flag shows the user how many options (and units) were involved in a
particular compliance strategy. For a breakdown of the contribution of each option to the
strategy's total cost and allowance impact, the use may consult the Compliance Strategies Detail
Report and the Compliance Option Report by Strategy (discussed in sections 8.1.4 and 8.1.5
below).
135
-------
8.1.4 Compliance Strategies Detail Report
The Compliance Strategies Detail Report lists information similar to the Compliance Strategy
Total Cost Report described in Section 8.1.3 above. However, this report breaks down each
compliance strategy into its component options, listing cost and impact contributions of each
option to the overall expected result. As with the Total Cost Report, each strategy is listed in
ranking order according to expected cost. An example of the Compliance Strategies Detail
Report is shown below.
Table 8-3. Compliance Strategies Detail Report
===== Compliance Strategies Detail Report
SULFUR POWER & LIGHT Target Reduction 88363 Tons
Evaluated 9/10/1992 at 16:22; Phase I (1995-1999) run with 250 iterations
Strategies
1: SWITCH AT BIGCOAL 1 & 2
BIGCOAL 1 PRBCOAL
BIGCOAL 2 WVCOAL
Base Conservation
bonus allowances
Allowance purchases (sales)
Totals for strategy 1 :
Total
Cost($M)
115
116
(28)
203
Impact(tons)
54469
54589
313
146
(21152)
88364
Average
$/ton
502
515
313
542
Allowance transactions meet or exceed user-specified limits
ESC Main Menu
PgUp/PgDn View Report
F3 Print Report
Strategies
The leftmost column of this report displays the rank given to each compliance strategy, based
on the expected cost. The Strategy Name (that the user specified in the User Strategies screen)
appears next to the rank. Below this name, each option associated with the strategy is listed.
Note also that bonus allowances associated with an option are delineated in a separate line
directly below the option. The last option line of each strategy lists the allowance purchases
(or sales) necessary to meet the utility's reduction target.
If the user wishes to see an abbreviated version of this report, he or she can activate the
Compressed Detail Report flag on the Report Parameters screen (see Section 7.2).
136
-------
Total Cost
This column lists the expected value of the total cost (the net present value of all costs over the
period of the study) for each compliance option. The totals given at the bottom of each strategy
should correspond to the totals given in the Compliance Strategy Total Cost Report described
in Section 8.1.3 above. The breakdown of costs includes cost savings associated with linkages
defined in the Compliance Option Linking screen.
Impact
This column lists the expected annual impact, in tons of S02 reduced, for each option in the
strategies evaluated. The total Impact for each strategy will always correspond to the utility's
Target Reduction unless a strategy exceeds the user-specified allowance trading limitations. If
the expected value of the number of annual allowances transacted exceeds the limitations
specified by the user in the A How once Parameters screen, an asterisk will appear next to the
annual tonnage value in the allowance purchases row.
If allowance purchases exceed user restraints, an asterisk will appear next to the impact value
given on the Allowance Purchases line; the total Impact should still equal the Target Reduction,
however. Allowance sales, on the other hand, will never exceed user-specified limits. If a
strategy involves overcontrol without selling all of the extra allowances, total Impact will exceed
the Target Reduction by the amount of extra llowances the utility was unable to sell.
Average $/ton
This column presents the average unitized cost per ton of S02 removed by each option. The
unitized cost of an option is equal to its levelized costs (over the entire study period) divided
by its average annual impact (again, over the entire study period) — see page 181 for details
about the calculation of unitized costs. Because the value presented here is unitized, it is not
a quotient of the Total Cost and Impact columns.
8.1.5 Compliance Ontion Report hv Strategy
This report lists each option by strategy, presenting data on the ranges in costs and impacts
associated with each option. By presenting ranges, this report supplements the Compliance
Strategy Detail Report shown in Section 8.1.4 above. An example of the Compliance Option
Report bv Strategy is presented below.
137
-------
Table 8-4. Compliance Option Report by Strategy
Compliance Option Report by Strategy
SULFUR POWER & LIGHT Target Reduction 88363 Tons
Evaluated 9/10/1992 at 16:22; Phase I (1995-1999) run with 250 iterations
Strategies
: SWITCH AT BIGCOAL 1 & 2
BIGCOAL 1 PRBCOAL
BIGCOAL 2 WVCOAL
Mean
$/ton
502
515
SCRUB BIGCOAL 1 (ENHANCED)
BIGCOAL 1 WETFGD2 559
3: SCRUB BIGCOAL 1 & 2
BIGCOAL 1 WETFGD1
BIGCOAL 2 WETFGD1
End of Data
384
504
$/ton
Range
258-943
201-1172
409-797
287-653
350-789
Mean
Tons
Removed
54469
54589
97014
95329
92869
Range
50398-57737
45552-59474
69501-114424
65462-107389
70487-107736
ESC Main Menu
PgUp/PgDn View Report | F3 Print Report
Mean $/ton
This column presents the average unitized cost per ton of S02 removed by each option. These
values should correspond to the Average $/ton values presented in the Compliance Strategy
Detail Report, discussed in Section 8.1.4 above.
$/ton Range
This column presents the range in unitized costs for each option. The range represents the high
and low values generated during the scenario iteration process.
Mean Tons Removed
This column presents the mean tons of SOz removed by each option, including the impact of
bonus allowances, if applicable.
Mean Tons Removed Range
This column presents the range in tons of S02 removed by each option. The range represents
the high and low values generated during the scenario iteration process.
138
-------
8.1.6 Compliance Option Report bv Unit
The Compliance Option Report bv Unit lists information similar to the Compliance Option
Report bv Strategy but reports the information on a unit-by-unit rather than a strategy-by-
strategy basis. This report will list all options considered by the most recent
Evaluation/Optimization run. An example of this table is shown below.
Table 8-5. Compliance Option Report by Unit
Compliance Option Report by Unit
SULFUR POWER & LIGHT Target Reduction 88363 Tons
Evaluated 9/10/1992 at 16:22; Phase I (1995-1999) run with 250 iterations
Unit/Option
Unit: BIGCOAL 1
WETFGDl
PRBCOAL
WETFGD2
Unit: BIGCOAL 2
WETFGDl
WVCOAL
End of Data
Mean
$/ton
384
502
559
504
515
$/ton
Range
287-653
258-943
409-797
350-789
201-1172
Mean
Tons
Removed
95329
54469
97014
92869
54589
Range
65462-107389
50398-57737
69501-114424
70487-107736
45552-59474
ISC Main Menu | PgUp/PgDn View Report | F3 Print Report
Mean $/ton
This column presents the average unitized cost for each option. These values correspond to the
Average $/ton values presented in the Compliance Strategy Detail Report, discussed in Section
8.1.4 above.
$/ton Range
This column presents the range in unitized costs for each option. The range represents the high
and low values generated during the scenario iteration process.
Mean Tons Removed
This column presents the mean tons of S02 removed by each option, including the impact of
bonus allowances, if applicable.
139
-------
Mean Tons Removed Range
This column presents the range in tons of S02 removed by each option. The range represents
the high and low values generated during the scenario iteration process.
8.1.7 Compliance Option Ranking Report
The Compliance Option Ranking Report lists compliance option by unit, and gives the rank of
each plan in which the compliance option appears. This report can help the user assess the
importance of a compliance strategy to the top plans. For example, if a compliance option
appears in the top three out of six strategies, it may be integral to the utility's least-cost
compliance strategy. An example of this report is shown below.
Table 8-6. Compliance Option Ranking Report
Compliance Option Hanking Report
SULFUR POWER & LIGHT Target Reduction 88363 Tons
Evaluated 9/10/1992 at 16:22; Phase I (1995-1999) run with 250 iterations
Plan Rank Where
Unit/Option Description Option Appears
Unit: BIGCOAL 1
WETFGD1 Wet Limestone Forced Oxidation Scrubber 3
PRBCOAL Switch to Powder River Basin LS Coal 1
WBTFGD2 Wet Limestone Magnesium Oxide Scrubber 2
IGCC Integrated Gasification Combined Cycle NOT CHOSEN
Unit: BIGCOAL 2
WETFGD1 Wet Limestone Forced Oxidation Scrubber 3
PRBCOAL Switch to Powder River Basin LS Coal NOT CHOSEN
WVCOAL Switch to West Virginia LS Coal 1
End of Data
+ = More plans than those listed used this compliance option
ESC Main Menu | PgUp/PgDn View Report | F3 Print Report
Unit/Option
This column lists each option under the unit for which the option was defined. Units are listed
in the order in which they appear in the Display/Edit Affected Units screen.
140
-------
Description
This description corresponds to the detailed description specified by the user in the Edit/Define
Compliance Options screen.
Plan Rank Where Option Appears
This column lists the rank of each compliance strategy in which the option appears. If, during
an optimization run, STARRSS does not choose an option the user has selected for
consideration, the words "NOT CHOSEN" will appear in this column. If the option appears
in more than five plans, a "+" sign will appear at the end of the string of numbers in this
column to signify that there were more plans that used the option.
8.1.8 Compliance Strategies Unitized Cost Report
The Compliance Strategies Unitized Cost Report reflects the cost of each compliance strategy
in terms of tons of S02 removed (i.e. cost per unit). Table 8-7 below shows an example of this
report.
Table 8-7. Compliance Strategies Unitized Cost Report
Compliance Strategies Unitized Cost Report =====— . ¦¦ - =
SULFUR POWER & LIGHT Target Reduction 88363 Tons
Evaluated 9/10/1992 at 16:22; Phase I (1995-1999) run with 250 iterations
Average
Marginal
Plan Plan
$/ton
$/ton
Rank Name
Removed
Removed
1 SWITCH AT BIGCOAL 1 & 2
542 [
218)
574 [
200]
2 SCRUB BIGCOAL 1 (ENHANCED)
583 [
55]
559 [
56]
3 SCRUB BIGCOAL 1 & 2
582 [
137]
509 [
88]
End of Data
() = Negative Values [] = Standard Deviation
ESC Main Menu | PgUp/PgDn View Report | F3 Print Report
Plan Rank
The leftmost column of this report displays the rank given to each compliance strategy, based
on the least expected cost. As the table above demonstrates, strategies are listed in rank order.
141
-------
Plan Name
The name of the strategy provided by the user in the Execute submenu appears next to the rank.
Average S/ton Removed
This column presents the average unitized cost for each strategy. This value corresponds with
the value on the "Strategy Totals" line of the Compliance Strategy Detail Report (discussed in
Section 8.1.4). The standard deviation of this value is presented in brackets to the right.
Maiginal $/ton Removed
This column presents the marginal unitized cost for each strategy. This value corresponds with
the value of the most expensive compliance option in the Compliance Strategy Detail Report
(discussed in Section 8.1.4). Because the marginal cost values do not include the costs of
allowance transactions, the Average $/ton Removed may in some cases be higher than the
Marginal $/ton Removed. The standard deviation of this value is presented in brackets to the
right.
Input Summaries
The Input Summaries report allows the user to view his or her inputs to the Unit-level Info
screens more concisely. The user can quickly determine if he/she needs to edit the inputs.
The table below presents the Input Summaries submenu.
142
-------
Table 8-8. Input Summaries submenu
Files system-Level Info unit-Level Info Rxecute Reports
w Warnings
t Compliance Strategies Total Cost Report
D Compliance Strategies Detail Report
Q Graph of Compliance Statistics
a Compliance Option Report by Strategy
U Compliance Option Report by Unit
R Compliance Option Ranking Report
z Compliance Strategies Unitized Cost Report
x Input Summaries
G Generating Unit Operating Factors
D Display Generating Units
R Retirement and Commission Years
Xi Option Life, Efficiency, and Fuel
c Compliance Option Costs
d Option Derate and Overrides
F Fuels
F1 Help | ENTER make' selection |
For triple-forecast data itenia, the Input Summaries report the weighted average
value of these data items (based on the probability distribution that is
associated with each data item).
The following sections will briefly describe each selection from the Input Summaries
submenu.
143
-------
Generating Unit Operating Factors
This report summarizes the inputs to the Generating Unit Operating Factors screens. An
example of this screen is shown below.
Table 8*9. Generating Unit Operating Factors Input Summary
Generating Unit Operating Factors
SULFUR POWER & LIGHT
STARRSS TEST RUN
S02 Rem.
Var O&M
S02
Capacity
Unit Name
Effic.
($/MWH)
Rate
Fuel
% blend
Factor
BIGCOAL 1
0.0
4.7
4.500
COAL-ILLN
100.0%
58.8
BIGCOAL 2
0.0
5.7
4.500
COAL-ILLN
100.0%
66.2
MEDCOAL 1
0.0
6.3
4.500
COAL-ILLN
100.0%
61.7
MEDCOAL 2
0.0
6.3
4.500
COAL-ILLN
100.0%
61.7
MEDCOAL 3
0.0
6.3
4.500
COAL-ILLN
100.0%
61.7
MEDCOAL 4
81.8
•5.9
0.819
COAL-ILLN
100.0%
61.1
SMALLOIL 1
0.0
4.1
1.000
HIGHOIL
100.0%
2.5
SMALLOIL 2
0.0
2.9
1.000
HIGHOIL
100.0%
3.8
SMALLOIL 3
0.0
4.0
1.000
HIGHOIL
100.0%
3.6
End of Data
ESC Main Menu | PgUp/PgDn View Report | F3 Print Report
For each data item that is input in the form of a triple forecast, the report displays the weighted
average value (based on the probability distribution that is associated with that data item).
The S02 rate is calculated from the unit's existing fuel blend and pollution control technology.
The fuel type that is displayed on the screen is the first fuel in the unit's existing fuel blend.
It is displayed along with its fuel blend percentage to let the user know whether there are any
other fuels consumed at the unit.
The capacity factor is a weighed average over all three forecasts for the commission year of
the unit, the base year of the database, or 1995, whichever comes latest.
Display Generating Units
This report shows affected generating units in the same format as they appear in the
Display/Edit Affected Units screen. From this report screen, though, the user may generate a
print file to make hardcopy reports (see Section 8.1.1, Reporting Features). An example of this
report is shown below.
144
-------
Table 8-10. Display Generating Units Input Summary
= Display Generating Units
SULFUR POWER & LIGHT
STARRSS TEST RUN
Baseline Calculated
Unit
Capacity
Heat
Heat
S02 Emis.
Allowances
Name
(MW)
Rate
(TBTUs)
(tons)
Phasel
Phasell
BIGCOAL 1
650.
0
10000
26.700
75293
36500
14000
BIGCOAL 2
650.
0
10000
27.300
84761
37000
14500
MEDCOAL 1
350.
0
10500
32.320
44656
44000
17500
'MEDCOAL 2
350.
0
10500
32.320
44656
44500
18000
I MEDCOAL 3
350.
0
10500
32.320
44656
45000
18000
'MEDCOAL 4
350.
0
10400
32.260
7984
0
17500
SMALLOIL 1
50.
0
13800
0.37C
77
0
200
SMALLOIL 2
50.
0
13600
0.640
115
0
330
SMALLOIL 3
80.
0
13500
1.040
171
0
600
End of Data
ESC Main Menu | PgUp/PgDn View Report | F3 Print Report
Retirement and Commission Years
This report summarizes the inputs for retirement and commission years from the Generating
Unit Operating Factors screen. An example of this report is shown below.
Table 8-11. Retirement and Commission Years Input Summary
Retirement and Commission Years
SULFUR POWER & LIGHT
STARRSS TEST RUN
Unit Commission Retirement
Name Year Year
BIGCOAL 1 1978 2025
BIGCOAL 2 1980 2025
MEDCOAL 1 1966 2020
MEDCOAL 2 1966 2020
MEDCOAL 3 1966 2020
MEDCOAL 4 1976 2025
SMALLOIL 1 1942 2005
SMALLOIL 2 1950 2015
SMALLOIL 3 1958 2020
End of Data
ESC Main Menu | PgUp/PgDn View Report | F3 Print Report
145
-------
Option Life, Efficiency, and Fuel
This report summarizes the inputs for compliance option life, S02 removal efficiency, and new
fuel (as applicable) from the Edit/Define Compliance Options screen #1. An example of this
report is shown below.
Table 8-12. Option Life, Efficiency, and Fuel Input Summary
— Option Life, Efficiency, and Fuel
SULFUR POWER & LIGHT
STARRSS TEST RUN
Life
In-Service
Removal
New
Unit
Option
(years)
Year
Efficiency
Fuel
% blend
BIGCOAL 1
WETFGD1
30
1995
90.0
_
PRBC0AL
30
1995
0.0
COAL-PRB
100.0%
WETFGD2
30
1995
94.1
IGCC
30
2003
94.9
BIGCOAL 2
WETFGD1
30
1995
89.8
PRBCOAL
30
1995
0.0
COAL-PRB
100.0%
WVCOAL
30
1995
0.0
CNT-APP
100.0%
MEDCOAL 1
WVC0AL
30
1995
0.0
CNT-APP
100.0%
MEDCOAL 2
WVCOAL
30
1995
0.0
CNT-APP
100.0%
MEDCOAL 3
WVCOAL
30
1995
0.0
CNT-APP
100.0%
SMALLOIL 1
L0W0IL
30
2000
0.0
LOWOIL
100.0%
SMALL0IL 2
LOWOIL
30
2000
0.0
LOWOIL
100.0%
SMALLOIL 3
LOWOIL
30
2000
0.0
LOWOIL
100.0%
End of Data
ESC Main Menu | PgUp/PgDn View Report | F3 Print Report
For the data item that describes a compliance option's Removal Efficiency, the report displays
the weighted average value (based on the probability distribution that is associated with that
data item).
For fuel-switching options, the report displays the first fuel in the new fuel blend (and its
associated percentage of the new fuel blend). Dashed lines reflect the fact that the compliance
option does not involve a change in fuels.
146
-------
Compliance Option Costs
This report summarizes the inputs for capital costs, non-fuel variable O&M costs, fixed O&M
costs, additional costs, and new capacity factor (as applicable) from the Edit/Define Compliance
Options screen #2. An example of this report is shown below.
Table 8-13. Compliance Option Costs Input Summary
SULFUR POWER & LIGHT
STARRSS TEST RUN
Compliance Option Costs
Capital
Var. O&M
Fixed
Additional
New Capa
Unit
Option
($M)
($/MWH)
O&M ($M)
Costs
Factor
BIGCOAL 1
WETFGD1
157.000
1.11
0.454
0.000
60.0
PRBCOAL
7.260
0.19
0.119
0.000
58.0
WETFGD2
190.500
1.38
0.605
0.000
60.4
IGCC
446.000
3.30
1.200
0.000
63.2
BIGCOAL 2
WETFGD1
164.750
1.30
0.493
0.000
66.9
PRBCOAL
14.700
0.76
0.280
0.000
59.4
WVC0AL
9.100
0.09
0.105
0.000
62.3
MEDCOAL 1
WVCOAL
3.500
1.60
0.256
0.000
(same)
MEDC0AL 2
WVCOAL
3.500
1.60
0.256
0.000
(same)
MEDCOAL 3
WVCOAL
3.500
1.60
0.256
0.000
(same)
SMALLOIL 1
LOWOIL
2.000
0.00
0.000
0.000
(same)
SMALLOIL 2
LOWOIL
3.000
0.00
0.000
0.000
(same)
SMALLOIL 3
LOWOIL
2.500
0.00
0.000
0.000
(same)
End of
Data
ESC Main Menu | PgUp/PgDn View Report | F3 Print Report
Since all of the data items on this report are input as triple forecasts, the report displays the
weighted average values (based on the probability distribution that is associated with each data
item).
For New Capacity Factors, STARRSS will note that an option's New Capacity Factor is the
same as the generating unit's current one if the user did not specify otherwise.
147
-------
Option Derate and Overrides
This report summarizes the inputs for compliance option derations, heat rate adjustments, and
override inputs (as applicable) from the Edit/Define Compliance Options screen #3. An
example of this report is shown below.
Table 8-14. Option Derate and Overrides Input Summary
SULFUR POWER & LIGHT
STARRSS TEST RUN
Unit
BIGCOAL 1
BIGCOAL 2
MEDCOAL 1
IMEDCOAL 2
MEDCOAL 3
SMALLOIL 1
SMALLOIL 2
SMALLOIL 3
End of
1
Option
WETFGD1
PRBCOAL
WETFGD2
IGCC
WETFGD1
PRBCOAL
WVCOAL
WVCOAL
WVCOAL
WVCOAL
LOWOIL
LOWOIL
LOWOIL
Data
Option Derate and Overrides
Deration
3.8
1.7
3.9
-16.8
3.9
3.5
1.7
0.0
0.0
0.0
0.0
0.0
0.0
Heat Rate
Adjust
1.0000
1.0200
1.00C0
1.1680
1.0000
1.0680
1.0000
1.0600
1.0600
1.0600
1.0000
1.0C00
1.0000
Marginal
S02
OVERRIDES:
Cost Impact
27.70
26.50
17.00
19.30
23.80
25.80
25.80
19.00
19.00
19.00
0.00
0.00
0.00
ESC Main Menu
PgUp/PgDn View Report
F3 Print Report
Since all of the data items on this report are input as triple forecasts, the report displays the
weighted average values (based on the probability distribution that is associated with each data
item).
The dashed lines represent that overrides are not specified. If the user does specify overrides
for a compliance option, the other data fields in the Input Summaries for that compliance option
will be filled with dashes.
148
-------
Fuels
This report summarizes inputs to the Fuel Inputs screen, diplaying each fuel's sulfur content and
price forecast. Price forecasts resulting from user inputs are shown for every fifth year of the
study from the start year. An example of this report is shown below.
Table 8-15. Fuels Input Summary
===== - — - ¦- Fuels
SULFUR POWER & LIGHT
STARRSS TEST RUN
S content
Price
Forecasts
Fuel Name
(Ibs/MMBTU)
1995
2000
2005
2010
COAL-ILLN
4.500
141.0
171.7
209.1
254.7
COAL-PRB
1.000
173.3
211.1
257.1
313.1
CNT-APP
1.400
159.6
194.9
238.2
291.0
L0W0IL
0.200
440.1
536.0
652.8
795.0
HIGHOIL
1.000
392.8
478.4
582.6
709.6
End of Data
ESC Main Menu | PgUp/PgDn View Report | F3 Print Report
149
-------
8.2 GRAPHS
Results generated in STARRSS evaluation and optimization runs can be viewed graphically.
Furthermore, graphic results from several strategies can be overlaid, allowing the user to easily
compare probability distributions of costs and impacts between several strategies. Viewing
distributions of results also allows the user to address the relative risk of compliance strategies
and the structure of the distributions (for example, is the distribution peaked in the center, or
skewed to the right or left, etc.). Finally, although STARRSS cannot print graphs directly, it
does allow user to save the basic data used to build the graphs; this data can be converted into
printable graphs using standard graphics programs. The first part of this section discusses
general graphing features. The last five sections will discuss each individual graph selection.
8.2.1 Graphing Features
For each compliance strategy saved by the most recent Execute run, STARRSS can graphically
show five distribution results: total cost, average unitized cost, marginal cost, total allowances
purchased, and total cost of allowances. The graphic selection submenu is shown in Table 8-16
below.
Table 8-16. Graph of Compliance Statistics submenu
Files
system-Level Info
onit-Level Info
Execute
Reports
w
i
s
a
Total Cost of Compliance Strategies
Average Unitized Cost ($/ton)
Marginal Unitized Cost ($/ton)
Purchased Allowances
Total Cost of Purchased Allowances
Warnings
Compliance Strategies Total Cost Report
Compliance Strategies Detail Report
Graph of Compliance Statistics
tion Report by Strategy
tion Report by Unit
tion Ranking Report
rategies Unitized Cost Report
es
ameters
F1 Help | ENTER make selection
The user can move through this list with the arrow keys, and choose the graph by pressing
. A second menu will pop-up listing all of the compliance strategies evaluated in this
run. An example of this pop-up menu is presented in Table 8-17 below. From the pop-up
menu, the user selects the strategies he or she wants to view by pressing the to
toggle each strategy on or off. A check mark (V) will appear, indicating that a particular
150
-------
strategy will be graphed. If the user checks more than one strategy, all strategies will appear
on the graph overlaid. Pressing from the pop-up menu will generate the graphs the
user wishes to view. If no strategies have been marked, the strategy underneath the cursor will
be graphed.
Table 8-17. Graph of Compliance Statistics - Strategies Pop-up Menu
Files
System-Level Info
Unit-Level Info
Execute
Reports
w
T
S
G
Total Cost of Compliance Strategies
Average Unitized Cost ($/ton)
Marginal Unitized Cost ($/ton)
Purchased A (—Choose strategies to display—
1 SCRUB BIGCOAL 1 & 2
SCRUB BIGCOAL 1 (ENHANCED)
/ CONSERVE AND SWITCH
Return or Esc
Warnings
Compliance Strategies Total Cost Report
Compliance Strategies Detail Report
Graph of Compliance Statistics
tion Report by Strategy
tion Report by Unit
tion Ranking Report
rategies Unitized Cost Report
Total Cost
F1 Help | ENTER make selection
To summarize, the user must follow these three steps to view a graph:
1) Select Graph of Compliance Statistics from the Reports submenu;
2) Choose which graph to view from the list of five available graphs; and,
3) Mark (with the selection process) which compliance
strategies should appear on this graph.
While the graphics appear quickly and are sharp, some features are common to all of the
graphs. First, the names of the compliance strategies do not carry through into the graphics
mode. Each strategy is denoted in the legend simply as "Strategy 1," "Strategy 2," and so on.
The number of the strategy corresponds to the position of the strategy in the Compliance
Strategies Total Cost Report (or the Plan Rank, see Section 8.1.4). The user may find it helpful
to jot the strategy names down before viewing graphs.
As mentioned previously, graphs cannot be printed directly from STARRSS. Instead STARRSS
will create an output file that can be easily used to create graphs from a standard
151
-------
spreadsheet/graphics program. If the user presses the key, STARRSS will prompt the
user to name the file; the user then names the file and presses . STARRSS creates an
ASCII file with one column of numbers representing the values for the x-axis, and one column
of numbers for each strategy graphed. Each column is labelled at the top; the x-axis column
receives the label "x-axis," and each strategy receives the same label given in the graph legends
(i.e., "Strategy 1"). It is up to the user to import the file into a graphics program and provide
the labels and other structures necessary for printable graphs.
When creating graphs from a standard graphics program, the user should be aware of two
features about the data file created by STARRSS:
1) The x-axis values are relatively accurate but may not be in an appropriate
scale (i.e. $100 million may be represented as 1, or .1, etc.)
2) The values given for each compliance strategy represent relative
probabilities that the strategy will take on a certain value. STARRSS
represents these probabilities as fractions of 100 (percentages). Each
column of values corresponding to the compliance strategies should
therefore sum to 100 (or very close).
152
-------
Figure 8-1 below presents a graph generated from the STARRSS test run shown in this
document. The graph was generated using Lotus 1-2-3.
Figure 8-1. Graph Comparing Two Compliance Strategies
Comparison of Total Cost Distributions
?*e CMpiiise# Strit«plri
35
10
15
fl
3
e
sn
761
~ Comirrt k 5*11 cl
Figure 8-1 exhibits an example of the cost versus risk trade-off STARRSS is designed to
capture. In this example, the "Conserve & Switch" strategy carries the potential for lower costs,
but also carries much greater volatility in costs than the "Scrub BigCoal 1" strategy.
153
-------
8*2*2 Total Cost of Compliance SiiHtc^ics
This graph presents probability distributions for the total cost data presented in the Compliance
Strategies Total Cost Report (see discussion in Section 8.1.3). Pressing any key will return the
user to the STARRSS Graph of Compliance Statistics submenu. Pressing F3 will generate a
file for creating graphics (see Section 8.2.1).
8.2.3 Average Unitized Cost ($/ton)
This graph presents probability distributions for the average unitized cost data presented in the
Compliance Strategies Unitized Cost Report (see discussion in Section 8.1.8). Pressing any key
will return the user to the STARRSS Graph of Compliance Statistics submenu. Pressing F3 will
generate a file for use in creating graphics (see Section 8.2.1).
8.2.4 Marginal Unitized Cost ($/ton)
This graph presents probability distributions for the marginal unitized cost data presented in the
Compliance Strategies Unitized Cost Report (see discussion in Section 8.1.8). Pressing any key
will return the user to the STARRSS Graph of Compliance Statistics submenu. Pressing F3 will
generate a file for use in creating graphics (see Section 8.2.1).
8.2.5 Purchased Allowances
This graph presents probability distributions for the total allowances purchased (or sold)
presented in the Compliance Strategies Total Cost Report (see discussion in Section 8.1.3). A
line marks the point of zero purchases/sales, and indicates which direction represents purchases
and which direction represents sales. In addition, if the user has specified constraints on
allowance transaction volume, this graph will mark the point of the constraint. This will allow
the user to determine how the constraint affects the utility's participation in the allowance
market. Pressing any key will return the user to the STARRSS Graph of Compliance Statistics
submenu. Pressing F3 will generate a file for use in creating graphics (see Section 8.2.1).
8.2.6 Total Cost of Purchased Allowances
This graph presents probability distributions for the total cost of purchased allowances presented
in the Compliance Strategies Total Cost Report (see discussion in Section 8.1.3). Pressing any
key will return the user to the STARRSS Graph of Compliance Statistics submenu. Pressing
F3 will generate a file for use in creating graphics (see Section 8.2.1).
154
-------
8.3 AUXILIARY FILES
This section will briefly discuss a number of auxiliary files created by STARRSS in the course
of execution runs and report production. There are three types of files created by STARRSS
(and denoted by their filename extensions) that the user should know about: printable files
(.PRT), detailed information files (.DET), and raw data files for importing into spreadsheet
programs (.RAW).
8.3.1 Print Files
Whenever a user views a report, he or she can generate a printable form of that report by
pressing F3 (see Reporting Features. Section 8.1.1, for further discussion). STARRSS will
prompt the user to indicate whether this report should overwrite a previously existing report file,
or append this file to it. The report files created in this way have the filename .PRT,
where represents the root name of the STARRSS database.
8.3.2 Detail Files
If the user activates the Detailed Information Flag from the Execute submenu (see page 109),
STARRSS will create a file with information breaking down the exact components of costs and
impacts associated with compliance options under evaluation (capital costs, O&M costs,
purchased power costs, etc.). This is a flat ASCII file with the filename extension ".DET." The
user can view this file by exiting to DOS and typing "MORE < .DET" where
.SDB is STARRSS database that was used in the program execution. As an example,
a section of this file is shown in Table 8-18 on the next page.
8.3.3 Raw Data Files
Each time STARRSS evaluates strategies, it creates a file of the output results denoted by the
filename ".RAW" (where represents the root name of the STARRSS database).
This file contains the data generated by each scenario iteration and can be imported into
spreadsheet programs for further evaluation or for generating graphs or reports. If the user
chooses to import the .RAW file into Lotus 1-2-3. he or she should import the file as a
"Numbers" file. The .RAW file has been arranged to preserve the descriptive headers for each
column of numbers. Use of the .RAW file is entirely optional, but the user may find it helpful
in generating graphs, or in understanding the STARRSS scenario iteration process.
155
-------
Table 8-18. Detailed Information Report (a portion)
*** *** strategy #1: TEST *** ***
Iteration 1 of 1
Unit BIGCOAL 1 option WETFGD1
Option's effects on:
Fuel cost
Consumption
Generation
Unit Emiss.
Other Emis.
Total Emis.
($)
(MBTU)
(MWH)
(tons)
(tons)
(tons)
OLD
110655768
26280000
2628000
62415.0
0.0
62415.0
NEW
110655768
26280000
2522880
6241.5
1051.2
7292.7
CHANGE
0
0
-105120
-56173.5
1051.2
-55122.3
Breakdown of impact:
Option Impact
Phase I bonuses
Phase II bonuses
(repowering extension)
55122.301 tons/year
27285.400 tons/year
0.000 tons/year
136427.002 total)
0.000 total)
Total
Breakdown of costs:
Capital cost
Tax benefits
Tax costs
Increased fixed O&M
Additional costs
Change in fuel costs
Increased var. O&M
Marginal Capacity
Marginal Energy
82407.703
85.616 $M
-4.164 $M
22.166 $M
31.767
47.651
0.000 $M
38.403 $M
6.860 $M
18.029 $M
$M
$M
Total Cost
Marginal Cost
246.330 $M
716.848 $/ton
As the user can see from the lower half of Table 8-18, the Detailed Information file provides
a breakdown of all of the costs associated with all of a strategy's compliance options within
each scenario iteration of a STARRSS run. This file serves as background material for all of
the values in the STARRSS reports.
156
-------
9.0 HOW STARRSS WORKS
STARRSS has two "modes" of operation:
1) Evaluation of user-specified strategies, and
2) Development of its own recommended strategies (optimization).
Mode #1: Evaluation
In the first mode, STARRSS examines strategies that have been defined by the user in the User
Strategy screen (see page 117). Through a multiple-scenario process, STARRSS evaluates these
strategies and reports their total costs. These costs are an approximation of a utility's
incremental present worth of revenue requirements.
Approximation
These costs are an approximation of revenue requirements in the sense that STARRSS does not
perform full tax calculations. The pr gram uses an estimation process described below.
Incremental
These costs represent the incremental costs of a utility's compliance activities. They do not
include the "base case" costs of fuel, O&M, existing plant depreciation, etc. They only
represent the additional revenue requirements that will be borne by the ratepayers because of
the implementation of the utility's Clean Air Act compliance strategy.
Present Worth of Revenue Requirements
The STARRSS costs represent the total present value of the costs of compliance over the entire
study period. The length of the study period is controlled by the user (with the Y ears of Study
data item on the Execution Parameters screen). The yearly discount rates that are used to
calculate the present value of the yearly costs are defined as the Cost of Capital data items on
the Tax Rate, Escalation Rate and Cost of Capital screen.
STARRSS has two ways for using the database's input information and calculating a strategy's
costs:
1) single cost calculation, and
2) multiple-scenario calculation.
157
-------
Single Cost Calculation
The first process produces a single set of results. In this case, STARRSS does not run through
its Monte Carlo multiple-iteration procedure; instead, STARRSS will simply use the mean (i.e.,
weighted average) of each data item's triple forecast and generate one expected value for the
cost of a compliance strategy.
In other words, if the user inputs allowance purchase prices of $300, $400, and $500 (for the
low, medium, and high forecasts) with a probability pointer that references a 40%/40%/20%
probability distribution, the mean forecast for allowance purchase prices would be $380'.
The user stipulates this processing mode by specifying a zero for the Number of Scenario
Iterations per Strategy on the Strategy Summary screen and/or the Develop STA RRSS Strategies
screen.
Although this cost calculation process is obviously faster than performing multiple iterations,
it will not provide the user with any information on the potential risks and range of costs that
the adoption of a strategy may entail. All standard deviation references that appear on the
STARRSS reports of course will be zero.
Also, running STARRSS in the "mean forecast" mode may be fast, but the total cost results can
be substantially different from the expected value results that come out of the multiple scenario
calculation process. In the former case, STARRSS will calculate a strategy's cost once (based
on the mean forecasts for all data items). In the latter case, STARRSS will generate hundreds
of costs for a strategy. The mean of this cost distribution (known as the expected value) will
not be the same as the value that comes out of a STARRSS single calculation run (which uses
the mean of the inputs).
The single mode calculation option is useful for obtaining ball-park estimates; however, the
multiple scenario calculation mode provides more accurate information about the expected value
of a compliance strategy's costs.
Multiple Scenario Calculation
The second process is the multiple iteration procedure that has been discussed throughout the
manual. The user controls this processing mode by specifying a non-zero value (preferably 200
or higher) for the Number of Scenario Iterations per Strategy on the Strategy Summary screen
and/or the Develop STARRSS Strategies screen. This instructs the STARRSS evaluation
process to perform multiple "costing runs" or iterations. During each iteration, STARRSS will
select one of the three values from each data item's triple forecast and determine the cost of a
1 $380 x |40% x $300} + [40% x $4001 + [20% x $500]
158
-------
compliance strategy through the process described below. This iterative selection/calculation
process is known as a Monte Carlo simulation and is described in Chapter 3 (see page 28).
Mode #2: Optimization
The second STARRSS operating mode is optimization. If the user so specifies, STARRSS will
develop its own set of least-cost compliance plans. Each of these plans in turn will be
evaluated in the same manner that user-specified plans are.
A STARRSS optimization is a two-step process. First, STARRSS develops a list of top
strategies; then it evaluates all of these plans. For this second step, the user has the same single
vs. multiple scenario calculation option that is available for standard evaluation runs. The first
step (i.e., the actual optimization process) is described in sections 9.2 and 9.3 below.
9.1 EVALUATION CALCULATIONS
The STARRSS evaluation process utilizes the procedures described below for calculating the
costs and impacts of compliance strategies. If the user chooses the multiple scenario feature,
the entire process will occur for each iteration. Therefore, within the context of the calculations
described below, there is no uncertainty or variability in the input numbers. STARRSS is
assumed to be using specific values that have already been selected through the number-drawing
process described in Chapter 3 (see page 28).
In STARRSS Version 1, the program adopts an average-year approach for the calculation of
all emissions and emissions reductions. Year-to-year variations in these items are not explicitly
monitored but will be in Version 2. Instead, STARRSS Version 1 analyzes compliance
strategies within the context of an average, single-year snapshot. Therefore, if STARRSS
reports that a compliance strategy is expected to require allowances purchases, the user must
interpret this information as an average for the entire study period. Under such a strategy, the
utility is expected to be an allowance buyer on average. Potentially, this information could
translate into a situation where the utility could be selling allowances in the first few years of
the study period while buying significant quantities of allowances in later years.
One last note before getting into the details of the evaluation calculations: STARRSS Version 1
requires that the user select either a Phase I or a Phase II analysis. A Phase I analysis always
begins in 1995 (although the user can specify an earlier Base Year as a reference point for
discounting purposes - see page 59).
159
-------
In a Phase I analysis, STARRSS Version 1 assumes that Phase I lasts for the entire
length of the study.
In other words, a 20-year Phase I run will go from 1995 through the end of 2014 and will
assume that Phase II never happens. Such a run will only analyze the projected emissions and
potential emissions reductions for those units that are affected under Phase I. In addition, the
allowance allocations for the Phase I units will not change; they will stay at their Phase I levels
for the entire length of the study.
Calculate Target Reduction
STARRSS first defines the extent of the compliance challenge by calculating a utility's
target reduction. This is the difference between the utility's average annual projected
emissions and its allocated allowances.2
Calculate Costs of Individual Compliance Options
STARRSS then calculates the present value over the length of the study of all of the
costs for each selected compliance option. For the sake of this discussion, STARRSS
compliance options refer to all of the compliance-related activities that the user defines
in the database either through the Edit/Define Compliance Options screen or the
Incremental Conservation/Renewables screen; allowance purchases are excluded at this
point but are considered later.
Calculate Impacts of Compliance Options
STARRSS calculates the impact or expected emissions reduction that will be achieved
by each compliance option.
This number potentially could bo negative if the utility is already in compliance with the Clean Air Act Amendments. This will not cause
any problems with STARRSS. The program can be used to explore the possibilities of additional emissions control to generate more allowances
for sale.
160
-------
Calculate Bonus Allowances
As the adoption of certain compliance options are promoted by distributions from EPA
of "bonus" allowances, STARRSS calculates an approximation of these bonus
allowances and credits specific compliance options by adding the bonus allowances to
each option's calculated impact.
Calculate Allowance Purchases/Sales
STARRSS then adds up the total impacts (both real impacts and bonus allowances) of
all active compliance options and compares this total to the utility's reduction target.
Any shortfall is made up with allowance purchases, and any excess results in allowance
sales, subject to the user-specified allowance trading constraints.
Calculate Costs of Allowance Purchases/Sales
STARRSS multiplies the allowance purchases or sales by the appropriate market prices
to determine the costs or revenues from allowance trading. This process incorporates
the user-specified price premiums or discounts that are defined on the Allowance
Purchase Prices and Allowance Sale Prices screens.
Calculate Total Costs of Compliance Strategy
Last, STARRSS adds the present value of the costs of all of the individual compliance
options in a strategy and the costs or revenues of allowance transactions, deducts the
present value of the costs of any compliance option linkages (see page 104), and arrives
at a grand total for a compliance strategy.
These procedures are repeated for each iteration of the STARRSS multi-scenario process. For
example, if the user runs STARRSS for 300 iterations, then the program will develop 300
values for:
1) the target reduction for the utility,
2) the total cost of a compliance strategy,
3) the total number of allowances purchased/sold per year, and
4) the total costs/revenues associated with those allowances.
From these 300 values, STARRSS calculates expected values and statistical standard deviations
for each of the above items. In addition, STARRSS stores information on each compliance
option's expected value and range of costs and impacts.
161
-------
The following discussion provides a detailed explanation of each of the general procedures
outlined above.
9.1.1 Calculation of Target Reduction
The calculation of a utility's target reduction is performed by STARRSS in the following way.
Step 1: Calculate Each Affected Unit's Base Case Emissions
For each affected unit, STARRSS multiplies the unit's original average annual
fuel consumption by the sulfur "content" of the existing (i.e., current) fuel (or
fuel blend). The sulfur content of the fuel or fuel blend is expressed in
Lbs/mmBTU. he average annual fuel consumption is expressed in
mmBTU/year and is calculated using Equation 9-1 below. The average
consumption is calculated over the entire length of the study period. For
example, assume that a unit has an annual fuel consumption of 10 trillion
BTU/year for the first 10 years of a 20-year study and that the unit is expected
to be retired after that point. STARRSS calculates the unit's average annual fuel
consumption to be 5 trillion BTU/year.
FuelConsj = CapFact, * Cap, * 8760 his * HtRatej (9-1)
year
where:
FuelConsj =
average annual fuel consumption at unit j
CapFactj =
average annual capacity factor for unit j
ii
to
U
capacity for unit j
HtRatej =
average heat rate for unit j
The unit's capacity and average heat rate are inputs on the Display/Edit A ffected
Units screen. The unit's average capacity factor is the average (over the course
162
-------
of the study period) of the annual capacity factors that are input on the Affected
Units Operating Factors screen, adjusted for any commission dates or retirement
dates that occur within the study period. For example, assume that a new, S02-
emitting generating unit will be commissioned during Phase I and that the unit's
expected annual capacity factor will be 50%. The user is free to specify this
capacity factor value for 1995 (i.e., the beginning of Phase I) even if the unit is
not expected on-line until later. In fact, this is a preferred approach. That way,
as the user changes the commission date, STARRS S automatically makes the
necessary adjustments to its internal calculations. If the user executes a 5-year
Phase I run (i.e., from 1995 through 1999) and specifies a commission date of
1997, STARRSS calculates the effective average Phase I capacity factor for the
unit to be 30%3. This results in the appropriate calculation of average
generation, fuel consumption, and emissions for the single-year analysis
performed by STARRSS Version 1.
Step 2: Calculate Base Case Conservation Emissions Reduction
STARRSS calculates the average annual emissions reduction that will be
achieved by the base case conservation/renewable projects by multiplying each
study year's projected annual energy savings (as entered on the Base Case
Conservation/Renewables screen) by the System Marginal S02 Emissions (a data
item that is expressed in Lbs of S02/MWH and is entered on the same screen).
STARRSS takes the average of these emissions reductions over the years of the
study and deducts this value from the total unit emissions. Therefore, the
capacity factors for the system's generating units should be entered on a "before-
conservation" basis. If they are entered on an "after-conservation" basis, the user
should specify a value of zero for the base case conservation's System Marginal
SO2 Emissions data item (so as not to double count the conservation's emissions
reductions).
Step 3: Calculate Total Base Case Emissions
STARRSS adds up the base case emissions that were calculated for all affected
units in Step 1 and subtracts the conservation emissions reduction calculated in
Step 2. For a Phase I run, the unit emissions will only include those from
Phase I affected units.
; 50% x 3 yaafB/5 years
163
-------
Step 4;
Calculate Total Basic Allowance Allocation
STARRSS adds up the basic allowance allocations for all affected units. This
total value is calculated and displayed on the A llowcmce Parameters screen. This
value does not include any bonus allowances; instead, bonus allowances are
included in the emissions reductions for specific compliance options. The total
basic allowance allocation is merely the sum of the allocations that are input on
the Display/Edit A ffected Units screen. Again, for a Phase I run, the total only
includes the allowances for Phase I affected units.
Step 5: Calculate Total Target eduction
The last step is merely the subtraction of the total basic allowance allocation
from the total base case emissions. This is the total target reduction and
represents the average number of tons of S02 per year that must be reduced or
compensate for (with allowance purchases or bonus allowance allocations).
9.1.2 Calculation of Costs of Individual Compliance Options
The total cost for a compliance option is the present value of all expenses relating to that
compliance option over the course of the study. All escalated values are escalated from the
Base Year, and all calculations of present values are in Base Year dollars. The discount rate
for the present value calculations is the utility's cost of capital. Both the Base Year and the
Cost of Capital are input on the Tax Rate, Escalation Rates, and Cost of Capital screen (see
page 59). Negative values for individual terms in the cost calculations are permitted
(representing a decline in certain costs for a generating unit should that particular compliance
option be implemented). However, STARRSS produces a message in the STARRSS Warnings
Report if it finds any compliance options that have total costs which are negative. This
unrealistic situation would imply that reducing emissions would be a money-making proposition.
Presumably, if a utility's costs would be reduced by implementing a compliance option, then
the option should have already been implemented.
Within STARRSS, compliance options can be separated into two broad categories:
conservation/renewable programs, and genera ting-unit-specific compliance options. The
STARRSS calculation of the present value of the cost for both types of compliance options is
described below.
164
-------
Incremental Conservation Programs and Renewable Projects
A distinction must be made between Base Case programs and Incremental programs. Base case
programs in STARRS S do not have any cost inputs because the system only calculates
incremental revenue requirements. By definition, base case programs are those that were
expected to be implemented even without the passage of the CAAA, and therefore, their costs
should not be included in an assessment of a utility's cost of compliance. Thus, only
incremental programs have cost information in STARRSS, and it is used in the following
fashion.
Step 1: Calculate Incremental Program's Avoided Costs
For each incremental program, STARRSS merely multiplies each year's forecast
of Expected Energy Savings (in MWH) by the program's forecasted Annual
A voided Utility Costs (in S/MWH), thereby developing a stream of avoided costs
for all of the years of the study.
Step 2: Calculate Cost of Incremental Program
For each incremental program, STARRSS merely multiplies each year's forecast
of Expected Energy Savings (in MWH) by the program's forecasted Annual
Costs (in $/MWH), thereby developing a stream of program costs for all of the
years of the study.
Step 3: Calculate Present Value of Incremental Program's Net Economic Cost
For each incremental program, STARRSS calculates the present values of the
streams of avoided costs and program costs (that are calculated in Steps 1 and
2, respectively). STARRSS then calculates the difference between these values,
subtracting the first from the second. This is the present value of the program's
net cost. This should be a positive number. If the avoided costs were already
greater than the program costs, then the program should have already been
implemented for purely economic reasons.
Generating-Unit-Specific Compliance Options
For all compliance options that are specified through the Edit/Define Compliance Options
screens, STARRSS calculates the present value of the following costs:
165
-------
Capital Costs
Tax Benefits
Tax Costs
Incremental Fixed O&M Costs
Additional Costs
Fuel-Related Costs
Incremental Variable-O&M-Related Costs
Replacement Capacity Costs
Replacement Energy Costs
This is provided that the user has not specified either of the two override values on the
Edit/Define Compliance Options screen. The user has the option to bypass the regular cost
calculations by inputting cost overrides for any compliance option (in the form of base year
$/ton and total annual tons removed). If the user chooses to do this, STARRSS multiplies these
two numbers to get the annual levelized total cost for the option. This levelized value is
converted into a total present value by extending its value from the compliance option's In-
Service Year (or the study's start year, whichever comes later) through the end of the option's
life (or the end of the study, whichever comes first) and discounting this stream of costs by the
utility's Cost of Capital.
If the user has not specified these overrides, then STARRSS calculates a compliance option's
total costs in the following manner:
Step 1; Calculate Present Value of Capital Costs
STARRSS escalates the option's capital costs (which are input in Base Fear mid-
year dollars) out to the beginning of the option's In-Service Year using the
capital cost escalation rates on the Tax Rate, Escalation Rates, and Cost of
Capital screen. Since costs are being escalated from mid-year to beginning-of-
year, this entails a half-year's escalation. For example, if the Base y ear were
1992 and an option's In-Service Year were 1995, then STARRSS would escalate
the capital costs two and a half years (from July 1, 1992 to January 1, 1995).
Capital costs are the only costs that receive this half-year treatment, which
assumes that compliance options will be placed in-service at the beginning of a
year. A project's capital costs should be evaluated then. All of a project's
operating costs, on the other hand, will occur throughout the year and should be
evaluated on an averaged (i.e., mid-year) basis.
166
-------
STARRSS then discounts the escalated capital costs back to the Base Year. This
provides STARRSS with the present worth of a project's direct capital-related
revenue requirements (i.e., annual depreciation and total return on ratebase).
STARRSS does not consider any costs or benefits that fall outside of the study
period. If the compliance option has an In-Service Year that is before the study's
start year or if the option's life extends beyond the end of the study, STARRSS
calculates an appropriate adjustment (through proration and discounting) to
reduce the option's capital-related revenue requirements to account for that the
full costs that will not be within the study period. STARRSS does not calculate
salvage values or other "end effects" issues for options that go beyond the end
of the study.
Step 2: Calculate Present Value of Tax Benefits
STARRSS develops an approximation of the tax benefits associated with a
compliance option's capital expenditures. Since the IRS allows capital
investments to be depreciated (for tax purposes) on an accelerated basis, the
implementation of compliance options with capital expenditures will permit the
deferrance of taxes. Although the total amount of the tax dollars that will be
paid by the end of the project will be the same as without the deferrance, such
deferred taxes result in a present value benefit because of the timing of the tax
payments. Effectively, this benefit reduces the total capital costs of a project by
offsetting them with the value of the tax advantages. Therefore, STARRSS
calculates the tax benefit as a "negative" cost. Generally, this affect is relatively
small in present value terms, resulting in a 3-5% reduction of the present value
of capital costs. Therefore, for speed considerations, STARRSS Version 1 does
not perform a detailed tax benefit calculation. Instead, the program uses
information from a regression analysis that Hagler, Bailly performed. By
performing detailed tax benefit calculations for over 1,200 different sets of
financial assumptions, Hagler, Bailly developed a linear regression equation that
closely approximates project tax benefits under of variety of conditions.4 The
equation uses the Long-Run Effective Tax Rate, the Return on Equity, the Equity
Percent of Capital, and the average Cost of Capital data inputs (all of which are
input on the Tax Rate, Escalation Rates, and Cost of Capital screen) and assumes
that the compliance project is in the 20-year Tax Class, using the 150%-
declining-balance/switching-to-straight-line tax depreciation method. If the user
finds that the STARRSS calculation underestimates or overestimates the actual
tax benefits, the STARRSS calculation can be modified through the Tax Benefit
Multiplier on the Execution Parameters screen. This data item directly adjusts
4
The regression analysis had an R-squared of 0.9629
167
-------
the tax benefits that are calculated by STARRSS. By setting the multiplier to
zero, the user can eliminate the consideration of all compliance options' tax
benefits.
Step 3; Calculate Present Value of Tax Costs
Similar to the process in Step 2 above (for the calculation of a compliance
option's tax benefits) STARRSS develops an approximation of the tax costs
associated with a compliance option's capital expenditures. Since the equity
portion of the return that a utility earns on rate-based capital expenditures is
taxable, then the adoption of compliance options that involve capital expenditures
will increase the utility's tax payments over the life of the option. Similar to the
tax benefit calculation, STARRSS uses information from a regression analysis
that RCG/Hagler, Bailly performed. By performing detailed tax benefit
calculations for over 1,200 different sets of financial assumptions, Hagler, Bailly
was able to develop a linear regression equation that closely approximates project
tax costs under of variety of conditions.5 The equation uses the Long-Run
Effective Tax Rate, the Return on Equity, the Equity Percent of Capital, and the
average Cost of Capital data inputs (all of which are input on the Tax Rate,
Escalation Rates, and Cost of Capital screen). If the user finds that the
STARRSS calculation underestimates or overestimates the actual tax costs, the
STARRSS calculation can be modified through the Tax Cost Multiplier on the
Execution Parameters screen. This data item directly adjusts the tax costs that
are calculated by STARRSS. By setting the multiplier to zero, the user can
eliminate the consideration of all compliance options' tax costs.
Step 4: Calculate Present Value of Fixed O&M Costs
STARRSS calculates each compliance option's yearly increased fixed O&M
(operation and maintenance) costs by escalating the option's Increased A nnual
Fixed O&M Costs (found on the Edit/Define Compliance Options screen) from
the Base Year through the end of the study. It then takes the costs that are
incurred during the option's life that is within the study and discounts that stream
of costs back to the Base Year. In other words, if the option only lasts through
the first half of the study period, then the increased fixed O&M costs are
assumed to stop at that time. The sum of these discounted values is the present
value of the increased fixed O&M expenses.
5
The regression analysis had an R-squared of 0,9929
168
-------
As a numerical example of this process, assume that the Increased A nnual Fixed
O&M Costs for a compliance option are $1 million in 1992 dollars. Assume that
the fixed O&M escalation rate is 5% and the utility's cost of capital (i.e., the
discount rate) is 12%. Table 9-1 below shows the calculations that would be
performed for a 5-year Phase I run: the escalation of the $1 million into current
year values, the discounting of each year's value (1995-1999) back to 1992, and
the aggregation of these discounted values into a total present value. As can be
seen from the last value in the last column of the table, the present value for the
increased fixed O&M caused by the implementation of this hypothetical
compliance option would be $3,636 million.
Table 9-1. Calculation of the Present Value of Increased Fixed O&M Expenses
(all expenses in millions of dollars)
Year Fixed Discounted Accumulated
O&M O&M Discounted O&M
(present value)
1992 1.000
1993 1.050
1994 1.103
1995
1.158
0.824
0.824
1996
1.216
0.772
1.596
1997
1.276
0.724
2.321
1998
1.340
0.679
3.000
1999
1.407
0.637
3.636
Step 5; Calculate Present Value of Additional Costs
STARRSS performs the identical procedure for an option's A dditional Costs data
item. Note that this data item has its own compliance-option-specific escalation
rate (see page 90).
Step 6: Calculate Present Value of Fuel-Related Costs
STARRSS calculates a compliance option's fuel-related incremental costs by
accounting for two main factors: projected changes in a unit's fuel consumption
(e.g., because of changes in system dispatch, changes in boiler efficiency), and,
169
-------
in the event of fuel-switching, price differentials between currently-consumed
fuels and proposed fuel blends. The implementation of a compliance option at
an affected generating unit can increase or decrease the unit's fuel costs even if
the option does not entail any switching of the unit's fuel supply. Specifically,
if a compliance option changes the unit's operations (i.e., capacity factor), a
different level of fuel consumption will occur. In determining the true cost of
implementing a specific compliance option, STARRSS comprehensively
considers all cost increases or decreases that are caused by the option.
A compliance option's fuel-related incremental costs are calculated as the
difference between the product of the new projected fuel consumption and the
price of the new fuel blend and the product of the current fuel consumption and
the price of the existing fuel supply. Equation 9-2 below displays this in
mathematical terms.
Fuel Cost, j = (NewConSy * NewPiice,j) - (OldConSj * OldPricej) (9-2)
where:
FuelCosty
NewCons^ =
NewPrice;,
OldConS:
OldPrice:
incremental fuel cost of implementing compliance
option i at unit j
new average annual fuel consumption caused by
implementing compliance option i at unit j
weighted average price of compliance option i's
new fuel blend at unit j
current average annual fuel consumption for unit j
weighted average price of current fuel blend at unit
j
Equation 9-2 refers to a single year of calculations. STARRSS Version 1
performs its unit operation calculations in a single, average-year context. Year-
by-year changes in fuel prices are incorporated into the program's calculations.
In calculating a compliance option's incremental fuel costs, STARRSS first
calculates the affected unit's average fuel consumption over the study period for
both the base case and "change case" situations. The calculation of the base case
fuel consumption is shown in Equation 9-1 on page 162; the calculation for the
unit's fuel consumption after a compliance option has been implemented is shown
in Equation 9-3 on the next page. STARRSS then uses these single, average-
170
-------
year values in calculating incremental fuel costs for the affected unit for each
year of the study period (using Equation 9-2). Since STARRSS allows the user
to specify as many as three different fuels in a unit's existing and/or new fuel
blend, the program uses the weighted average prices in all fuel price calculations.
The program then takes the stream of the annual fuel costs calculated from
Equation 9-3 and discounts them back to the Base Year.
NewConSy = NewCapFacty * Capj * 8760 hrs * NewHtRate^ (9-3)
year
where:
NewConS;
NewCapFacty
average annual fuel consumption after
implementing compliance option i at unit j
unit j's average annual capacity factor after
implementing compliance option i
Capj
unit j's existing capacity
NewHtRatey =
unit j's average heat rate after
implementing compliance option i
The New Capacity Factor for a unit at which a compliance option is implemented
is a direct single-year user input on the Edit/Define Compliance Options screen.
STARRSS assumes that the value that the user inputs for this data item
represents a long-term estimate (i.e., constant value over time) of how the
affected unit is expected to operate. If the user leaves the New Capacity Factor
at zero, STARRSS assumes that the unit's utilization will not change and
therefore uses the unit's current capacity factor in the above calculation.
The capacity of a unit can be affected by the implementation of a compliance
option. For example, scrubbing a unit can cause a unit's capacity to be derated.
However, the Capacity Deration data item (that is specified on the Edit/Define
Compliance Options screen) does not affect the STARRSS fuel consumption
calculations. For fuel consumption calculations, STARRSS uses the same unit
capacity for both the base case and change case. A unit is derated by the
adoption of a compliance option, frequently because some of the unit's capacity
is required to power more equipment (such as with the installation of scrubbers).
Such a circumstance translates into a reduction in net generation but not fuel
consumption. The unit has less power that it can supply to the transmission grid,
but its fuel consumption is unchanged (all else being equal). If a compliance
171
-------
option is expected to reduce a unit's fuel consumption, the user should indicate
this through specifying an improvement in the unit's boiler efficiency.
A generating unit's boiler efficiency can be affected by the implementation of a
compliance option, particularly if a utility decides to burn a different type of fuel
than what the boiler was originally designed to burn. On the Edit/Define
Compliance Options screen, the user can specify a Heat Rate Multiplier. This
data item is used to adjust an affected unit's heat rate (i.e., boiler efficiency)
when a specific compliance option is implemented at the unit. The default value
is 1.000; higher values will increase the new heat rate that is used in Equation
9-3 and translate into a decrease in boiler efficiency; lower values indicate an
improvement in boiler efficiency.
2: Calculate Present Value of Variable O&M Costs
STARRSS calculates the existing value of the increased variable O&M costs at
a unit similar to the fuel cost calculation. These costs are meant to reflect non-
fuel-related unit-specific operating cost, such as increased water consumption,
waste disposal, and consumption of new products (e.g., limestone). They should
not include the costs of additional power that may be required for certain
compliance options. Replacement power costs are calculated in Steps 8 and 9.
A compliance option's non-fuel-related incremental variable O&M costs are
calculated as the difference between the product of the new projected unit
generation and the new variable O&M cost (specified on a $/MWH basis) and
the product of the current unit generation and the current variable O&M cost.
Equation 9-4 below displays this in mathematical terms.
VO&MCosty = (NewGen,j * NewVO&M,j) - (OldGen, * OldVO&M,) (9-4)
where:
VO&MCostjj = incremental variable O&M cost of implementing
compliance option i at unit j
NewGeny = new average annual generation caused by
implementing compliance option i at unit j
NewVO&My = new variable O&M cost (in $/MWH) at unit j after
implementing compliance option i
172
-------
OldGeiij = current average annual generation at unit j
OldVO&Mj = current variable O&M cost (in $/MWH) at
unit j
Equation 9-4 refers to a single year of calculations. Although STARRSS Version
1 performs its unit operation calculations in a single, average-year context, the
year-to-year changes in annual price data are not averaged; instead, they are
explicitly represented in a STARRSS analysis.
Current "base case" variable O&M costs are input on a unit-specific basis and
are expressed in $/MWH of net generation. They are escalated throughout the
length of the study by the Variable O&M Escalators on the Tax Rate, Escalation
Rate and Cost of Capital screen.
Each compliance option's Increased Non-Fuel Variable O&M Cost data item is
found on the Edit/Define Compliance Options screen, is expressed in the same
$/MWH terms, and is escalated by the same schedule of escalators. This data
item serves as a direct adder to the unit's current "base case" variable costs. In
calculating a compliance option's incremental variable O&M costs, STARRSS
first calculates the affected unit's average annual generation over the study period
for both the base case and "change case" situations. The calculation of the base
case generation is shown in Equation 9-5 below.
OldGeiij = CapFact, * Cap, * 8760 his (9-5)
year
where:
OldGenj = base case average annual expected generation at
unit j
CapFactj = base case average annual capacity factor for unit j
Capj = capacity for unit j
The calculation of the new projected annual average generation is similar to
Equation 9-5 except that a New Capacity Factor is used (if a non-zero value is
input for this data item on the Edit/Define Compliance Options screen). If a
compliance option's New Capacity Factor is left at zero, then STARRSS assumes
173
-------
that there will be no change in the unit's utilization and therefore uses the unit's
current capacity factor in the above calculation. Also, if the user specifies a
Capacity Deration, the unit's capacity will be adjusted. For example, a 4%
deration would cause STARRSS to multiply the unit's capacity by 96% (= 100%
- 4%) in calculating a unit's new projected net generation.
STARRSS then uses the single, average-year values for base case and new
generation in calculating incremental variable O&M costs for the affected unit
for each year of the study period (using Equation 9-4). The program then takes
the stream of the annual variable O&M costs and discounts them back to the
Base Year.
Step 8: Calculate Present Value of Replacement Capacity Costs
STARRSS calculates the present value of the costs (or benefits) of replacement
capacity for any compliance option that causes a deration (or increase in
capacity) at a generating unit. Similar to the calculations for fuel or variable
O&M costs, the program calculates the annual stream of replacement capacity
costs for an option by multiplying the yearly system marginal capacity cost (as
input on the Marginal Capacity Cost screen) by the difference between the
affected unit's new capacity and its original capacity. Derations result in positive
costs; capacity increases result in negative costs (i.e., benefits). STARRSS then
discounts the stream of costs back to the Base Year.
Step 9: Calculate Present Value of Replacement Energy Costs
STARRSS calculates the present value of the costs (or benefits) of replacement
energy for any compliance option that causes a change in a generating unit's
output. Through a process that is virtually identical to the calculation of
replacement capacity costs (described above), STARRSS multiplies the yearly
system marginal energy cost (as input on the Marginal Energy Cost screen) by
the difference between the affected unit's new generation (as described above in
Step 7) and its original "base case" generation (as calculated in Equation 9-5).
Decreases in generation result in positive replacement energy costs; increases in
generation result in negative costs (i.e., benefits). STARRSS then discounts the
stream of costs back to the Base Year.
174
-------
9.1.3 Calculation of Impacts of Individual Compliance Options
The "impact" of a compliance option refers to its annual average reduction in S02 emissions.
Incremental Conservation Programs and Renewable Projects
STARRSS calculates the emissions reduction impacts from incremental conservation programs
or renewable projects by multiplying the program's Expected Energy Savings for each year by
the program's System Marginal S02 Emissions (both entered on the Incremental
Conservation/Renewables screen).
Generating-Unit-Specific Compliance Options
STARRSS calculates impacts for each generating-unit-specific compliance option in the
following way.
Step 1: Calculate Unit's Base Case Emissions
For the unit which the compliance option affects, STARRSS multiplies the
original annual fuel consumption (as calculated in Equation 9-1) by the sulfur
content/emissions rate of the current fuel (or fuel blend). The program then
adjusts these uncontrolled emissions for any existing pollution control systems
by multiplying the emissions by one minus the existing system's removal
efficiency.
Step 2: Calculate Unit's New Emissions
STARRSS then calculates the unit's new level of emissions if the compliance
option were to be implemented. The program multiplies the new annual fuel
consumption (as calculated in Equation 9-3) by the new fuel blend's sulfur
content/emissions rate. Even if the option docs not entail fuel-switching (and
hence the base case and new fuel's sulfur content are the same), the fuel
consumption of the unit may change (because of differences in boiler efficiency
and unit utilization). The outcome of this calculation is then adjusted for any
new pollution control systems. When the unit does not have an existing
pollution control system, the new emissions are multiplied by one minus the new
system's removal efficiency. If the unit already has a system, then an adjustment
must be made for both systems by multiplying by one minus the existing
system's removal efficiency and one minus the new system's removal efficiency.
175
-------
Step 3: Calculate Effects on Other Units Emissions
If the generating unit's capacity or capacity factor will be changed by the option,
then STARRSS will calculate the emissions impact at other power plants that
would be caused by increased or decreased generation from this unit. The
program will calculate the difference between the unit's original annual
generation and the new annual generation and multiply this differential by the
value of the compliance option's System Marginal S02 Emissions data item. In
the case of a reduction of the unit's generation, this term will be positive —
reflecting the additional emissions that will occur elsewhere because other units
will have to increase generation to compensate. If the individual unit experiences
an increase in generation, this will back down other units and reduce their
emissions.
Step 4: Calculate Total Annual Impact
Calculate the total annual impact for the compliance option using Equation 9-6
below:
Impact, = RegEmisSj - NewEmiss, l - OthrEmisSj (9-6)
where:
Impactj = total annual impact for compliance option i
RegEmissj = base case annual emissions from generating
unit j
NewEmisSj} = new annual emissions from generating unit j
after implementing compliance option i
OthrEmisSj = emissions impacts at other generating units
caused by changes in generation at unit j
Step 5; Calculate Bonus Allowance Effect
Scrubbing, repowering, and conservation compliance options can generate bonus
allowances for a utility. STARRSS calculates the theoretical allocation of bonus
allowances for each eligible compliance option based on the provisions in Title
IV of the CAAA. The program adjusts the allocation of the bonus allowances
176
-------
by the associated user-specified Bonus Allowance Supply Percentages (on the
Allowance Parameters screen). This is the anticipated total allocation.
STARRSS divides the option's bonus allowance allocation by the number of
years of the study to determine the annualized allocation that will be used in
STARRSS Version l's single-year analyses. This annualized number is added
to the appropriate compliance option's emissions reduction impact. All unitized
cost ($/ton) calculations in STARRSS use this "modified" impact in the
denominator to reflect the benefits of bonus allowances.
STARRSS uses simplified processes to capture the effects of bonus S02
allowances on the selection of particular compliance options. For each
compliance option, STARRSS will calculate the total bonus allowance impact,
divide that total by the number of years in the study, and add that total to the
SOz reducing impact associated with the compliance option. To disable the
calculation of bonus allowances for any option, the user must set the Bonus
Allowance Supply Percentage in the Allowance Parameters selection of the
System-level Info submenu to zero for all forecasts.
Phase I Extension Bonus Allowances
The CAAA allocates Phase I Extension Bonus Allowances for Phase I-affected
units that use technology achieving 90% or greater S02 removal efficiency (i.e.,
scrubbers). Phase I extension bonus allowances have two components: one
allows the unit to delay installation of qualifying technology until January 1,
1997, and another provides extra incentive allowances for reducing emissions
below the Phase II standard of 1.2 lbs. S02/MBtu,
In STARRSS, the first component of the Phase I Extension Bonus is calculated
for each unit using equation 9-7:
Bonus Part 1 = (RegEmisSj - NewEmiss^j) * 2 (9-7)
where:
RegEmisSj = regular (uncontrolled) annual emissions from
generating unit j without a scrubber
NewEmisSj j = annual emissions from generating unit j resulting
from implementing scrubber compliance option i
The difference is multiplied by two because that is the number of years (1995
and 1996) over which the extension bonus allowances are granted.
177
-------
By using the difference between the units expected emissions with and without
a scrubber for the two years 1995 and 1996, the bonus allowances allow the
utility to continue operating several units at their current emission levels until
1997. In the CAAA, the unit using scrubber technology is designated the
"control unit," while the units that would receive extra allowances freed up by
the control unit are designated the "transfer units." By allocating bonus
allowances to control and transfer units, EPA permits the utility to delay
installation of the scrubber until 1997.
The second component of the Phase I Extension Bonus is calculated for each unit
using equation 9-8 and represents those bonus allowances that are allocated for
the years 1997 - 1999:
Bonus Part 2 = (BasPhaseHj - NewEmisSj j) * 3 (9-8)
where:
BasPhaseflj = basic phase II allowance allocation (Baseline Heat
*1.2 lbs S02/MBtu) for generating unit j
NewEmisSj i = annual emissions from generating unit j resulting
from implementing scrubber compliance option i
The difference is multiplied by three because it is the number of years (1997 -
1999) over which the bonus allowances are granted. This component of the
bonus allowances in effect rewards the unit for achieving an emission rate lower
than 1.2 lbs/MBtu three years before the Phase II deadline.
Repowering Extension Bonus Allowances
Repowering Extension Bonus Allowances allow a utility system to cover
increased emissions at other generating units while an affected unit undergoes a
repowering construction period. For each year of the repowering construction
period after 2000 (up to a maximum of three years), bonus
allowances are allocated according to equation 9-9:
178
-------
Repowering Bonus = RegEmisSj - Emissl.2j (9-9)
where:
RegEmisSj = regular (uncontrolled) annual emissions from
generating unit j before repowering
Emiss 1.2j = annual emissions at the Phase II emission limitation
(i.e. unit's Baseline Heat * 1.2 lbs SCyMBtu) for
generating unit j
This bonus allows the utility to replace the generation lost at the repowering unit
with compensating generation at an emissions rate no greater than 1.2 lbs/MBtu.
If the unit's emissions are lower than the unit's basic Phase II allocation, no
bonus is awarded.
Conservation/Renewable Energy Bonus Allowances
The CAAA provides a Conservation/Renewable Energy Bonus Allowance reserve
for utilities engaging in qualifying energy-saving conservation activities,
STARRSS calculates bonus allowances from this reserve using equation 9-10:
Con/Renew Bonus = ExSave, * .002 (9-10)
where:
ExSave, = Expected savings over the applicable period for
program i, in MWh (or expected generation
provided by renewable energy project i)
The .002 factor converts verified savings from MWhs to allowances at a rate of
4 lbs S02/MWh (the conversion multiplier stipulated in the CAAA).
For utilities with Phase I-affected units, only the 1992 - 1994 energy savings will
be considered in the above equation; for Phase II-affected utilities, only the 1992
-1999 energy savings will be considered.
179
-------
9.1.4 Calculation of Allowance Transactions
STARRSS compares the utility's emissions reduction target with the sum of the annual impacts
and annualized bonus allowance allocations for all compliance options in a strategy. For a
shortfall, STARRSS "fills the gap" with allowance purchases. If the sum of the impacts and
bonus allowances exceeds the target reduction then STARRSS sells the excess allowances.
The program determines the costs or revenues from allowance transactions by pricing a stream
of annual allowance transactions over the length of the study. Effectively, STARRSS Version
1 assumes that the calculated average-year volume will be purchased/sold in every year of the
study. The program multiplies this annual trading volume by each year's allowance price
(buying or selling) to develop a stream of annual costs or revenues. STARRSS takes in
consideration the size of the annual transactions and modifies the buying/selling price depending
on the Purchase Price Premium or Sale Price Discount (see page 53). The program then
discounts this stream of costs or revenues back to the Base Year.
Trading Limitations
If the amount of allowances sold exceeds the user-specified allowance sales limit (as entered
on the Allowance Parameters screen), then STARRSS will not give the strategy any
credit/revenues for those allowances that are over the limit.
In the opposite case, if the amount of allowances that the utility must purchase is greater than
the user-specified limit, the program will still purchase them (since the utility still must comply).
However, STARRSS will "flag" all allowance transactions that exceed the selling or buying
limits by placing an asterisk next to the transaction values on the output reports.
In Version 1, STARRSS determines the trading limits by taking the average value of the yearly
limits over the study period.
9.1.5 Calculation of Total Cost of Compliance
Prior to calculating the total cost of a compliance strategy, STARRSS will determine the present
value of any applicable compliance option linkages (see page 104). The capital cost savings
are assumed to occur in the In-Service Year of the latest compliance option. The operating cost
savings are assumed to occur only during those study years that all of the compliance options
in the linkage are active.
The last step in the process is the calculation of a strategy's total cost of compliance. This is
merely the sum of all of the individual compliance option costs, plus the allowance transaction
180
-------
costs (which will be negative if the utility is an allowance seller), minus any cost savings
because of applicable compliance option linkages.
9.1.6 Calculation of Unitized Costs
In addition to the total present value of compliance costs, STARRSS displays unitized costs
(i.e., $/ton) on a number of output reports.
To convert the present value of total cost for a compliance option into a unitized cost, the
levelized value must be calculated first. If the discount rate remains constant over the study
period, the levelized value can be calculated by using Equation 9-11 below.
(PresValxx * DiscRate)
LevVal^ = (9-11)
(1 - (1 + DiscRate) LOS)
where:
LevValM = levelized value of the present value of total costs in
year 19xx
PresValxx = present value of total costs in year 19xx
DiscRate = discount rate (utility's cost of capital)
LOS = length of study (in years)
If the user has input a discount rate that changes from year to year, a more complicated
equation (that uses a string of discount factors) must be used to calculate the levelized cost of
compliance.
To calculate an option's or strategy's unitized cost of compliance (in $/ton), the levelized cost
of compliance simply is divided by the average annual impact (in tons of S02 reduced).
181
-------
9.2 FULL OPTIMIZATION
The STARRSS Full Optimization process considers every possible combination of "active"
compliance options (i.e., those options that the user has selected for the optimization). For
example, assume that a user has defined two compliance options for a utility system, one each
at the utility's two affected units. The utility's current annual emissions arc 250,000 tons/year.
However, it has only been allocated 150,000 allowances/year, thereby necessitating the reduction
of 100,000 tons/year (or the purchase of allowances to cover any excess emissions). Option #1
will reduce system emissions by 70,000 tons, and Option #2 will reduce emissions by 60,000
tons. If the Full Optimizer is xecuted, STARRSS will develop four compliance strategies:
1) Purchase 100,000 allowances
2) Implement Option #1 only and buy 30,000 allowances
3) Implement Option #2 only and buy 40,000 allowances
4) Implement both options and sell 30,000 allowances
The Full Optimizer will evaluate all of these possible combinations based on the mean forecast
for all of the STARRSS data items. During the optimization process, STARRSS will not
perform multiple iterations for each possible strategy because this would take too long. Instead,
the Full Optimizer calculates a single present value of the cost of each possible strategy. All
of the STARRSS inputs are temporarily set to their mean value (i.e., the weighted average of
the triple forecasts) when the program calculates each possible strategy's present value of
compliance costs.
The Full Optimizer will discard any strategies that violate the user-specified allowance trading
limits (on the Allowance Parameters screen). However, this does not mean that the user will
never see the limits exceeded by optimal strategies. As is pointed out below, STARRSS
submits it strategies to the multiple-scenario evaluation process. Therefore, a strategy may
remain within the allowance trading limits when evaluated under the mean forecast assumptions
but exceed the limits when opened up to the variability of the multiple-scenario.
In the Full Optimizer, STARRSS ranks the strategies in a master list that can hold as many as
255 strategies. STARRSS continues to develop new combinations of compliance options even
if the list fills up. However, if a compliance strategy does not have a low enough cost to make
it on the list, it is discarded. The Full Optimizer continues this process until it has considered
all possible strategies. This could involve evaluating billions of strategies. For example, if a
utility system has 10 affected units, and if each unit has 9 different possible
182
-------
compliance options, then there are 10 billion different combinations of options. The number
of possible strategies is given by Equation 9-12 below.
Possible Number of Strategies = (Number of Options + i) (9-12)
Obviously, the full-enumeration approach can translate into an enormous number of options to
consider. As noted above, STARRSS does not attempt to save all of these strategies in the
computer's memory. As described above, STARRSS instead develops a master list of at most
255 strategies. In opting to do, the program takes one shortcut. The economy of scale cost
savings that are modelled in the database through the Compliance Option Linkages (see page
104) are not considered in the cost of a strategy until all possible strategies have been
enumerated and the top 255 strategies arc on the master list. At that point, the cost savings of
all linkages are deducted from the total cost of any strategies that contain the specific
compliance option combinations that are modelled as linkages. The list is then resorted.
If the user has modelled a compliance linkage that entails considerable cost savings, it is
possible that a strategy that includes this cost-saving combination of options may not make it
onto the master list. Conceivably, if the cost savings were tremendous, that strategy may have
been the least-cost plan. The user should remain aware of this limitation of the Full Optimizer
and should evaluate such cost-saving combinations as user-specified strategies if the
optimization process appears to overlook such measures.
Ultimately, the user determines the number of strategies that will be more fully evaluated from
the master list of 255. The Number of Strategies to be Evaluated/Saved (see page 119) is the
data item through which the user controls the size of this top set of plans. That number of
strategies will be taken from the top of the list of 255 and run through the standard multiple-
scenario evaluation process. After the top plans have been evaluated, they are displayed in the
STARRSS output reports in ascending order of expected cost. The least-cost plan is not
necessarily the most desirable. The user must also consider the level of risk (i.e., potential
variation in cost) that is associated with each strategy, along with non-quantifiable issues that
can bear on the selection of an appropriate compliance strategy.
9.3 HEURISTIC ALGORITHMS
In the event that a user defines an optimization problem that is so large that a full enumeration
of all possible compliance strategies would be too time-consuming, two alternative
methodologies are provided. These methodologies employ heuristic algorithms in the
development of a set of "good" compliance strategies. In mathematical terminology, the
problem of determining the least-cost compliance strategy for a utility is "NP-complete." In
other words, the optimal solution cannot be determined through any short-cuts; the only way
to be sure one has found the least-cost compliance strategy is to fully enumerate all of the
possible strategies and see which one is the cheapest. Therefore, there is no guarantee that any
183
-------
methodology which bypasses the full enumeration approach will find the optimal plan.
However, true optimization is not critical within STARRSS. The main target of the STARRSS
optimization methodology is to develop a set of good compliance plans which can then be
exposed to a variety of future economic and operational uncertainties. True optimization can
only be performed in a world of fixed underlying assumptions. What appears to be the optimal
strategy under the mean forecast assumptions within STARRSS could have a higher expected
cost than other strategies under variable conditions. Therefore, the STARRSS heuristic
algorithms quickly compile a set of low-cost, diverse compliance plans; the true test of each of
these plan's "optimality" will occur during STARRSS' full scenario analysis.
For both heuristic algorithms, STARRSS allows the allowance trading constraints (specified on
the Allowance Parameters screen) to be violated. However, in the case of purchase violations,
it prices the additional allowances at $999/ton; for sales violations, it prices the excess
allowances (over the sales limit) at $0/ton. This arrangement permits the program to consider
strategies that may marginally violate the trading limits (when evaluated under the mean forecast
assumptions) but are still worthy of consideration.
9.3.1 Heuristic #1: Multiple Scenario Hill Climbing
The first heuristic uses a three-step process to generate each strategy, the steps of which will
be described below:
Step #1: Scenario generation
Step #2: Hill climbing optimization
Step #3: Mean-forecast re-evaluation
Scenario Generation: The scenario generation step is the same process that occurs in the
strategy evaluation process described in section 9.1; one of the three forecasts for each data item
in the database is chosen, describing a possible scenario. The entire optimization that takes
place in step two will attempt to minimize costs under this scenario; Heuristic #1 is the only
optimizer which considers multiple scenarios.
Hill Climbing: Hill climbing is an established optimization technique in Operations Research.
It is analgous to a climber trying to find the highest point on a mountain. If the shape of the
mountain is fairly regular, the climber can easily find the top simply by choosing the steepest
direction in which to take each step. The climber knows he or she is at the top of the mountain
when a step further in any direction would lead the climber downhill. In Heuristic #1, "steps"
are substitutions of one compliance option for another at any one unit (including doing nothing
at all as an option). A random strategy is chosen as a starting point, and the substitution that
results in the greatest cost reduction in the overall strategy is taken at each step.
184
-------
Note that this algorithm is not guaranteed to come up with the optimal solution every time. The
assumption in the analogy is that the mountain is fairly regular in shape; if it has more than one
distinct peak, the climber could end up at a "false summit" (i.e., a peak that is not the highest.
Similarly, Heuristic #l's hillclimbing will sometimes find a strategy which is not the least cost,
but from which any single substitution would produce a more expensive strategy.
Heuristic #1 attempts to circumvent this possibility by repeating the hillclimbing process four
times within each scenario iteration, using four randomly generated strategies as starting points;
this is analogous to four climbers starting at different places and climbing the same mountain
with the hope that at least one woul reach the true sAmmit.
The heuristic algorithm is also protected against false summits by the use of multiple scenario
iterations; each scenario corresponds to a slightly different "landscape" for the hillclimber to
traverse. If the scenarios are significantly different, a false summit is unlikely to fool the
climber, or even exist at all, in every single iteration.
Re-Evaluation: The least cost of the four (or fewer) strategies the hillclimber finds is re-
evaluated under the mean forecast assumption, and sorted into the final list of strategies
according to this measure of its cost. The rationale behind re-evaluation is that if a strategy
which has a low cost in some arbitrary scenario is not somewhat competitive in the mean
forecast scenario, then it is not really viable.
Tradeoffs between Heuristic #1 and Full Enumeration
Heuristic #1 can be much faster than full enumeration, generates strategies that have been
developed under scenarios other than the mean forecast, and considers compliance option
linking every time it evaluates the cost of a strategy. If there are significant linkage benefits
in the database, Heuristic #1 could outperform the Full Enumerator. On the other hand, under
certain circumstances, Heuristic #l's strategies may not measure up to the Full Enumerator's
strategies, especially when allowance purchase and sales limits are strict enough to constrain
the search; these situations are more likely to yield false summits.
9.3.2 Heuristic #2: Varying Prioritization
The second heuristic's process is more complex and is especially designed for compliance
strategy optimization. While both Heuristic #1 and #2 develop sets of compliance plans that
are optimal or near-optimal, preliminary analyses have shown that Heuristic #1 is a little better
on average. However, under certain circumstances, Heuristic #2 does better.
The general flow of the second heuristic process involves two distinct algorithms: the Main
Algorithm and the Market Algorithm. The Main Algorithm generates strategies that consist of
emissions-reducing actions at every unit where compliance options are specified; in many cases,
185
-------
this results in strategies that involve the significant overcontrol of emissions and the sale of
many allowances. Each strategy is then passed to the Market algorithm for possible
improvement. The Market Algorithm explores the possible benefits that may be achieved
through allowance transactions. If the marginal compliance options are more expensive than
the allowance purchase price in the marketplace, then the Market Algorithm will back these
options out of the plan and sell fewer (or purchase more) allowances. Once the Market
Algorithm can no longer economically back options out of the plan, it will begin to explore the
possibility of adding options whose cost is cheaper than the allowance sale price in the
marketplace, thereby overcontrolling emissions and selling the excess allowances.
Main Algorithm
The Main Algorithm generates all of the compliance plans on which the Market Algorithm
works. Is assures that the basic "building blocks" for a low-cost compliance strategy will be
compliance options with low unitized ($/ton) costs, large impacts (total tons of S02 emissions
reduced), or a combination of both. In other words, a low-cost strategy may entail
implementing low-cost/low-impact options at all affected units or medium-cost/high-impact
options at only a few units. Regardless, it is unlikely that a sound strategy will involve many
options that are both high-cost and low-impact.
Therefore, the primary objective of the Main Algorithm is to select a variety of good sets of
compliance options for the Market Algorithm to work on. As can be seen in the following
example, this may not mean selecting the least-cost options for each affected unit.
Assume that a utility must reduce its annual emissions by 30,000 tons of S02. The utility has
three affected units. The following table presents the compliance options available for each unit
along with the levelized $/ton cost and expected impact (tons reduced) of each of those options:
1M Compliance Options
FUEL SWITCH SCRUB
$/ton tons $/ton tons
BIGCOAL 1 400 10,000 500 30,000
BIGCOAL 2 550 10,000 700 30,000
BIGCOAL 3 600 10,000 800 30,000
166
-------
In this case, selecting the cheapest compliance options (fuel switching) at all of the units would
not be the least-cost strategy. Such a plan would cost $15.5 million/year6 on a levelized basis,
whereas a decision to scrub BIGCOAL 1 (and meet the utility's compliance requirements with
that one action) would be cheaper, costing only $15 million/year7.
Heuristic #2's Main Algorithm therefore must consider not only a compliance option's unitized
cost ($/ton) but also the amount of S02 reductions that the option can achieve. What
characterizes a compliance option as being "good" is both its low cost and its high impact.
Based on this fact, STARRSS must rank the utility's compliance options on more than just cost
($/ton). Since the Main Algorithm must produce multiple compliance plans, a procedure was
designed that allows the algorithm to establish a variety of rankings, instead of just one. These
rankings will be in ascending order and will be based on what will be called the minimization
factor, or "M-factor." The M-factor is a numeric value which is calculated for each compliance
option based on the following formula:
M-factor = (kj)($/ton) + (k2)(Ej)(l/tons) + (k3)(E2)($/ton)(l/tons)
where: $/ton refers to each compliance option's unitized cost; 1/tons is the
inverse of each compliance option's emission reduction impact; k,, k2, and
k3 are weighting factors that sum to 100%; and Et and E2 are equalization
coefficients (and will be addressed later in this section).
Heuristic #2's approach is referred to as a Varying Prioritization approach since it establishes
a variety of different rankings of compliance options (30 different rankings, to be exact) where
each ranking prioritizes the options with a different weighting of the options' unitized costs,
impacts, or a combination of the two.
As a start, STARRSS will set kl = 100% (and thus, the other two weighting factors will be 0%).
Therefore, the M-factors for all of the utility's compliance options will be the options' unitized
costs ($/ton). Ranking the options in ascending order will place those options with the lowest
$/ton cost at the top of the list. STARRSS will start at the top and begin its selection process,
moving all the way down the list. Obviously, as STARRSS moves down the list, it must keep
track of which generating units each compliance option affects since two options cannot be
chosen for the same generating unit. Therefore, whenever STARRSS selects an option, it
temporarily deactivates any subsequent options in the list that also apply to the same generating
unit.
6 $15.5 million/year« [$400 x 10,000] + [$550 x 10,000] + [$600 x 10,000]
7 $15 million/year = $500 x 30,000
187
-------
Each M-factor ranking will "spawn" several compliance plans based on multiple rounds of
selection. These multiple selection rounds will be addressed below. For the time being, the
important issue is the M-factor ranking.
After STARRSS has developed one or more compliance strategies from the above M-factor
ranking (where k, = 100%), the weighting factors are changed. Obviously if kj were set to 0%
and k2 were set to 100%, it is likely that the M-factor ranking would change substantially. With
the full weight being placed on the second term in the M-factor calculation, those options with
the largest impact (i.e., tons of S02 reduced) would have the smallest values for the inverse of
the impact (1/tons) and would therefore be at the top to the list.
Incidentally, the inverse of the impact is used in the M-factor calculation for the following
reason. As was stated earlier, "good" compliance options can have either low $/ton costs and/or
high impacts. Therefore, if STARRSS is to appropriately combine an option's characteristics
(and select the options with the lowest M-factors), the inverse of the impact must be used.
Thus, a large impact translates into a smaller M-factor and therefore a better ranking of the
option.
As the k2 weighting factor is increased, the benefits of large-impact compliance options begin
to compete with (and ultimately overshadow) the benefits of options that merely have low
unitized costs. With a different ranking in place, STARRSS can now repeat the selection
process, starting at the top of the list and picking the lowest M-factor options for all of the
utility's units. This reranking is performed 30 times with various values of kj, k2, and k3. Each
time that this reranking produces a fundamentally different list, a different set of options will
be selected.
The third term in the M-factor calculation is merely a combination of the first two. Effectively,
this term is a type of cost-benefit ratio, in that it measures how large an option's unitized cost
is in relation to the option's impact. Obviously, the lower this value is, the more attractive is
the compliance option. If k3 is left at 0%, then this cost-benefit term will not affect the
M-factor. However, increasing the value of k3 will cause those options with favorable cost-
benefit ratios to rise in the ranking.
The M-factor calculation involves two other coefficients: the equalization coefficients, E, and
E2. These coefficients put the three terms in the calculation on "equal footing." Realizing that
1) the unitized costs for most compliance options are in the hundreds of dollars per ton, and that
2) the impacts are generally in the thousands or tens of thousands of tons, one can see that the
terms in the calculation are mismatched. Since the second term is the inverse of the impact,
its value will usually be around 0.001 or 0.0001 (1/1000 or 1/10000, respectively), while the
first term will be in the 100s. Thus, the first term could be six orders of magnitude larger than
the second. If the M-factor calculation is not adjusted for this magnitude differential, the
overall process will still work; however, k1 will have to drop to 0.0001% (and k2 will have to
rise to 99.9999%) before any meaningful changes will occur in the ranking of compliance
188
-------
options. In order to bring the weighting factors into a more appropriate range, equalization
coefficients will be used to "equalize" the effects on the M-factor from the three terms in the
calculation.
The equalization coefficients are calculated at the beginning of the Main Algorithm ~ during
a preliminary analysis of the utility's compliance options. The coefficients are based on the
mean value (across all options) of each of the terms in the M-factor calculation and are
calculated in the following manner:
Ej = Mean of S/ton = (Mean of $/ton) x (Mean of tons)
Mean of 1/tons
E2 = Mean of tons
For example, if the average value of the unitized costs for all compliance options was $500/ton
and the average impact was 10,000 tons, then E; would be 5,000,000 and E2 would be 10,000.
Having explained how all three M-factor terms are placed on equal footing, how then are the
weighting factors (k„ k2, and k3) calculated? STARRSS has a table of values for the weighting
factors, in which each row of values is used to define each ranking (or reranking) of the
compliance options. The following chart shows the table of k-values:
189
-------
Ranking # k, Js2
1
100
0
0
2
85
0
15
3
70
0
30
4
55
0
45
5
40
0
60
6
25
0
75
7
10
0
90
8
0
0
100
9
85
15
0
10
70
15
15
11
55
15
30
12
40
15
45
13
25
15
60
14
10
15
75
15
0
15
85
16
70
30
0
17
55
30
15
18
40
30
30
19
25
30
45
20
10
30
60
21
0
30
70 I
22
55
45
0 1
23
40
45
15 I
24
25
45
30
25
10
45
45
26
0
45
55
27
40
60
0
28
25
60
15
29
10
60
30
30
0
60
40
Each particular row of k-values "seeds" a new ranking of the utility's compliance options.
Within the context of a single ranking, several compliance plans could be developed. Round
I of the selection process was described earlier: basically, the top options are picked until an
option has been chosen for every unit. Anytime that STARRSS encounters an option for a
generating unit that has already been addressed by a previously selected option, the program
will skip the new option. Obviously, this is justified by the fact that the "challenger" (i.e., the
new option) has a less favorable M-factor than the "incumbent" (i.e., the already-selected
option). However, the M-factor is not the ultimate measure of optimality; it is merely a
mathematical construct for temporarily ranking compliance options, and a close face-off between
190
-------
a challenger and an incumbent may be worth investigating further. Bumping the incumbent and
replacing it with the challenger could actually produce a better compliance strategy. For this
reason, five "rounds" will be performed for each ranking. After developing the list of
compliance options from the "master" ranking, STARRSS will search for any challenger option
that has an M-factor that is close to an incumbent's (less than 5% higher, to begin with). If it
finds such a challenger, STARRSS will replace the incumbent and thereby create a new
compliance strategy. STARRSS then returns to the master strategy again to investigate other
swaps. This swapping arrangement will continue until another four variations on the original
compliance strategy are developed. If STARRSS gets to the bottom of the list before it has
developed five variant strategies, the cut-off percentage is doubled, and STARRSS returns to
the top of the list to continue the process.
A variant of this multiple-rounds process (where marginally higher M-factor options can replace
incumbents) is used to solve the non-compliance problem; this situation occurs when STARRSS
reaches the bottom of the ranking before it achieves compliance. The rankings that put very
little emphasis on an option's impact (focusing instead on $/ton) can result in a strategy of
completely low-impact options that will not bring the utility into compliance. In this case, a
modified round is performed, where a challenger is assessed not only on its M-factor (and how
it compares to the incumbent) but also on how much additional impact (in tons of S02
reduction) that it achieves relative to the incumbent. Since the solution to this problem involves
finding more tons, challengers that provide less impact are skipped immediately. During this
modified round, the challenger-incumbent M-factor percentage is allowed to rise until enough
challengers with positive impact contributions have bumped their incumbents and covered the
shortfall.
All compliance strategies that are developed within the Main Algorithm and which at a
minimum meet the utility's compliance requirements are stored in a single list. The present
value of the total cost of each strategy is calculated before it is put on the list. This cost is
merely the summation of each selected compliance option's cost ($/ton x tons reduced), minus
the linkage benefits between any selected options, plus the revenue or minus the cost of any
allowance transactions required to bring the strategy into compliance. If the master list grows
too large during the heuristic process (more than 255), the strategies that have the highest costs
are dropped from the list. At this point, each strategy is passed to the Market Algorithm for
possible improvements.
Maifcet Algorithm
The Market Algorithm takes the individual compliance strategies that are produced by the Main
Algorithm and explores ways in which the total cost of compliance can be reduced through
economically beneficial allowance transactions. STARRSS will first remove any uneconomical
allowance sales by removing options from the strategy whose unitized costs ($/ton) are higher
than the levelized sale price of allowances. After exhausting options which cost more per ton
191
-------
than allowances, STARRSS will examine the list of "unused" compliance options for possible
additions to the strategy's portfolio; if t e selling price ofi allowances is higher than the cost of
one or more of these options, STARRSS will add these options to the strategy, sell the excess
allowances at a profit, and reduce the overall cost of compliance.
Specifically, the Market Algorithm will function in the following manner. First, the compliance
strategy's options are ranked in ascending order according to their unitized costs. STARRSS
begins by temporarily removing the most expensive option and replacing it with allowances.
If the cost of the strategy decreases, STARRSS drops the option from the strategy. The
program works its way up the list towards cheaper options until it finds an option which it is
not economical to drop.
At this point the Market Algorithm prepares to add compliance options to the strategy by
sorting the list of "unused" options, again according to unitized cost. Starting with the cheapest
item on this list, and moving towards the most expensive, STARRSS will compare the cost of
the strategy with and without each option, and add the option to the strategy if the increased
allowance sales (or reduction in allowance purchases) can economically justify it. When it
reaches the first option whose inclusion would not reduce the cost of the strategy, the option
is not added to the strategy, and the strategy is inserted into a final list of strategies to be passed
on to the evaluator. The length of this list is determined by the Number of Strategies to be
Evaluated/Saved data item on the Develop STARRSS Strategies screen.
Allowance Trading Limits and Option Cost Irregularities
The costs of strategies and options used internally in both heuristic processes described above
are modified somewhat to handle special situations. If a strategy considered at any point would
involve buying more allowances than the limit set by the user, the excess allowances are
automatically priced at a million dollars per ton. This circumvents cumbersome and
inappropriate program logic that would discard compliance strategies that marginally violate the
allowance purchase constraint. As it stands, the internal costs for strategies that significantly
violate that limit become very high, and those strategies are inevitably discarded. Similarly,
allowance sales beyond the user-specified limit are priced at zero dollars per ton. This
discourages STARRSS from continuing to consider more and more options to overcontrol
emissions for the purpose of allowance sales that exceed the allowance sales constraint.
Finally, compliance options with zero or negative impact and positive cost are assigned
extremely high M-factor values (to discourage their selection), and options with positive impact
and negative cost are assigned extremely low negative M-factor values (to encourage their
selection). The user should note that these special cost calculations are never reflected in the
reported costs. They are used internally by the heuristics and discarded before the final list of
strategies that have been developed are submitted to the evaluator for analysis.
192
-------
10.0 CUSTOMIZED DATABASES
STARRS S is delivered to all government agencies with one customized database for each utility
that comes under that agency's jurisdiction. The set of delivered databases will also include
complete databases for any multi-state holding companies and power pools to which individual
operating companies under the agency's jurisdiction belong. Deliveries to utilities will include
each recipient's specific database. Deliveries to all other organizations will include a "generic"
database.
THESE DATABASES ARE MEANT TO PROVIDE USERS WITH A HELPFUL
STARTING POINT FOR MODELLING SPECIFIC UTILITIES. HOWEVER, ALL OF
THE VALUES IN THE DATABASES MUST BE CHECKED FOR ACCURACY.
NEITHER EPA NOR RCG/HAGLER, BAILLY IN ANY WAY GUARANTEES THE
VALIDITY OR ACCURACY OF THE INFORMATION.
Although some of the information in STARRSS can be reliably estimated from historical data
(such as unit capacities, allocated allowances, etc.), much of the STARRSS input data involves
forecasts that the user must develop (e.g., allowance price forecasts, fuel price forecasts, etc.).
For many of these data items, illustrative values have been entered into the delivered databases
solely for the purpose of helping the user become acquainted with the system, and allowing the
user to run the program immediately upon delivery. Had these inputs been left at zero,
executing the program would have produced nonsensical results.
As mentioned above, the user should verify all information in the delivered databases. To
prioritize which information most needs checking and modification, the inputs in these databases
are divided into two categories: 1) forecasts that use illustrative values (and therefore should
be changed immediately), and 2) historical information that came from published sources. The
remainder of this chapter clarifies which data entries are purely illustrative and which are from
published sources.
All inputs in the delivered utility-specific databases cover only the Medium Forecast (with an
associated low/medium/high probability distribution of 0%/100%/0%). No ranges or
probabilities are predicted for any of the data items. Such an arrangement fails to take
advantage of STARRSS' multi-scenario analysis features. The user is therefore encouraged to
develop ranges and to input low, medium, and high forecasts for as many data items as
possible, thereby capturing the benefits of STARRSS1 multi-scenario methodology.
DISCLAIMER
193
-------
10.1 ILLUSTRATIVE DATA
The following is a list of STARRSS data inputs for which no attempt was made to produce or
predict accurate information. The values listed are the illustrative values entered in the
databases. These are not suggested values. They should be changed to reflect the specific
circumstances of the utility being modelled. Table 10-1 shows the data inputs for which the
user will need to develop specific forecasts.
Table 10-1. STARRSS Data Items Containing Illustrative Values
DATA ITEM
ILLUSTRATIVE VALUE(S)
Allowance Price Forecasts
Purchase Price (1995)
Sale Price (1995)
$500 (escalated at 5%)
$400 (escalated at 5%)
¦
Utility Marginal Energy Costs (1992)
Utility Marginal Capacity Costs (1992)
$50/MWH (escalated at 5%)
$ 100/kW (escalated at 5%)
Utility Cost of Capital
Utility Return on Equity
Equity Percent of Capital
10%
12%
50%
Escalation Rates
Capital Costs
Variable O&M Costs
Fixed O&M Costs
5%
5%
5%
Effective Tax Rate
34%
194
-------
10.2 PUBLISHED HISTORICAL INFORMATION
Each delivered database has been customized with information pertaining to a specific utility.
All of the unit-specific information in the delivered databases has been drawn from published
sources of historical information. The majority of the data was extracted from reference 2
(hereafter referred to as "the CQF Report"), reference 3 (hereafter referred to as the "NADB"),
and reference 4 (hereafter referred to as "the UDI Report"). These sources provide estimates
of unit operating characteristics, fuels, and allowance allocations.
10.2.1 Unit Information
STARRSS Version 1 delivered databases of operating utilities, holding companies, or power
pools include only those units within the system affected by the Clean Air Act (ie. those units
which receive allowances). Table 10-3, at the end of this chapter, shows the units included in
each of the databases for this STARRSS delivery. This section lists the data items defined for
units in these databases, and describes the data sources and methods used to derive the
information.
~ Unit Name and Number: The unit name and number label was altered from the
NADB label to fit a 10-character field.
~ Capacity (MW): The values entered for capacity represent the unit's 1989
summer net dependable capacity as provided by NADB.
~ Heat Rate: The values entered for heat rate represent the unit's 1989 generator
full load heat rate (in Btu/kWh) as provided by NADB.
~ Variable Operation & Maintenance Costs: The UDI report lists Variable O&M
costs for all of the major coal-fired U.S. plants. Not all coal-fired plants had this
information available, however. Variable O&M costs were given at the plant
level only, and do not account for differences between units that may result from
differing ages or the presence of pollution control equipment. UDI presented the
1990 variable O&M costs, which were escalated to 1992 dollars using the
General Purpose Machinery and Equipment category of the Producer Price Index
(U.S. Bureau of Labor Statistics, March, 1992).
~ Capacity Factors: Where possible, unit capacity factors reported in the UDI
report were used in STARRSS. For units not covered in the UDI report,
capacity factors were calculated by dividing the baseline heat input by the
potential heat input (calculated from NADB), yielding an average capacity factor
for the years 1985-1987. Any estimated capacity factor exceeding 90% was reset
195
-------
to 90%. Table 10-6 at the end of this chapter lists the units in the delivered
database whose capacity factors were calculated using information from NADB.
Fuel Used: The fuel information was compiled by cross-referencing historical
information contained in the UDI and CQF reports. Price forecast information
comes from EIA macroeconomic forecasts for the next 20 years. The derivation
of fuel price and sulfur content will be explained in greater detail in the next
section.
Flue Gas Desulfurization Efficiency: Historic FGD S02 removal efficiency
information from the UDI report was included for those affected units with pre-
existing FGD equipment.
Baseline Heat: The values entered for baseline heat represent the boiler-
generator average total heat input for the years 1985-1987 (in Trillion Btus) as
provided by NADB.
Phase I Allowances: Phase I allowance calculations are relatively
straightforward. Table A of section 404 of the Clean Air Act Amendments of
1990 (Title IV) gives the basic allowance allocation for units at 110 generating
facilities. These allowance allocations are adjusted by the creation of the 2.8%
EPA Allowance Sales and Auction Reserve. In addition, Section 404(a)(3)
allocates 200,000 Phase I allowances on a pro rata basis to units in Ohio, Illinois,
and Indiana. The calculation of Phase I allowance allocations for units included
in the delivered databases is shown in Table 10-4, at the end of this chapter (note
that units are listed according to their holding company affiliation; Table 10-2
lists utility holding companies and their operating subsidiaries).
Phase II Allowances: Phase II allocations are somewhat more complex. After
basic allowances are assigned according to the provisions of section 404
(according to the category each affected unit falls in) adjustments are made to
account for the following factors:
-The ratchet factor necessary to achieve the 8.9 million ton national
emissions cap;
-Bonus allowances allowing qualified units to run at a 60% capacity
factor (total bonus pool ratcheted to 530K);
-Withholding of allowances for the Conservation and Repowering
Reserve;
-Withholding of allowances for the EPA Sales and Auction Reserve;
196
-------
-Addition of miscellaneous bonus allowances to qualifying units (e.g.
units in "clean" states, selected units in ten states with high reduction
obligations, etc.).
STARRSS Version 1 databases include allowance allocations for units through
the year 2009. Allowance allocations change slightly after that year, as several
bonus pools and reserves expire. Furthermore, allowances in STARRSS are
allocated by generating unit rather than by boiler. This will result in no change
in allocation for units with a one-to-one boiler-generator configuration. For
multi-header boilers, STARRSS assigns allowances to each generator by
multiplying the total number of allowances assigned to the multi-header
configuration by the generator's share of the multi-header configuration's total
capacity. This results in no net change in overall allowance allocations, although
some allocations may appear different from available data which lists allowance
allocations by boiler. The precise calculation of allowance allocations (by boiler)
for units included in this database delivery is given in Table 10-5, at the end of
this chapter (note that units are listed according to their holding company
affiliation; Table 10-2 lists utility holding companies and their operating
subsidiaries).
Finally, for utility systems with a partial interest in jointly-owned units, several unit
characteristics were pro-rated according to percentage ownership, as given in the UDI report.
Pro-rated characteristics include the capacity, baseline heat, Phase I allowances, and Phase II
allowances. For example, if a utility system owned 10% of a 900MW unit with a baseline of
10 trillion Btus, and 2000 Phase II allowances, it would show up on the STARRSS affected unit
list as a 90MW unit with a baseline of a trillion Btus and 200 Phase II allowances. Although
it makes sense to assume that a utility with a 10% share of a unit controls 10% of the unit's
allowances, this may not necessarily hold true, and should be verified to the extent possible.
10.2.2 Fuel Information
Included in each STARRSS database is fuel information defined for each unit. Of all of the
historical, unit-related information contained in the STARRSS delivered databases, this is the
most subject to error, and must therefore be scrutinized closely. The fuel price and emissions
rate information was drawn primarily from the Department of Energy/Energy Information
Administration's Cost and Quality of Fuels for Electric Utility Plants - 1990 (CQF).
Information from U.S. Coal Plant Statistics 1990 (UDI) was also used. The fuels defined in
delivered databases represent preliminary information indicating the types of fuels burned at
units within the system and historical cost information. The basic process employed was to:
197
-------
1) assess the sulfur content of fuels by examining the fuel or multiple fuels that
were delivered to each affected plant during 1990;
2) examine and report the spot price of this fuel or fuel blend in 1990; and,
3) apply the EIA fuel price forecast escalation rates to derive 20-year fuel price
forecasts.1
Section 8.2.3 will outline the process used to derive the fuel quality information, Section 8.2.4
will describe the sources used for fuel price information, and Section 8.2.5 will suggest a
research design for incorporating more accurate fuel information.
Fuel Sulfur Content
Coal
The "Origin of Coal Received by Company and Plant" table (Table 36) of the CQF report lists
the origin and quality of coals received at every coal-fired plant in the United States in 1990.
The UDI report devotes a table ("Table 1: Age & Status of U.S. Coal-Fired Units by NERC
Region") to the current status of coal-fired units, which includes the 1990 average sulfur content
of the boiler fuel. By cross-referencing these tables, a profile of the quality of fuel burned at
each unit could be derived. In particular, cross-referencing the UDI and CQF reports revealed
whether different units within a given plant burned the same coal, the same coal blend, or
different coals during 1990.
Calculation of fuel bum emission rate (in lbs. S02/MBtu) depends on three pieces of
information: coal heat content (in Btus/lb. coal), coal sulfur content (by percent weight), and
the conversion factor for sulfur to sulfur dioxide (2 lbs. SO/lb. Sulfur).2
The same set of escalators were used for &!! coats, regardless of regional or other differences.
Different forecast escalators were used for oil and natural gas.
The calculation proceeds as follows:
1/(Heat Content) * (Sulfur Content %)/100 *2*10' = Emission Rate (Ibs./MBtu)
The conversion factor of two assumes that virtually all of the coal's elemental sulfur is oxidized to S02
during combustion. The 106 factor simply converts Btus to MBtus. Combining all of the constants leads
to the following simplified equation:
20,000/{Heat Content) * (Sulfur Content %) = Emission Rate (Ibs./MBtu)
where 20,000 = 2 * 106/100. This equation was used to calculate emission rates from the information
provided by the CQF report.
198
-------
In many instances, units burn a blend of fuels rather than a single fuel. The delivered
databases, however, do not define fuel blends; instead, fuel blends are reported as a single fuel
with aggregate fuel quality and price. Furthermore, in some cases, an analysis of the CQF
report indicated that fuel blends at some units included only a subset of all the fuels received
at the plant. In these cases, the average sulfur content reported in the UDI report was used as
a benchmark to infer which of the received coal types were most likely blended. Based on this
determination, a weighted average heat content, sulfur content, and delivered cost was calculated
for the fuel blend. Again, these estimates only partially capture the actual fuel situation utilities
face for the affected units on their systems.
The fuel names or labels used in the delivered databases are designated according to the plant
burning the fuel, and the fuel burn emission rate. For example, a fuel label might read
"BIGCOAL-MS". This label denotes a medium sulfur coal burned at the "BIG COAL" plant.
For fuel labelling purposes, the following ranges were used to designate a coal as low, medium-
, or high-sulfur:
In addition, where space permitted, a designator indicating the fuel's state of origin was included
in the label. A fuel label of this type might read "BCOALMS-AL", signifying a medium sulfur
coal from Alabama burned at the "BIG COAL" plant. Naturally, the user is free to adopt
his/her own labelling conventions in the process of defining fuels.
For units burning significant amounts of oil during 1990, price and quality information from
Table 43 ("Quantity, Average Delivered Cost, and Quality of Fossil-Fuel Receipts by Company
and Plant") of the CQF report served as the reference for the quality of petroleum burned at the
unit. The fuel burn emission rate was calculated in a similar fashion to that described for coal.5
Oil heat and sulfur content is not as conveniently reported as it is for coal. The average heat content
of oils were calculated using cost information provided in cents/MBtu and $/Bbl as follows:
1/(Btu Cost) * (Barrel Cost) * 100 = Heat Content (MBtu/Bbl)
Using conversion rate of 42 gallons/Bbl and 5.8 lbs/gallon, along with sulfur content by weight reported
in the CQF report allowed the derivation of oil burn emission rate, in lbs SO^MBtu.
Fuel Type
Low Sulfur (LS)
Medium Sulfur (MS)
High Sulfur (HS)
Emission Rate (lbs./MBtu)
less than 1.2
1.2 - 2.5
greater than 2.5
Oil
199
-------
The fuel labelling convention for oil indicates the fuel and the plant at which the fuel was
burned. For example, an oil-burning unit might have a fuel label reading "OIL-SMLLOIL",
indicating an oil burned at the "SMALL OIL" unit.
Natural Gas
As with oil, Table 43 of the CQF report was used to determine whether or not a significant
amount of natural gas was burned at a particular unit. The S02 emission rate for natural gas
was assumed to be zero for STARRSS analysis purposes, so no derivation of fuel quality was
necessary.
The fuel labelling convention for natural gas indicates the fuel and the plant at which the fuel
was burned. For example, an natural gas-burning unit might have a fuel label reading "GAS-
TURBN1", indicating natural gas burned at the "TURBINE 1" unit. Note that many gas
burning units also burn significant quantities of oil. STARRSS delivered databases do not
reflect this common situation.
"Current" Fuel Prices
The "Receipts and Average Delivered Cost of Coal by Type of Purchase, Company, and Plant"
table (Table 42) of the CQF report lists the aggregate delivered cost of spot and contract coal
on a plant-by-plant basis in 1990. Since contract prices may reflect negotiated agreements from
five or ten years ago (when coal prices were much higher), the contract deliveries were not
considered to be representative of the current or projected market. Therefore, where possible,
the spot price of coal delivered to a plant was used to denote the current fuel cost (1992).4
However, in some cases, plants made no spot purchases, or made small spot purchases
unrepresentative of the fuel burned at the plant. In these cases, the average contract price was
used instead of the spot price. For units burning a subset of the aggregate fuels, the spot price,
contract price, and the average delivered cost for the specific fuel (or fuel blend) burned at the
unit were compared to determine the most representative price for the fuel.
For oil and natural gas, the average delivered cost reported in Table 43 of the CQF report was
used for the fuel cost at units burning oil or natural gas. Again, for units burning both oil and
natural gas, only one fuel was defined; the user will need to define blends of oil and natural gas
where appropriate.
While fuel prices currently input in the STARRSS databases will allow the user to run
STARRSS and to conduct preliminary screening exercises, the usefulness of these prices is
extremely limited in a formal evaluation of a utility's compliance plan. In particular, historical
4 As spot coal prices have not changed much between 1990 and 1992, the 1990 CQF values were not
inflated or otherwise adjusted.
200
-------
prices from a single year cannot capture the contract situation a utility faces for a given plant
or unit. Whether the 1990 price for coal at a unit reflects the beginning of a long-term contract
or the expiration of a contract has significant consequences for a utility's evaluation of the
economics of fuel switching or blending. The fuel contract situation of a unit also effects the
long-run costs the utility faces when it implements compliance options that change the amount
of fuel consumed at that unit. Furthermore, for units burning petroleum, 1990 prices were
influenced by singular events (ie. Iraq's seizure of Kuwait). Therefore, a fuel price forecast
based on a single-year analysis of average spot prices or delivered costs may significantly
distort the costs of any compliance option that changes a unit's fuel consumption.
Fuel Price Growth Rates
The STARRSS data inputs include separate national fuel price growth rates for coal, oil, or
natural gas. These price projections come from DOE/EIA's Annual Outlook for U.S. Electric
Power. 1991: Projections Through 2010 (July 1991). These price projections make no
distinction between regions of the country or between fuel qualities.
10.2.3 Research Recommendations
The user should acquire more detailed information to accurately portray the fuel situation and
options of a utility plant or unit. This information may include:
~ volume, quality, F.O.B. mine price and transportation costs of spot coal
purchases;
~ volume, quality, F.O.B. mine price and transportation costs of contract coal
purchases;
~ details of current coal contracts, including:
- expiration date;
- price escalation methodology (or expectations of future price
escalation) and,
- market price reopener provisions; and
»• volume, quality, F.O.B. mine price and transportation costs of alternative coal
supply options being considered by the utility for future coal supplies (spot and
contract).
Use of these data items should put the user in a good position to model both the utility's current
fuel situation and the economic basis for fuel-based compliance activities.
Note that even if the same coal is burned at several plants within a utility system, the delivered
price for that coal will vary depending on the cost of transportation to each plant, and market
201
-------
conditions prevailing at the time each coal contract was entered into. Coals must therefore be
modelled on a plant-by-plant basis.
Finally, for a STARRSS analysis, if the user knows he/she will not define a compliance option
for a particular unit, the user need not obtain more accurate fuel price information for that unit,
although the user must still verify fuel sulfur content information. Because STARRSS models
compliance costs on an incremental basis, accurate prices are not necessary if they will not be
compared to costs for new fuels. However, STARRSS will still need to know the affected unit's
emissions (and therefore fuel quality) to determine the overall system S02 reduction obligation.
10.3 TABLES: DELIVERED DATABASE INFORMATION
The following tables are samples of customized tables that are included in a formalized delivery
of STARRSS. Each direct recipient of STARRSS (e.g., state regulatory commissions) receives
a set of customized tables that contain information for all of the databases that are included in
the recipient's delivery.
SAMPLE TABLES
Table 10-2. Holding Company and Operating Utility Systems Included in STARRSS
Delivered Databases.
Sulfur Power & Light Company
Table 10-3. Units Included in STARRSS Delivered Databases.
SULFUR POWER & LIGHT
Baseline
Calculated
Unit
Capacity
Heat
Heat
S02 Emis.
Allowances
Name
{MW)
Rate
(TBTUs)
(tons)
PhaseI
Phasell
BIGCOAL 1
650.0
10000
26.700
75293
36500
14000
BIGCOAL 2
650.0
10000
27.300
84761
37000
14500
MEDCOAL 1
350.0
10500
32.320
44656
44000
17500
MEDCOAL 2
350.0
10600
32.800
46244
44500
18000
MEDCOAL 3
350.0
10400
32.860
44424
45000
18000
MEDCOAL 4
350.0
10400
32.260
7984
0
17500
SMALLOIL 1
50.0
13800
0.370
77
0
200
SMALLOIL 2
50.0
13600
0.640
115
0
330
SMALLOIL 3
80.0
13500
1.040
171
0
600
202
-------
Table 10-4. Phase I Allowance Calculations for Units in Delivered Databases.
Boiler Gen. Basic Sec. 404 Total EPA 2.8% Final
Plant Name Number Number Phase I Additions Phase I Reserve Phase I
SULFUR POWER & LIGHT
BIGCOAL 1 1 37522 0 37522 1022 36500
Table 10-5. Phase II Allowance Calculations for Units in Delivered Databases.
Boiler Gen. Basic Ratcheted Cons./Repower 2.8% Sales/Auc. Sec. 405 Final
Plant Name Number Number Phase II Phase II Adjustment Adjustment Addition Phase II
SULFUR POWER k LIGHT
BIGCOAL 1 1 15985 14532 140 392 0 14000
Table 10-6. Units in Delivered Databases For Which NADB Was Used to Calculate Capacity
Factors.
Plant Name Number
SULFUR POWER & LIGHT
BIGCOAL 2
Table 10-7. Jointly-owned Units Appearing in Delivered Databases.
Plant Name Ownership
and Unit Number Percentage
SULFUR POWER & LIGHT
BIGCOAL 2 50.00
203
-------
11.0 DESCRIPTIONS OF COMPLIANCE OPTIONS
This chapter provides a rudimentary description of some of the many compliance options
that are available to utilities as they develop Clean Air Act compliance strategies.
Specifically, the chapter is divided into four basic sections:
(1) Pollution Control Technologies
(2) Fuel Switching
(3) Conservation and
(4) Other Compliance Activity
Although the majority of this chapter is dedicated to describing pollution control
technologies, this does not mean technological options are more important or are preferable
over the other options. It is simply that many of the other options are difficult to summarize
in a general fashion. Typically, their cost-effectiveness and viability are very dependent on
the specific utility or generating unit being analyzed. This is also the case with
technological options, but more literature exists upon which to base general descriptions.
In the Pollution Control Technology section, each subsection describes the general process
for each pollution control technology, the primary strengths and weaknesses utilities will
consider for each process, and approximate cost and performance information. Because
sulfur reducing technologies have evolved dramatically in the last few years, even these
generic cost and performance parameters can only be broadly estimated. The site-specific
nature of pollution control retrofits further complicates efforts to gauge compliance option
costs. Nevertheless, this chapter attempts to provide a range of information on which users
can base their expectations for one set of common assumptions control costs and
performance.
STARRSS users may develop more specific cost and performance estimates from other
sources. For example, actual bids by pollution control equipment vendors could be used if
available. Also, the Air and Energy Engineering Research Laboratory has published another
PC compatible software system capable of producing more specific and reliable cost
estimates for sulfur and SOz removal systems. This software, the Integrated Air Pollution
Control System, Version 4.0, user's guide, technical documentation, and programmer's
maintenance manual (EPA/600/7-90/022a,b,c, and d) can be obtained from the National
Technical Information Service (specify PB91 506469) for $80.00. Research is underway to
update this software and documentation.
204
-------
11.1 POLLUTION CONTROL TECHNOLOGIES
Pollution control technologies may be divided into four broad categories which are discussed
in the following sections:
~ Precombustion Coal Treatment will discuss general cost and removal
information for physical and chemical coal cleaning options (page 206);
*¦ Combustion Treatment will review the most popular repowering and boiler
S02 removal technologies, and discuss their relative strengths and weaknesses
(pages 207 through 209). Technologies reviewed include:
- Atmospheric Fluidized Bed Combustion (AFBC)
- Pressurized Fluidized Bed Combustion (PFBC)
- Integrated Gasification Combined Cycle (IGCC)
- Furnace Sorbent Injection (FSI)
~ Flue Gas Desulfurization (scrubbing or FGD), will review and provide cost
information and relative strengths and weaknesses for a variety of FGD
processes (pages 209 through 226); and,
~ Reagent Additives, will discuss additives commonly used in conjunction with
FGD systems to improve removal efficiency (pages 226 through 227).
Reagent additives reviewed include:
- Dibasic Acid (DBA)
- Thiosulfate
Precombustion coal treatment involves either washing or chemical treatment of coal to
remove sulfur. Combustion options modify the design of the boiler to improve S02
removal efficiency. In some cases, combustion options also improve the efficiency and
reliability of the boiler. FGD uses sodium- or calcium-based reagents to remove S02 from
post combustion flue gases, while fuel switching often involves modifications to boilers
and/or coal handling equipment to permit burning a lower sulfur fuel.
Coal cleaning falls into two categories: physical coal washing and chemical coal cleaning.
The low cost of physical coal washing makes it an attractive option, although sulfur removal
efficiency also tends to be low. Chemical coal cleaning processes aim to remove greater
amounts of sulfur, but none of the processes has yet proven cost-effective. Development of
commercially viable chemical cleaning processes is likely to be five to ten years away.
Combustion treatment options use a variety of combustion processes, often combined with
calcium-based reagents directly in the furnace, to reduce S02 emissions from the coal
205
-------
combustion gases. Except for FSI and new duct sorbent injection techniques now under
development (not discussed herein), the high capital costs of boiler retrofits for combustion
options renders them non-competitive with other S02 removal processes. There are,
however, benefits to combustion options aside from S02 control; improved boiler efficiency
and improved reliability keep the cost of power at modified boilers lower than conventional
systems with pollution control retrofits. As a result, utilities have utilized combustion
options mainly with boilers at or near retirement, where the largest efficiency gains could be
realized.
The maturing of flue gas desulfurization technologies has led to a variety of control options
which have a fairly similar range of overall control costs. The most appropriate FGD option
or set of options for a utility system will depend on site-specific factors associated with
retrofitting its units and the amount of S02 reduction the system needs to achieve to ensure
continuous compliance. Other factors ranging from the supply and cost of reagents to the
volatility of S02 allowance prices may also affect the utility's choice of FGD technologies.
Boiler retrofits for fuel switching carry considerably lower capital costs but more variation
in costs from unit to unit. In some cases, no boiler modifications are needed for fuel
switching. In general, initial concerns about the high volatility and moisture of low-sulfur
western coals have diminished, reducing capital cost estimates for boiler retrofits to
accommodate even these coals. The cost differential between fuels under consideration
plays a much larger role in determining the economic viability of a fuel switch than capital
costs associated with boiler modifications. Section 11.2 will discuss the economics of fuel-
switching in greater detail.
11.1.1 Pr£CQrn|)|ist]qh C^oal Clcpnin^
Physical Coal Cleaning
During physical coal cleaning raw coal is tumbled, screened, and sorted into size
classifications. Each size of coal in water is further acted upon by vibrating tables or froth
flotation cells to physically separate pyritic sulfur bearing rock, shale, and other impurities
from the coal. Although physical coal cleaning is a relatively inexpensive means of sulfur
reduction, costs can vary considerably. The economics of physical coal cleaning tend to be
plant and coal seam specific and coal seam. Washing coal with less than 1% sulfur content
(by weight) is generally impractical. Capital costs for coal cleaning can range from 10-30
$/kW, fixed O&M costs can vary from 0.6-6 $M/yr, depending on the size of the plant, and
variable O&M costs can range from 0.75-1 $/MWh. Typical S02 removal efficiency ranges
from 10-30%.
206
-------
Chemical Coal Cleaning
Most chemical coal cleaning efforts have used chemical reagents in a tub of pulverized coal.
The reagents react with both organic and inorganic sulfur, and the mix is centrifuged to
separate the coal from its impurities. These methods have proven costly, and none have
been demonstrated commercially.
In perhaps the most promising precombustion method for coal cleaning, ethanol and ethanol
vapors decompose and bind to coal, reacting with organic and inorganic sulfur in the coal.
The by-products, elemental sulfur and acetaldehyde, are commercially saleable. The end
product is a finely pulverized low sulfur coal that can be used directly in boilers (see, for
example, Compliance Strategies Review, 3 February 1992). Initial estimates suggest that the
90% sulfur removal can be achieved at low cost using this process. Ohio researchers are
seeking funding for a demonstration facility that would apply this process, but it has not yet
seen demonstration or commercial use.
11.1.2 Combustion SQ2 Reduction Technologies
This section will describe briefly three common combustion technologies that utilities may
consider for Phase I or Phase II compliance. Two of these technologies involve extensive
boiler retrofits, or repowering; in addition to improvements in unit efficiency, combustion
technologies that repower an existing boiler may qualify the utility for bonus allowances
from EPA and an extension in the unit's compliance deadline.
Combustion options treat coal directly in the unit boiler to reduce S02 emissions. In
addition to S02 control, combustion options can provide other benefits: improved unit
capacity, improved unit heat rate, and a high level of NOx reduction. Although retrofitting a
boiler with a combustion technology tends to be much more expensive on a per kW basis
than flue gas desulfurization options, the other benefits of improved efficiency and unit
dispatch may offset the increased cost, particularly if the retrofit takes place at an older, less
efficient boiler that the utility is considering for retirement. Many combustion options are
eligible for funding through the Department of Energy's Clean Coal Technology program,
further offsetting costs to the utility. For new facilities, combustion technologies and flue
gas desulfurization technologies are estimated to be cost-competitive on a $/kW basis.
Atmospheric Fluidized Bed Combustion
Atmospheric Fluidized Bed Combustion (AFBC) injects powdered coal and limestone
together into the boiler. Air pressure from combustion creates a "fluidized bed," in which
the limestone reacts with S02 directly in the furnace. The waste by-product is a relatively
stable calcium sulfate powder. Because AFBC uses low combustion temperatures, the
process inhibits NOx formation. The process achieves S02 removal in the range of 90-95%,
and NOx emission reduction of approximately 70-90%. Primary disadvantages to the AFBC
207
-------
process include: high volume of waste production caused by high molar ratio of calcium to
sulfur, and possible upgrades to electrostatic precipitators and fabric filters to accommodate
increased ash and dust loading. Improvements in rated capacity and/or heat rate are boiler-
specific.
Pressurized Fluidized Bed Combustion
The Pressurized Fluidized Bed Combustion process (PFBC) represents an advanced AFBC
process that economizes on unit size and waste disposal requirements. The advance features
allow PFBC to operate at higher pressures, which improve efficiency and reduce the amount
of reagent needed to achieve pollutant removal (relative to AFBC). PFBC carries somewhat
higher capital costs than AFBC but can achieve greater improvements in the boiler's
capacity, particularly if the boiler is near retirement. Utilities consider PFBC most
appropriate as a repowering technology for older boilers.
Integrated Gasification Combined Cycle
The Integrated Gasification Combined Cycle (IGCC) process gasifies the coal in a reactor.
The gasified coal is then combusted in a gas turbine which powers an electric generator
directly. The steam boiler can be used for recovery of heat from the gas turbine exhaust
and deliver supplemental power through a steam turbine. IGCC achieves an S02 removal
efficiency exceeding 95% and NOx reduction exceeding 90%. In some cases, IGCC
substantially improves the capacity of the retrofitted boiler. The cost of retrofitting the
gasification facility makes IGCC the most capital-intensive commercially viable repowering
option.
Furnace Sorbent Injection
Furnace sorbent injection uses powdered limestone (or other calcium-based sorbent) injected
directly into the furnace. The limestone is calcined to calcium oxide, which then reacts with
S02 and combustion air oxygen to form calcium sulfate. Furnace sorbent injection requires
only limited boiler modifications, keeping capital costs low. The process is not therefore
considered to be a "repowering" technology such as AFBC or IGCC. Table 11-1 (below)
outlines the strengths and weaknesses of furnace sorbent injection, relative to flue gas
desulfurization technologies (against which it is often compared). Although many power
plants in Europe use furnace sorbent injection, only a few boilers in the United States have
used the process, and then only at a demonstration scale (B&V, 1991).
208
-------
Table 11-1. Furnace Sorbent Injection strengths and weaknesses
STRENGTHS WEAKNESSES
Low capital cost Low S02 removal efficiency
Low waste handling costs Increased dust loading
Limited domestic experience
Important Factors: The increase in dust loading associated with the furnace sorbent
injection process may require a replacement or upgrade of the unit's
electrostatic precipitator, resulting in increased capital costs. For
retrofit cost assumptions, see Table 11-3 and discussion (page 210).
Table 11-2. Furnace Sorbent Injection Cost Ranges'
Capital Costs ($/kW): 50 - 85
Fixed O&M Costs ($Mfyr): 2.9 - 7.5
Variable O&M Costs ($/MWh): 1.65 - 4.15
S02 Removal Efficiency (%): 50 - 60
11.1.3 Flue Gas Desulfurizatfon Technologies
The following section describes most of the FGD technologies utilities might consider
during compliance planning. The section discusses each technology, describing the general
process, listing strengths and weaknesses, and supplying ranges for costs the user may wish
to use in developing compliance options for modelling in STARRSS.
1 Cost estimates based on values from Radcliffe, "FGD Economics", EPR1 Journal. December, 1990.
209
-------
As noted previously, the cost information is presented in broad ranges that attempt to
capture most of the potential variability in FGD costs for typical medium-sized utility
boilers. These cost estimates are based on an iterative risk analysis using baseline data from
several studies of FGD technologies conducted by the Electric Power Research Institute
(EPRI). All monetary values given represent 1992 dollars. Table 11-3 presents some
typical values for parameters used in these type of analyses.
Table 11-3. Parameters Used to Develop FGD Cost Estimates
PARAMETER VALUE (RANGE)
Plant Size (MW) 300
Plant Retrofit Factor 1.0
Plant Capacity Factor (%) 60-70
Plant Heat Rate (Btu/kWh) 9,500 - 10,500
Coal Higher Heating Value (Btu/lb) 10,000 - 11,500
Coal Sulfur Content by Weight (%) 2.0 - 3.2
Other values for these parameters will considerably alter the costs presented herein. Note
that a retrofit factor of 1.0 was used to develop these cost estimates, reflecting essentially the
cost of a new unit with a new power plant. This convention allows these cost estimates to
be easily integrated with existing plant retrofit factors to provide a reasonable plant-specific
range of cost estimates. Most available cost estimating studies present costs for a "typical"
power plant with a "moderate" retrofit factor ranging from 1.3 to 1.6.
Conventional Limestone
In the conventional limestone scrubbing process, a limestone slurry circulates through a
spray tower to absorb S02 and form a calcium sulfite/sulfate sludge. This process has fairly
widespread commercial application in the United States. In addition, the process uses a
cheap and abundant reagent, pulverized limestone (EPRI, 1984).
210
-------
Table 11-4. Conventional Limestone strengths and weaknesses
STRENGTHS WEAKNESSES
Use of abundant reagent High power consumption
Extensive experience with process High volume of waste
Used on a wide variety of coals
Important Factors: Utilities have more experience with the conventional limestone process
than with any other FGD system; therefore, subsequent discussions of
the strengths and weaknesses of various FGD systems will use the
conventional limestone FGD process as the basis for comparison.
Table 11-5. Conventional Limestone Cost Ranges2
Capital Costs ($/kW): 135 - 220
Fixed O&M Costs ($M/yr): 1.0 - 6.4
Variable O&M Costs ($/MWh): 0.55 - 3.60
S02 Removal Efficiency (%): 90 - 92
Limestone Forced Oxidation Without Gypsum Recovery
The limestone/forced oxidation (LSFO) scrubber is a refinement of the conventional wet
limestone scrubber. The LSFO process oxidizes the calcium sulfite/sulfate by-product to
precipitate landfill gypsum from the reagent slurry that is discarded in landfill. The process
has also demonstrated somewhat higher S02 removal rates than conventional limestone FGD
systems (EPRI, 1984).
2 Cost estimates based on values from Radcliffe, "FGD Economics", EPRI Journal. December, 1990.
211
-------
Table 11-6. Limestone Forced Oxidation strengths and weaknesses
STRENGTHS WEAKNESSES
Lower waste disposal costs High power requirements
Used on a wide variety of coals High volume of waste
Uses an abundant, low-cost reagent
Important Factors: Because of LSFO's similarity to conventional FGD processes, utilities
consider the risks associated with LSFO to be low. In addition, lower
overall costs and higher S02 removal efficiency have made LSFO the
most popular FGD technology to date for Phase I retrofits.
Table 11-7. LSFO Cost Ranges3
Capital Costs ($/kW):
125 - 205
Fixed O&M Costs ($M/yr):
1.4 - 7.1
Variable O&M Costs ($/MWh):
0.75 - 3.95
S02 Removal Efficiency (%):
90-95
Limestone Forced Oxidation With Gypsum Product Recovery
Adding a "pre-scrubber" and auxiliary waste handling equipment to the LSFO scrubber
described above produces commercial grade gypsum instead of gypsum waste. The pre-
scrubber removes chlorine and other impurities that would otherwise end up in the gypsum
by-product and degrade it (UE&C, 1991).
3 Cost estimates based on values from Radcliffe, "FGD Economics", EPRI Journal. December, 1990.
212
-------
Table 11-8. Limestone Forced Oxidation/by-product strengths and weaknesses
STRENGTHS
WEAKNESSES
Use of abundant reagent
High power requirements
Reduced waste disposal costs
Higher capital costs
Produces marketable by-product
Need high level of control of impurities
Important factors: The economic viability of the gypsum production process depends on a
readily accessible market for wallboard gypsum. The process may
require ESP upgrades for improved dust control.
Table 11-9. LSFO/by-product Cost Ranges4
Capital Costs ($/kW):
130 - 215
Fixed O&M Costs ($M/yr):
1.0 - 6.9
Variable O&M Costs ($/MWh):
0.60 - 3.80
S02 Removal Efficiency (%):
90 - 95
Saaitoerg-Hoelter (SHU)
The SHU process uses a wet limestone and formic acid slurry reagent to achieve 90%
removal of S02 from flue gases. The formic acid increases the degree of limestone
utilization, and reduces lime and gypsum scaling. The waste product consists primarily of
dewatered landfill gypsum. Developed in Germany, the process has not yet seen utility-
scale application in the United States. Five units in Europe apply the SHU process,
although none of the units burn high-sulfur coals of the kind typically used in the United
States (B&V, 1991).
"Cost estimates based on values from Radcliffe, "FGD Economics," EPRI Journal. December, 1990.
213
-------
Table 11-10. Saaifoeig-Hoelter strengths and weaknesses
STRENGTHS WEAKNESSES
High reagent utilization Higher cost of formic acid
Use of abundant reagent (limestone) Little domestic experience
Lower waste disposal costs Low pH causes corrosion problems
Important factors: Utilities have not applied the SHU process to high sulfur coals, so
actual removal efficiency may be uncertain. The availability of formic
acid in large quantities and at an economically feasible price may also
be uncertain.
Table 11-11. Saarberg-Hoelter Cost Ranges
Capital Costs ($/kW):
Not Available
Fixed O&M Costs ($M/yr):
Not Available
Variable O&M Costs ($/MWh):
Not Available
S02 Removal Efficiency (%):
90 - 92
Chiyoda-121
The Chiyoda scrubber uses a jet bubbling reactor to remove S02 and create commercial
grade gypsum. As with the Limestone/gypsum product process, the Chiyoda process
requires pre-scrubbing equipment to remove chlorine and residual fly ash that would
otherwise degrade the gypsum product. The Chiyoda process has not been used
commercially in the United States, although it has been used successfully in Japan. The
Chiyoda process uses limestone more efficiently than conventional processes, and reduces
capital and maintenance costs (EPRI, 1984).
214
-------
Table 11-12. Chiyoda-121 strengths and weaknesses
STRENGTHS WEAKNESSES
High reagent utilization Little domestic experience
Use of abundant reagent
Produces saleable by-product
Important Factors: The Southern Company has successfully demonstrated the Chiyoda
process, but it has not been implemented at a commercial scale facility.
Table 11-13. Chiyoda-121 Cost Ranges5
Capital Costs ($/kW):
125 - 205
Fixed O&M Costs ($M/yr):
1.2 - 6.6
Variable O&M Costs ($/MWh):
0.65 - 3.70
S02 Removal Efficiency (%):
90-92
Pure Air
The Advanced Flue Gas Desulfurization (AFGD) system proposed by Pure Air (a joint
venture of Air Products and Chemicals, Inc., and Mitsubishi Heavy Industries America, Inc.)
essentially uses a forced oxidation wet limestone FGD system and incorporates advanced
design features to improve reliability and reduce capital costs. The Pure Air process uses
pre-crushed limestone as the reagent, and a single absorber module to remove 90-95% of
S02 from the flue gases. The high degree of reliability of the single absorber eliminates the
need for a spare absorber, reducing capital costs. As part of DOE's Clean Coal Technology
Program, Pure Air will demonstrate the AFGD process at Northern Indiana Public Service
5 Cost estimates based on values from Radcliffe, "FGD Economics", EPRI Journal. December, 1990.
215
-------
Company's Bailiy Station. A single absorber will clean the flue gases for a combined total
of 528 MW, starting in 1995 (U.S. DOE, 1989).
Table 11-14. Pure Air Advanced FGD strengths and weaknesses
STRENGTHS WEAKNESSES
High reliability Limited domestic experience
Lower O&M Costs Higher reagent costs
Produces saleable by-product
Important Factors: Currently, most FGD manufacturers promise to cut out the spare
absorber from their systems, minimizing the capital cost advantage
claimed by Pure Air. Higher reagent costs result from the need to pre-
crush limestone; these costs may be negligible in some cases.
Table 11-15. Pure Air Advanced FGD Cost Ranges6
Capital Costs ($/kW): 110 - 175
Fixed O&M Costs ($M/yr): 1.6 - 6.6
Variable O&M Costs ($/MWh): 0.90 - 3.65
S02 Removal Efficiency (%): 90 - 95
Lime
Wet lime flue gas desulfurization systems use essentially the same process as limestone FGD
systems. Using lime instead of limestone as the reagent provides several advantages,
£
Cost estimates based on values from Radcliffe, "FGD Economics," EPRI Journal. December, 1990.
216
-------
including: increased reagent utilization, higher S02 removal efficiency (92%-96%), and
better turn-down capabilities. However, the significantly higher unit cost of lime largely
offsets these advantages. Lime also has a greater tendency to scale. Utilities have extensive
experience with lime FGD systems, making it a proven process (B&V, 1991).
Table 11-16. Conventional Lime strengths and weaknesses
STRENGTHS
WEAKNESSES
Extensive industry experience
High power consumption
High removal efficiency
Expensive reagent
Used with wide range of coals
Increased scaling
Important Factors: Lime FGD systems have slightly better removal efficiency than their
limestone counterparts, although this advantage is offset by
considerably higher costs; lime can cost 3-6 times as much as
limestone.
Table 11-17. Conventional Lime Cost Ranges
Capital Costs ($/kW):
135 - 220
Fixed O&M Costs ($M/yr):
2.9 - 9.0
Variable O&M Costs ($/MWh):
1.05 - 4.25
S02 Removal Efficiency (%):
92 - 96
Magnesium Enhanced Lime
The Magnesium promoted lime scrubber uses a slurry of approximately 95% pure lime
(CaO) and 5% magnesium oxide (MgO) as the reagent. Dravo, Inc. markets this reagent as
a product called Thiosorbic Lime. The magnesium oxide reacts with S02 to form
217
-------
magnesium sulfite, which reacts further with S02 to form magnesium bisulfite. In addition,
the lime in the slurry will also react with S02 to form calcium sulfite. The high degree of
reactivity of this solution leads to a high S02 removal efficiency (98%). The process
requires more water extraction equipment for the waste products than conventional limestone
processes, and the reagent costs are higher than limestone (UE&C, 1991).
Table 11-18. Magnesium Enhanced Lime strengths and weaknesses
STRENGTHS
WEAKNESSES
High reagent utilization
High removal efficiency
Reduced corrosion due to higher pH
Expensive reagent
High waste disposal costs
Important Factors: The very high removal efficiency of this process substantially reduces
control costs of this option on a $/ton removed basis, offsetting the
expense of the reagent.
Table 11-19. Magnesium Enhanced Lime Cost Ranges7
Capital Costs ($/kW): 100 - 170
Fixed O&M Costs ($M/yr): 2.9 - 9.0
Variable O&M Costs ($/MWh): 1.65 - 5.20
S02 Removal Efficiency (%): 96 - 98
7 Cost estimates based on values from Radcliffe, "FGD Economics", EPRI Journal. December, 1990.
218
-------
Lime Spray Diying
The lime spray drying process uses a spray dryer as the contacting device for the flue gas
and hydrated lime reagent (CaO). Reagent is pumped to the spray dryer and sprayed as a
fine mist into the absorber where it mixes with the flue gas. Water is evaporated by the
heat of the flue gas while S02 is absorbed. A dry calcium sulfite/sulfate powder forms as
the flue gas cools. A baghouse or electrostatic precipitator collects the resulting dry solid
and fly ash (EPR1, 1990).
Table 11-20. Lime Spray Diying strengths and weaknesses
STRENGTHS WEAKNESSES
Low capital cost Expensive reagent
Low power requirements Low S02 removal efficiency
High volume of waste
Important Factors: Cost values given here assume a fabric filter is installed with the lime
spray drying system. S02 removal efficiency tends to drop to the low
range for coals with greater than 2% sulfur content by weight.
Table 11-21. Lime Spray Diying Cost Ranges8
Capital Costs ($/kW): 95-160
Fixed O&M Costs ($M/yr): 1.2 - 5.9
Variable O&M Costs ($/MWh): 0.70 - 3.30
S02 Removal Efficiency (%): 75 - 85
8 Cost estimates based on values from Radcliffe, "FGD Economics", EPR1 Journal. December, 1990.
219
-------
Lurgi Circulating Fluidized Bed
This process routes post-combustion flue gas through a circulating fluidized bed of hydrated
lime which reacts with S02 to achieve a high removal efficiency (95-97%). The reagents
recycle continually through the fluidized bed, allowing for a high rate of reagent use. Lurgi
systems have operated in Europe since 1980, and one 100 MW lignite unit in the United
States has operated since 1987. Only one supplier, who holds the patent, offers the Lurgi
process. The process costs more than other dry FGD processes but its low reagent and
capital costs and proven process results in lower costs over the life cycle of the installation
(B&V, 1991).
Table 11-22. Lurgi Circulating Fluidized Bed strengths and weaknesses
STRENGTHS
WEAKNESSES
Low capital cost
High reagent cost
Low waste handling costs
Limited domestic experience
High reagent utilization
Only one vendor for process
Important Factors: The high rate of reagent utilization largely offsets the reagent's cost,
making Lurgi CFB an extremely cost-effective option on a levelized
basis. Increased dust loading may require an electrostatic precipitator
upgrade or replacement.
220
-------
Table 11-23. Lurgi CFB Cost Ranges'
Capital Costs ($/kW): 85 - 140
Fixed O&M Costs ($M/yr): 2.4 - 7.4
Variable O&M Costs ($/MWh): 1.40 - 4.15
S02 Removal Efficiency (%): 95 - 97
Soda Ash
In the soda ash scrubbing process, a sodium carbonate solution is dispersed in the flue gas
stream via spray nozzles. The soda ash reacts with S02 in the flue gas to form sodium
sulfite bisulfite and sulfate compounds. As with the lime or limestone scrubbing process
soda ash generally costs more than lime or limestone the process has higher reagent costs.
Disposal of the soluble waste product is also potentially more costly and/or environmentally
less desirable. (B&V, 1991).
Table 11-24. Soda Ash strengths and weaknesses
STRENGTHS
WEAKNESSES
Low energy requirements
High reagent cost
Low capital costs
High waste disposal cost
Important Factors: The economic viability of the soda ash process depends on the
availability of low cost supplies of soda ash and a scarcity of calcium
reagents.
9 Cost estimates based on values from Radcliffe, "FGD Economics", EPRI Journal. December, 1990.
221
-------
Table 11-25. Soda Ash Cost Ranges10
Capital Costs ($/kW):
Not Available
Fixed O&M Costs ($M/yr):
Not Available
Variable O&M Costs ($/MWh):
Not Available
S02 Removal Efficiency (%):
90
Dual-Alkali
The dual alkali process uses two S02 removal reagents: lime or limestone and soda ash. A
soda ash solution is used to absorb the S02 from the flue gas thereby taking advantage off
its superior S02 removal chemical kinetic properties. Lower cost lime or limestone reagents
are used to regenerate the soda ash solution from the sodium sulphite, bisulfites, and sulfates
resulting from removal of the S02 from the flue gas. In a recirculating tank, the calcium
reagent regenerates sodium sulfite and a relatively minor amount of soda ash make-up is
required to balance the soda ash lost in the calcium sulfate/sulfite waste generated. Dual-
alkali systems currently serve six large utility boilers in the United States (B&V, 1991).
Table 11-26. Dual-Alkali strengths and weaknesses
STRENGTHS WEAKNESSES
High reagent utilization High reagent cost
Utility experience with process High waste disposal cost
Important Factors: The S02 removal efficiency of the dual alkali process tends toward the
high range for high sulfur coals (greater than 3% sulfur content by
weight).
10 Cost estimates based on values from Radcliffe, "FGD Economics", EPRI Journal. December, 1990.
222
-------
Table 11-27. Dual-Alkali Cost Ranges'1
Capital Costs ($/kW): 115 - 190
Fixed O&M Costs ($M/yr): 1.7-7.5
Variable O&M Costs ($/MWh): 1.00 - 4.10
S02 Removal Efficiency (%): 85 - 95
Wellman-Lord
The Wellman-Lord process uses an aqueous sodium sulfite solution as the primary contact
reagent for incoming flue gas. The sodium sulfite is converted to sodium bisulfite which
can be easily regenerated by simply heating the solution. The regeneration stage reproduces
the sodium sulfite solution and a concentrated stream of S02 gas that is sent to a sulfur
recovery stage. The process removes 90% or more of flue gas S02, and can produce
marketable sulfuric acid, or by reaction with natural gas elemental sulfur. Eight utility coal-
fired boilers with a combined capacity of 2100 MW use the Wellman-Lord process (B&V,
1991).
Table 11-28. Wellman-Loid strengths and weaknesses
STRENGTHS WEAKNESSES
High reagent utilization High capital cost
Produces marketable sulfur High waste disposal cost
High energy requirement
Important Factors: The utility industry has not given much consideration to the Wellman-
Lord process because of its high capital costs and process complexity.
11 Cost estimates based on values from Radcliffe, "FGD Economics", EPRI Journal. December, 1990.
223
-------
Table 11-29. WcHman-Lord Cost Ranges
Capital Costs ($/kW): Not Available
Fixed O&M Costs ($M/yr): Not Available
Variable O&M Costs ($/MWh): Not Available
S02 Removal Efficiency (%): 90 - 95
Dowa
The Dowa process uses a dual alkali system similar to that outlined previously, except the
primary reagent is an aqueous slurry of aluminum sulfate and aluminum oxide (A/203)
instead of soda ash. The resulting aluminum sulfite/sulfate mixture is then oxidized to
aluminum sulfate and regenerated. As with the dual alkali process, lime or limestone
regenerates the primary reagent and precipitates gypsum waste. No U.S. utility has used the
Dowa process, although TVA successfully demonstrated the process at its 10 MW Shawnee
Test Facility in 1982 (B&V, 1991).
Table 11-30. Dowa strengths and weaknesses
STRENGTHS
High reagent utilization
Reduced equipment erosion
WEAKNESSES
High reagent cost
High waste disposal cost
Limited domestic experience
Important Factors: Although Dowa has been used in Japan, the primary application has
been to industrial boilers, rather than utility boilers.
224
-------
Table 11-31. Dowa Cost Ranges
Capital Costs ($/kW):
Not Available
Fixed O&M Costs ($M/yr):
Not Available
Variable O&M Costs ($/MWh):
Not Available
S02 Removal Efficiency (%):
90
Magnesium Oxide
This process uses a magnesium hydroxide slurry to absorb flue gas S02. The magnesium
sulfite resulting from the reaction is then calcined in an off-site process to regenerate the
absorbent and to extract concentrated S02 for the production of marketable sulfuric acid or
elemental sulfur. This recovery allows for a very high rate of reagent utilization and
produces a marketable by-product. Three magnesium oxide systems currently operate on
U.S. utility boilers with an S02 removal efficiency of 90% or greater (B&V, 1991).
Table 11-32. Magnesium Oxide strengths and weaknesses
STRENGTHS WEAKNESSES
High reagent utilization High reagent cost
Produces marketable sulfuric acid High energy requirements
Important Factors: The degree of control needed to operate the Magnesium Oxide process
efficiendy (including the smooth management of the off-site processing
and delivery of regenerated reagent) is a disadvantage compared to
options in which the process is controlled entirely on-site.
225
-------
Tabic 11-33. Magnesium Oxide Cost Ranges
Capital Costs ($/kW): Not Available
Fixed O&M Costs ($M/yr): Not Available
Variable O&M Costs ($/MWh): Not Available
S02 Removal Efficiency (%): 90 - 98
11.1.4 Reagent Additives
Dibasic Acid (DBA)
The addition of dibasic acid to the recirculation tank enhances the performance of limestone
forced oxidation FGD systems. Dibasic acid prevents a substantial drop in pH during the
S02 absorption process, which increases the absorption capability (removal efficiency) of
the limestone reagent. However, dibasic acid contaminates the resulting gypsum waste,
making the waste unsuitable for use as a commercial grade gypsum by product. (UE&C,
1991).
Table 11-34. Limestone/Dibasic Acid strengths and weaknesses
STRENGTHS WEAKNESSES
Higher S02 removal Higher reagent cost for DBA
High waste disposal cost
Limited Use
Important Factors: To date, Dibasic Acid has been used solely to improve removal
efficiencies in systems that had fallen below removal efficiency
expectations. DBA has not seen use in a new or retrofit FGD system.
226
-------
Table 11-35. Limestone/DBA Cost Ranges12
Capital Costs ($/kW):
130 - 215
Fixed O&M Costs ($M/yr):
1.4 - 7.1
Variable O&M Costs ($/MWh):
0.80 - 3.95
S02 Removal Efficiency (%):
92-95
Thiosulfate
Thiosulfate has the effect of minimizing the oxidation of sulfite to sulfate thereby preventing
gypsum scaling in the absorber and promotes a less contaminated calcium sulfite crystal
precipitate that is more easily dewatered increasing the utilization of the limestone reagent.
In the spray tower, emulsified elemental sulfur reacts with limestone to form calcium sulfite
and thiosulfate; the thiosulfate ion further reacts with CaC03 (limestone), increasing the
amount of Ca available to react with S02 in the flue gas. The waste product consists
primarily of a calcium sulfite sludge. The thiosulfate process increases utilization level of
the reagent, reducing costs to purchase reagent and the volume of waste produced. Many
new systems can use thiosulfate, and vendors have modified several existing limestone
systems to use thiosulfate. The performance of thiosulfate tends to be site-dependent,
however (UE&C, 1991).
11.2 FUEL SWITCHING COMPLIANCE OPTIONS
Natural Gas Co-Firing
In natural gas co-firing, coal and natural gas burn simultaneously in a single steam
generator. Because natural gas emits virtually no S02 when burned, the addition of natural
gas reduces boiler S02 emissions. The amount of S02 reduction depends on the proportion
of natural gas in the boiler fuel, although boilers designed to burn coal can handle more than
a 10% blend of natural gas in the fuel mix a greater proportion of natural gas is rarely used
due to cost and technical factors. The use of natural gas reduces maintenance and unit
unavailability costs and can improve the rated capacity of previously derated units. Natural
gas co-firing also reduces boiler NOx emissions. Capital costs of gas co-firing vary greatly,
12 Cost estimates based on values from Radcliffe, "FGD Economics", EPRI Journal. December, 1990.
227
-------
and depend on the natural gas supply facilities the plant has already installed; for plants with
significant prior investment, capital costs can be as low as $5/kW, while for plants with no
prior investment, capital costs can exceed $50/kW. The price of natural gas supply
determines the bulk of the operation and maintenance costs for co-firing (B&V, 1991).
Coal Switching/Blending
The cost of coal switching or blending varies greatly from unit to unit. In their original
design, utilities build boilers to maximize the performance of a particular coal. Key coal
characteristics utilities design the boilers for include: ash content, ash softening temperature,
moisture content, grindability, and sulfur content. Utilitiy planners consider sulfur content
the least important of these factors; a coal that closely matches the ash content, moisture
content, ash softening temperature, and grindability of the current coal will usually be
suitable for fuel switching. For example, because low-sulfur Appalachian coals match the
characteristics of many mid-western high- sulfur coals, Appalachian coals have been in
relatively high demand for fuel switching.
Most fuel switches will require some capital modifications. Low sulfur coals produce lower
concentrations of S03 that will tend to adsorb on the particulate and affect the restivity of
the flyash, decreasing electrostatic precipitators. Fuel switches therefore usually require an
ESP upgrade or replacement. In addition, the lower sulfur coals can cause slagging,
plugging, and fouling in a boiler designed to use other coals with different ash softening
temperature characteristics. Several test burns have suggested that these problems are not as
formidable as first believed.
Not surprisingly, the price of candidate coals for fuel switching play a larger role in
determining the viability of a fuel switch option than how well it matches the coal the boiler
was designed for. High demand and increasing prices for eastern low-sulfur coals, along
with easing concerns about using western coals, has led many utilities to consider western
coals. The cost differential between western and eastern low-sulfur coals is great enough
that in many cases it is more cost-effective to modify the boiler to burn western low-sulfur
coal than to pay a stiff premium for eastern low-sulfur coals.
The delivered price of coal also has an important site-specific component: the diversity of
transportation options available to the utility plant. If a plant coal yard has a single rail spur
as its sole source of delivery, then the railroad company servicing the rail may command a
higher price for delivery than if a plant has multiple rail spurs or is close to a barge
unloading point. In the east and northeast, where rails lines are extensive, transportation
costs will not play a large role in fuel costs. A plant's decision to buy western coal,
however, will likely depend more on transportation costs than on the mine mouth cost of the
coal itself.
228
-------
11.3 CONSERVATION COMPLIANCE OPTIONS
While it is unlikely that utilities will rely heavily on conservation to meet their reduction
obligations, most utilities will factor gains from demand-side management into their
compliance option portfolio. Conservation carries three distinct benefits from a compliance
planning perspective:
1) Aggressive demand-side management efforts, particularly those that curtail
base load energy generation, will reduce S02 emissions, proportionately
reducing the need for a utility system to expend emission allowances to cover
those emissions;
2) Even DSM action that does not curtail generation can reduce the rate of load
growth which, in addition to avoiding the cost of new generation, reduces the
need to cover new generation out of the utility system's pool of emission
allowances; and,
3) If conservation programs meet statutory requirements, those programs may
qualify the utility to receive bonus allowances from EPA's Conservation and
Renewable Energy Reserve.
Section 404(g) of the Clean Air Act Amendments creates the Conservation and Renewable
Energy Reserve by deducting 30,000 allowances/year from national totals from the years
2000 to 2009, for a total reserve of 300,000 allowances. Allowances allocated from the
reserve by EPA may be used any time after they are allocated.
The two criteria a utility conservation program must meet to qualify for allowances from the
reserve are:
*¦ The utility must have in place a commission-approved least cost plan (or
integrated resource plan) that explicitly considers demand-side as well as
supply-side resources; and,
~ The utility's rate structure must guarantee net income neutrality for
investments in demand-side management measures. Examples of net income
neutrality mechanisms are measures that increase the return on rate base for
utilities engaging in DSM, or an electric revenue adjustment mechanism such
as that used in California. The Department of Energy certifies that the
applicant's regulatory authority is, in fact, employing a net income neutrality
mechanism.
229
-------
Once the applicant meets these criteria, they receive allowances at the rate of 4 lbs
S02/MWh of energy saved. Note that qualified renewable energy sources may also receive
allowances from the Reserve at the rate of 4 lbs S02/MWh generated.
STARRSS uses a simple process to compare marginal control costs and allowance prices
specified by the user to determine if a new conservation program is justified as part of an
effort to meet the overall reduction target. The STARRSS program will consider both the
S02 reduction impact and the bonus allowance impact of any conservation program the user
specifies.
11.4 OTHER COMPLIANCE ACTIVITY
This section briefly discusses a variety of non-standard compliance options that utilities can
undertake to reduce S02 emissions on their system. In some cases, STARRSS Version 1 is
limited in its ability to model these options as discrete and comparable to other compliance
options because full system dispatch modelling is not yet available. For these cases, this
section will also include suggestions on how to model these compliance options using
STARRSS.
Reduced Utilization
Reduced utilization is a specific Phase I compliance option provided by the Clean Air Act
Amendments. A utility wishing to reduce the generation of a Phase I-affected unit (thereby
reducing that unit's S02 emissions) must provide EPA with two types of information:
• the amount of reduction in use at the unit, expressed as the difference between
the projected annual heat input and the Baseline Heat Input ("Baseline"), in
Btus; and
• the source of compensating generation (or factors accounting for reduction in
utilization, if applicable).
If the source of compensating generation emits no S02 (such as nuclear or hydroelectric
generation), then the utility need only demonstrate that the increase in generation at these
units will fully compensate the reduction in utilization at the Phase I-affected unit (using the
affected unit's current heat rate as the benchmark value to convert kWhs to Btus).
Alternatively, if the utility expects conservation programs or other system-wide factors to
result in reduced utilization, the utility may specify these factors, subject to EPA's year-by-
year review.
However, in the case where the compensating unit is a fossil-fired Phase II-affected unit, the
compensating unit becomes a Phase I-affected unit and receives Phase I allowances equal to
230
-------
its Baseline times the lesser of its actual or allowable S02 emissions rate (if the
compensating unit has a zero Baseline, it receives no allowances).
A utility pursuing reduced utilization must therefore consider carefully which compensating
unit it wishes to use; some units may receive a more advantageous allowance allocation, or
be emitting at a low enough rate to reap substantial compliance benefits from a reduced-
utilization/compensating unit option.
Suggested Approach forSTARRSS Modelling of Reduced Utilization
Modelling a reduced utilization compliance option in STARRSS is relatively straightforward
but may require the user to perform some side calculations to determine some STARRSS
inputs. Structuring a reduced utilization compliance option actually requires only two inputs
in the Define Compliance Options screen. First, the user enters the projected New Capacity
Factor of the unit reducing utilization. The resulting costs and emissions reductions are
tracked in STARRSS using the inputs for the fuel the unit will burn under the new
compliance option and the marginal energy costs to replace the lost generation.
The second input that the user must define is the System Marginal SQ2 Emissions rate
associated with reducing utilization. This input should reflect the net emissions rate (in lbs
S02/MWh) of the compensating unit(s). Accordingly, if the compensating unit is non-fossil
based, or if the reduction in utilization is attributed to a system-wide load reduction, this
input should be zero. If the compensating unit is a Phase II-affected unit, the user must
calculate the marginal S02 emissions rate according to Equation 11-1 below:
System Marginal S02 Emissions (Ibs/MWh) = [(Ec-Ac)/Gr] * 2000 Ihs/ton (11-1)
where:
Ec
Ac
Gr
231
compensating unit c's projected emissions (in tons of S02), calculated
as the product of the unit's projected heat input times the unit's
projected S02 emissions rate (in lbs/106 Btu);
compensating unit c's Phase I allowances, calculated as the product of
the compensating unit's Baseline times the lesser of the units 1985 S02
rate or the unit's S02 limit (in lbs./106 Btu) under SIP or other
regulations; and,
the difference in generation resulting from reduced utilization at
reducing unit r, calculated as the difference between the MWh's
generated at the reducing unit's Baseline, and the projected MWhs of
generation.
-------
The 2000 multiplier converts tons of S02 into lbs. Note that if further compliance activities
are performed at either the reducing unit or the compensating unit (such as a fuel switch
along with a reduction in utilization), costs to perform these activities must be reflected in
the same compliance option as the inputs for reduced utilization. Because STARRSS can
only consider one option for each unit in compliance strategy development, combinations of
compliance options must be modelled as a single composite compliance option.
Phase I Substitution Units
Utilities may find that certain Phase II-affected units on their system can more easily comply
with Phase I reduction obligations than their Phase I units. In this event, the Act contains
provisions allowing utilities to substitute Phase II-affected units for their Phase I-affected
units, effectively transferring all or a portion of the Phase I-affected unit(s) reduction
obligation to the Phase II unit(s). In a Phase I Substitution Plan, a utility must submit to
EPA the following information:
1) the calculated reduction obligation of the proposed Phase I unit;
2) the calculated reduction obligation of the proposed Phase II substitution unit
(under SIP or other regulations);
3) the proposed reduction to be achieved at the Phase I unit due to compliance
activity;
4) the proposed reduction to be achieved at the Phase II unit due to compliance
activity; and,
5) satisfactory demonstration that the sum of the proposed reductions (items 3
and 4 above) equals or exceeds the sum of required S02 emissions reductions
(items 1 and 2 above).
Note that multiple Phase I units and substitution units may be included in a single Phase I
Substitution Plan. If EPA determines that the proposed substitution plan will not result in a
net emissions increase, it will approve the substitution plan and allocate allowances to units
in the plan as follows:
• the Phase I unit(s) in the plan will receive allowances equal to their basic
allowances plus the difference between the unit's reduction obligation and the
proposed amount of reductions due to compliance activity;
• the substitution units in the plan will receive allowances equal to their current
emissions (or allowable emissions under SIP, if less) less the difference
232
-------
between the Phase I unit's reduction obligation and the Phase I unit's proposed
amount of reductions due to compliance activity.
Suggested Approach for STARRSS Modelling of Substitution Plans
STARRSS is not well equipped to compare a proposed substitution plan discretely to other
compliance options, because substitution plans involve compliance options at different
facilities that must take place concurrently as well as changes to basic data (i.e. allowance
allocations) that are not typically reflected in the Edit/Define Compliance Options screens.
The best way to evaluate a substitution plan is to create a separate .SDB file for the utility
system under consideration, incorporating the changes to allowance allocations and proposed
compliance options. Allowance allocations may be changed in the View/Edit Affected Units
screen, and units governed by an approved substitution plan can have their options "fixed"
(i.e. evaluated regardless of other compliance activity) in the Define Active Compliance
Options step of the Develop STARRSS Strategies screen. Comparing the results of runs on
the original database to the results of runs on the database modified to reflect a substitution
plan should provide the user with an indication of how the substitution plan is affecting the
utility's efforts to achieve least-cost compliance with its S02 reduction obligations.
Efficiency Improvements
Efficiency improvements considered by utilities typically fall into two categories:
improvement of the boiler heat rate, and improvement of pollution control device efficiency.
By replacing old steam seals in the turbine or worn components elsewhere in the system,
utility engineers can improve the unit's heat rate, thereby reducing the amount of S02
emitted for an equal level of generation. Although this process constitutes part of a
generating unit's standard maintenance, compliance requirements may cause utilities to
evaluate efficiency improvements as a marginal S02 compliance activity, particularly at
older boilers. This can be modelled in STARRSS by designating a compliance option that
reduces the Heat Rate Multiplier (on the Edit/Define Compliance Options screen).
A second possibility considered by many utilities with FGD-equipped units on their system
is the improvement of the FGD system's S02 removal efficiency. This can often be
achieved through implementation of a tighter process control, the addition of larger amounts
of reagent, or the use of reagent additives (as discussed in Section 11.1.4). FGD efficiency
improvements can remove significant amounts of S02 at relatively low cost, making such
improvements a worthwhile marginal compliance activity. Such possibilities can be
modelled in STARRSS by designating new compliance options with S02 Removal
Efficiencies (on the Edit/Define Compliance Options screen) for units that already have
existing scrubbers (as designated on the Affected Units Operating Factors screen).
233
-------
Clean Energy Additions
The addition of hydroelectric, gas-fired, or renewable energy units to a utility's system can
reduce the need for generation at affected units and subsequently reduce system-wide S02
emissions. Furthermore, renewable energy resources may qualify the utility for bonus
allowances in a manner similar to that for conservation programs (Section 11.3) — at a rate
of 4 lbs S02/MWh of energy generated by the renewable resource. If a utility anticipates
a reduction in generation by its Phase I-affected units below 1985 levels, it is encouraged to
file a Reduced Utilization plan with EPA.
Unit Retirement
The Clean Air Act Amendments have also led to greater consideration of unit retirement for
older S02-emitting units on many utility systems. Obviously, the retirement of an affected
unit frees up that unit's allowances for use on the rest of the utility's system and covers the
emissions of new fossil units. Note, however, that if a Phase I unit is targeted for
retirement, the utility may need to account for the replacement of that unit's generation and
file a Reduced Utilization plan with EPA. If the generation of the utility's Phase I units as a
whole (subtracting the retired unit) still exceeds their 1985 generation (including the retired
unit), no reduced utilization test is necessary.
A retirement option (as opposed to a base case planned retirement) can be modelled in
STARRSS by specifying a compliance option with a Start Date that immediately follows the
proposed retirement year, a New Capacity Factor of 0.1%, and an appropriate value for the
System Marginal S02 Emissions (all on the Edit/Define Compliance Options screen).
234
-------
APPENDIX A
STARRSS DATA REQUIREMENTS
Affected Generating Unit Information:
1) Utility Ownership Percentage(s)
2) Summer Net Capacity (MW)
3) "Expected Long-Range Capacity Factor(s)
4) Average Heat Rate (BTU/kWh)
5) "Current Variable O&M Cost {Base Year $/MWH)
6) Expected Retirement Year (if before End Year)
7) Fuel/Fuel Blend Burned By The Unit1
Fuel Information:
8) Sulfur Content (Lbs of S02/mmBTU)
9) "Delivered Price Forecast (1995-End Year, cents/mmBTU)
Utility Information:
10) "System Marginal Energy Cost Forecast (1995-End Year, $/MWH)
11) "System Marginal Capacity Cost Forecast (1995-End Year, $/kW)
12) Cost of Capital Forecast {Base Year-End Year)2
13) Effective Tax Rate
14) Escalation Rate Forecasts {Base Y ear-End Year) for:
a) Capital Costs
b) Variable O&M Costs
c) Fixed O&M Costs
"The user can define three forecasts for these data items (High, Medium, Low). The user also
should designate his or her estimate of the likelihood that the forecast will occur by specifying
a probability percentage for each forecast, the percentages for all three forecasts must sum to
100%.
The user must designate a name for each fuel (such as the name of the supplier or the location where
it was mined) and, in the case of units that burn a blend of fuels, the percentage that each fuel represents in
the blend (by mmBTU).
The utility's latest allowed return on ratebase will suffice if a forecast is not available.
A-1
-------
Conservation Information:
15) 'Energy Savings Forecast For Planned Conservation (Base Year-End Year,
MWH)
Allowance Market Information:
16) 'Allowance Market Price Forecast (Base Year-End Year, $/allowance)
Compliance Option Information:
New Conservation Programs
For each program:
17) 'Energy Savings Forecast For New Conservation Program (Base Fear—with an
escalation rate for future years' savings, MWH)
18) 'Expected S02 Emissions Reduction From Conservation Program (Lbs/MWH)
19) 'Expected Annual Program Costs (Base year—with an escalation rate for future
years' costs, $/MWH)
20) "Expected Annual Avoided Costs (Base Year--with an escalation rate for future
years' avoided costs, $/MWH)
Fugi Switching Options
For each fuel switching/blending option at each affected generating unit:
21) New Fuel Blend
22) 'Capital Costs (in Base Year $M)
23) 'Increased Non-Fuel Variable O&M Costs (in Base Year $/MWH)
24) 'Increased Fixed O&M Costs (in Base Year $M/yr)
25) 'Additional Costs [if any] (in Base Year $M/yr)
26) 'Capacity Deration (%)
27) 'New Capacity Factor [if unit will be operated differently]
28) 'Expected S02 Emissions Impact From Decreased/Increased Generation
(Lbs/MWH)
'The user can define three forecasts for these data items (High, Medium, Low). The user also
should designate his or her estimate of the likelihood that the forecast will occur by specifying
a probability percentage for each forecast; the percentages for all three forecasts must sum to
100%.
A-2
-------
Pollution Control Technology Options
For each technology option at each affected generating unit:
29)
30)
31)
32)
33)
34)
35)
36)
Capital Costs (in Base Year $M)
Increased Variable O&M Costs (in Base Y ear $/MWH)
Increased Fixed O&M Costs (in Base Y ear $M/yr)
Additional Costs [if any] (in Base Year $M/yr)
Capacity Deration (%)
New Capacity Factor [if unit will be operated differently]
Expected SOz Emissions Impact From Decreased/Increased Generation
Lbs/MWH)
S02 Removal Efficiency
*The user can define three forecasts for these data items (High, Medium, Low). The user also
should designate his or her estimate of the likelihood that the forecast will occur by specifying
a probability percentage for each forecast; the percentages for all three forecasts must sum to
100%.
A-3
-------
DESCRIPTION OF STARRSS DATA REQUIREMENTS
Unit Information
Data items #1 and #2 (Ownership Percentage and Summer Net Capacity) are fairly self-
explanatory. The third item, Capacity Factor, should represent an estimate of a unit's future
utilization. The best information would be annual projections from the Base Year through the
End Year, presumably taken from a long-range "base case" that may have been filed. Ideally,
the user should obtain or develop three forecasts (High, Medium, and Low scenarios) that
represent all of a utility's units' annual capacity factors for High, Medium, and Low load growth
scenarios (excluding DSM impacts). It should be emphasized that this is the ideal. If the user
is only able to estimate a single long-term capacity factor for each unit, that will suffice.
The fourth item, Average Heat Rate, should represent the generating unit's efficiency based on
its average capacity utilization. Therefore, it does not necessarily have to be the full load rate
if the unit tends to operate at lower capacity levels most of the time.
Item #5, Variable O&M Costs, is self-explanatory. Item #6, Expected Retirement Year, is only
needed if the user expects the unit to be retired before the end of the study.
Fuel Information
The user must define what fuel or fuel blend each unit burns. Defining a fuel requires three
pieces of information: a unique fuel name, the expected uncontrolled S02 emissions rate (in
Lbs/mmBTU), and price forecasts. The user is free to define as many fuels as he or she likes.
A unit in STARRSS may burn a blend of up to three fuels. If such is the case, the user merely
specifies each fuel's percentage of the unit's fuel blend (on an mmBTU basis).
Similar to the generating unit capacity factors, three fuel price forecasts can be specified for
each fuel. The user must at least specify the 1992 delivered prices and an expected growth rate.
If detailed forecasts are available, the user can represent three delivered price forecasts (High,
Medium, and Low) for each fuel for each year of the study.
Utility System Information
Utility-specific system marginal energy and capacity costs are input in much the same fashion
as fuel price forecasts. These energy and capacity costs are used to calculate the cost of
replacement power and therefore should reflect generation costs only (i.e., no transmission or
distribution costs).
A-4
-------
For present value calculations and escalation of costs, the user must provide cost of capital and
cost escalation rates. For each utility, please specify the company's current allowed rate of
return (i.e., cost of capital). If the user has a financial forecast of how this might change, that
forecast may be input; otherwise, the user can assume that the utility's cost of capital will not
change from year to year. In STARRSS, the user can also specify assumptions about nominal
escalation rates for 1) capital costs, 2) variable O&M costs, and 3) fixed O&M costs.
Conservation Information
Since certain qualified conservation measures employed after 1991 may make a utility eligible
for bonus allowances, the user should specify a forecast of each utility's expected level of
conservation savings. This forecast should be in MWHs from 1992 through 1994. If such
information is not readily available, the utility possibly has an estimate of the number of bonus
allowances it expects to receive from the Conservation and Renewable Energy Bonus Allowance
Reserve.
Allowance Market Information
The user can specify three forecasts (High, Medium, and Low) for both buying prices and
selling prices in the emerging allowance market. This allows the user to model a bid-ask
spread; in illiquid markets it is common to see significantly different buying and selling prices.
Compliance Option Information
The remainder of STARRSS inputs pertain to potential compliance options for a utility (such
as increased conservation) and for specific generating units (such as fuel switching, co-firing,
scrubbing, etc.). The critical values for the latter would be the estimates of capital costs,
increased operating costs, operational changes (e.g., capacity derates or changes in utilization)
and S02 removal impacts. For fuel switching, the user must identify a possible fuel type that
could be utilized by a particular unit; any estimates for capital costs (e.g., for retrofitted fuel
handling systems) or increased operating expenses can also be specified.
A-5
-------
APPENDIX B
STARRSS WARNING MESSAGES
The following is a complete compilation of the warning messages that a user could encounter
in using the system. For this appendix, the warning messages appear on the left-hand side of
the page in bold italics; the explanations of the messages are on the right-hand side. The
messages are arranged in alphabetical order, except for those that begin with a name. For
example, the user will find the explanation for the message "BIGCOAL 3: WETFGD1 is active
outside of BIGCOAL 3's lifetime" under toward the end of the appendix.
A fatal memory error occurred. Reduce the size of
the database in use or obtain more memory. See also
the Warnings appendix in the STARRSS documentation.
This message could mean one of two things: (1) there is not
enough memory for the size of the program, the database, and the
temporary storage needed for execution, or (2) the database is
incomplete in some way (e.g., there are no options defined, or no
fuels, or no units). After making sure the second alternative is not
the problem, the user has the option of eliminating memory-
resident software or reducing the size of the database (by
removing unneeded units, options, fuels, linkages, and
conservation/renewable programs). See page 3-14 for more
suggestions for reducing a database's memory requirements.
AUowance sale price exceeds purchase price in (High/Medium/Low) forecast
In Version 1, this refers to the present value of the stream of
prices for a given allowance price forecast, not just to any single
year's price. If the present value of allowance sales prices exceeds
that of allowance purchase prices STARRSS will still evaluate
plans, but it cannot capture profits from "arbitraged" allowances.
A maximum of 5 units may be linked
STARRSS limits the number of units in any given linkage to five.
Linked units will usually be units at a single plant for which there
are economies of scale in construction, supply delivery, etc.
B-1
-------
A maximum of 5 units may be redundant
STARRSS limits the number of units in any given redundancy
definition to five. Redundant units are units which are to be
considered identical for the purposes of preliminary analysis; it is
unlikely that units at two different plants would be considered
identical, or that there would be more than five affected units at
a single plant.
Bad Fuel Blend at Unit
Blend Adds up to
The fuel blend specified on the Affected Unit Operating Factors
screen must add up to 100%.
Bad New Fuel Blend at Option :
-------
Cant delete last unit
There must be at least one unit defined in the database at all
times. If only one unit remains in the database, the user will not
be allowed to delete it.
Cant delete: name in use by unit , for example
A compliance option name cannot be deleted if there is an option
at any unit which uses that name. Delete all options which use
the name before trying to delete the name from the list.
Cant display the report ~ is unreadable
Although reports can generally be displayed from a previous
execution of STARRSS, if certain files have been deleted or
tampered with, the user will have to re-run the evaluator or
optimizer and regenerate the report files.
Cant open file
Cant read file
Cant write to file
The file mentioned has either been deleted from the disk, is in a
different directory, or has had its "permissions" changed by the
user or another program.
Cant run a zero-year study
The Number of Years field on the Execution Parameters screen
must be set to one or more years.
B-3
-------
Can't start the graphics system: check the BGI directory
listed on the report parameters screen
There should be a drive and directory (e.g. c:\starrss\bgi) listed on
the Report Parameters screen which contains the
must be defined on or before
Starting in 1995 for a Phase I run, or 2000 for a Phase II run,
there must be a capacity factor specified for every unit, on the
Affected Unit Operating Factors screen, page 2. Use the Fill
function there (Ctrl-F) to see which years remain unspecified.
Capacity factors are not defined for any units
Normally unspecified capacity factors are assumed to be zero, but
if no capacity factors are specified anywhere in the database there
is no point in continuing with execution. This warning might
mean that the Base Year on the Tax Rate, Escalation Rates, and
Cost of Capital screen was moved forward, and all the capacity
factors were only specified for the old base year.
Fatal Error: The database is too large to be loaded
STARRSS tried to load a database that was too large for the
available memory and was unable to recover from the error. Try
eliminating memory-resident software, obtaining more RAM, or
using a smaller database.
Fuel is in use at unit ; not deleted
Fuels cannot be deleted if they are referenced anywhere else in the
database. In this case, the reference is on page one of the
Affected Unit Operating Factors screen for this unit. Delete all
other references before deleting the fuel itself.
B-4
-------
Fuel is used by option :
-------
H,M & L probabilities for pointer must add to 100%
— Adjusting probabilities to low=0, med-100, high=0
The three rightmost values in each row of the Probabilities
Associated with Forecasts screen are complimentary probabilities
and must add up to 100%. Because it is impossible to exit from
the Probabilities screen with inconsistent values, the database file
has probably been tampered with.
Internal error; preserve the file zbackup.sdb and
contact RCG/Hagler, Bcdlly for further assistance.
This warning message indicates an internal calculation error, or
possibly a corrupted database file. Please preserve any further
information the message gives, as well as the database
ZBACKUP.SDB so Hagler, Bailly can more easily locate the
problem.
Life of conservation or renewable does not overlap study years
— program removed from strategy ()
The "study years" begin in 1995 for a Phase I run or 2000 for a
Phase II run (see the Execute menu), and the length of the study
is specified in the Execution Parameters screen. The Incremental
Conservation/Renewables screen specifies the start year and
lifetime of the conservation or renewable program are specified.
The two ranges should overlap.
Life of linkage 's options do not overlap
— linkage disabled
The "study years" (see above for definition) and the lifespan of all
the options listed for this linkage (Option Life and Start Year on
page one of the Edit/Define Compliance Options screen) must
have some range of years in common. For example, a five-year
option starting in 1995 and a five-year option starting in 2001
cannot be linked, since presumably there is no economy of scale
for non-concurrent options. Such a link will simply be ignored by
the evaluator, but this warning will always be given.
B-6
-------
Life of option :
-------
No database has been loaded yet. Please select the
Load command from the Files menu to load a database.
A database can't be built from scratch. To build a new database,
load in an existing database and modify it appropriately. This
message will appear when trying to enter a screen when
STARRSS is first invoked, or after a failed attempt to load a
corrupted or missing database.
No help available for this screen
See the appropriate section of this manual for further assistance.
No legal compliance plans could be.created
If the optimizer fails to create any legal plans, it means either that
there weren't enough high-impact options flagged as "active" on
the Define Active Compliance Options screen (which can be
found by first entering the Develop STARRSS Strategies screen),
or that the allowance transaction limits are set too stringently on
the Allowance Parameters screen.
None of the strategies are active
At least one of the strategies on the Summarize and Execute
screen must be marked with a check for any execution to occur.
No plans have been saved.
If the Number of Plans to Save parameter on the Develop
STARRSS Strategies screen is set to zero, none of the plans
generated will be saved and evaluated afterwards.
B-8
-------
No report has been generated ( not found)
This report is not available for viewing; re-run the evaluator or
optimizer to generate the desired report again.
No strategies were generated
This message is generated when the second heuristic process has
been unable to generate any strategies. If this happens, use the
first heuristic or the full enumeration optimizer instead.
Number of Iterations for Heuristic #1 must be at least 1
Change the Number of Iterations for Heuristic #1 to a number
greater than zero.
Only legal compliance plans could be created
The Number of Plans to Save parameter was higher than the
number of possible combinations of active options specified in the
Define A ctive Compliance Options screen. Make more options
active or lower the number of plans to save.
Only 14 strategies can be simultaneously graphed
There is only room on the left side of the screen for 14 strategy
labels. Remove some of the check marks from the list of plans to
be graphed.
Option :
-------
Option :
-------
Phase II units may not be included in Phase I runs.
Deactivate options at unit .
Phase II units may not be included in Phase I runs.
Remove from strategy .
Reducing emissions at a Phase II affected unit does not influence
Phase I compliance, and cannot therefore be considered a part of
a Phase I compliance strategy.
Print file already exists: Append or overwrite?
When performing an evaluation or optimization or upon pressing
F2 while viewing a report, a file formatted for printing is written;
this message lets you choose whether to append the new pages of
information to the end of the file, or to erase the file and start
from the beginning.
Probability pointer MUST sum to 100%
The three rightmost values in each row of the Probabilities
Associated with Forecasts screen are complimentary probabilities
and must add up to 100%. Because it is impossible to exit from
the Probabilities screen with inconsistent values, the database file
has probably been tampered with.
Program has positive cost and increases emissions
The evaluation proceeds normally when a conservation or
renewable program has a positive cost, yet increases S02
emissions, but a message appears warning that the situation is not
ideal.
Program has zero cost
The evaluation proceeds normally when a conservation or
renewable program has zero cost, but this message alerts the user
to this unusual situation.
B-11
-------
Redundance has only one unit
Redundance is a way of indicating that two or more units should
be considered identical for the purpose of preliminary analysis.
Running the evaluator with this many strategies and
iterations AND with the detailed flag on will create
a huge disk file.
The primary purpose of the detailed information flag is to verify
that costs and bonuses are being computed in the way the user
expects. Therefore one or two iterations are probably sufficient
for a detailed examination of these values.
Running the optimizer with the detailed information flag
set to a value greater than 1 writes detailed information
information about the optimization process to the file
.DET. Its use is not recommended.
The detailed output of the optimizers is not documented and is
primarily intended for software development and verification at
Hagler, Bailly.
Set the Help Directory field in the Report Parameters
screen to the directory where the file "STARRSS.HLP"
is located.
STARRSS reads from this help file every time the user presses the
key.
Strategy ## () has no options or programs
— Evaluating it as a do-nothing strategy
The optimizers will sometimes suggest a strategy of allowance
purchases and nothing else; the warning message is sent, but it is
evaluated anyway.
B-12
-------
Strategy ##, conser./renew has zero impact
— Using 9999.99 as marginal cost
Strategy ##, option :
-------
There are no choices among active options
If only one choice (including choosing to do nothing!) is "active"
for each option in the Define Active Compliance Options screen
(accessed via the Develop STARRSS Strategies screen), then the
optimizers have no work to do and will refuse to execute. Note
that the active flags are all deactivated when the Phase I/Phase II
flag is flipped (to prevent consideration of Phase II units in a
Phase I run).
There are no compliance options defined in this database
There are no strategies defined in this database
There are no units defined in this database
Some forms cannot be entered without first defining objects in
other screens.
This operation may take more memory than you have available.
Check the "Memory Available" table under the Files menu to see
how much memory is available and how much is needed to
perform various functions. The memory requirements are only
estimates, and are generally on the high side, so execution may be
possible even if the table indicates that it is not; but do so at your
own risk — remember that the database is always saved as
"zbackup.sdb" at the start of an evaluation or optimization; in the
event of a crash or program termination, zbackup.sdb will contain
all the information the user had defined for the .sdb file prior to
the crash.
This report is too large to display at this
time. Print the file instead.
The file name given in the warning message contains the report
requested, although it is not formatted with page breaks, headers,
or footers. Try saving the database then removing options to free
up some memory.
B-14
-------
Undefined capacity factor at unit
You cannot exit from the Affected Unit Operating Factors screen
if there is some unit without a capacity factor specified somewhere
on page 2 or beyond.
:
-------
Unit is in at least two redundances
Redundances are sets of identical units. These sets cannot
overlap.
Unit has an incorrectly defined fuel
— using zero cost and sulfur content for existing fuel
The fuel blend specified on the Affected Unit Operating Factors
screen must add up to 100%.
Unit has more than 256 options to consider
The full enumeration optimizer won't work if more than 256
options are active at any one unit.
Units cannot be deleted while there are redundancies,
linkages, or user strategies defined. Please remove
all of these structures from the database before
deleting units.
This rule avoids the confusion that could be caused if (for
example) a unit were deleted but was still listed in a redundancy.
You don't have graphics capability!
This message indicates that whatever graphics capabilities the
user's machine may have, they are not recognized or supported by
the Borland C graphics subroutines that STARRSS uses.
You must set the base and end years to something reasonable.
The base year must be later than 1950, and the end year must be
within 150 years of the base year.
B-16
-------
APPENDIX C
TROUBLESHOOTING
This Troubleshooting appendix is meant to assist the user in solving operational problems that
the user may encounter when using STARRSS. Potential problem areas have been broken
down into the following general categories:
Invoking STARRSS
Moving Around the System
Changing Data Items
Loading Files
Evaluating
Optimizing
Reading Reports
Reading Input Summaries
C-l
-------
Invoking STARRSS
1
Problem
Explanation/Solution
"File not found"
STARRSS must be invoked from the
directory where it has been placed.
Change directory to that location before
calling STARRSS. (e.g.,
CD C:\STARRSS)
"Cannot execute STARRSS.EXE"
There is not enough memory available to
load the STARRSS executable.
STARRSS requires 500,000 bytes of core
memory. The user should eliminate
unneeded memory-resident programs, or
purchase more memory; however,
STARRSS cannot make use of extended
or expanded memory.
The program seems to be loaded into
memory, but does not work properly.
Possibly the PC has an 8086 I
microprocessor. STARRSS is written for |
80286 (or better) machines. It will not 1
work on an 8086 or compatible. |
The words, "STARRSS has been
modified" appear on the banner page, and
nothing else happens.
STARRSS copy-protection has been 1
triggered somehow. This copy of the |
executable has been rendered unusable. |
After the banner page, the words, "Can't
open " appear in a small
window.
The user must have typed
"STARRSS ," and
was not a valid STARRSS
database. |
C-2
-------
Moving Around the System
Problem
Explanation/Solution |
The cursor cannot be positioned over some
check marks.
Options belonging to a secondaiy unit in
any redundance are activated or 1
deactivated depending on the options at the I
primary unit.
The user cannot exit the Probabilities
Associated with Forecasts screen.
Each set of three probabilities must add up
to 100% before the user can leave the
screen.
The user cannot exit the Affected Unit
Operating Factors screen.
Two specific data items must have values
defined for them before the user can leave
this screen. At least one capacity factor
value must be defined; and a fuel or fuel
blend that adds up to 100% must be B
defined.
The user cannot exit the Edit/Define
Compliance Options screen.
A fuel or fuel blend adding up to 100%
must be defined before the user can exit
this screen.
The user cannot exit the Generating Unit
Redundance screen.
The user will not be allowed to exit this
screen if: two redundancies contain the
same unit, any redundance contains the
same unit twice, or a redundance contains
only a primary unit.
Typing the name of a fuel on the Fuels
screen does not bring up the cost and
content data for that fuel.
Use the F2 key, while the cursor is on the
fuel name, to move to a different fuel
definition. Typing a name only changes
the label on the current fuel.
I STARRS S disappears and the user is
presented with a DOS prompt.
The user may have accidentally selected 1
"Temporarily Exit to DOS." Type "exit" I
to return to STARRSS. |
(Continued)
C-3
-------
Moving Around the System (continued)
1 Problem
Explanation/Solution |
Help screens are not available.
Go to page two of the Reporting |
Parameters screen and make sure the Help
Directory references the directory that
contains the file "STARRSS.HLP". If the
user cannot locate the STARRSS.HLP file
on his or her PC, the user should copy the
file from the delivery diskette.
Graphical presentation of the results is not
available.
Go to page two of the Reporting
Parameters screen and change the BGI
Files Directory to the directory that
contains the graphical interface files.
These are the files that were included on
the delivery diskette which have the .BGI
file name extension. If this does not work, 1
graphics may be unavailable for this I
machine. |
C-4
-------
Changing Data Items
1 Problem
Explanation/Solution j
|
The name of a unit cannot be changed,
even though the cursor is apparently over
the correct field.
Unit names can only be changed on the j
Display/Edit Affected Units screen. Use E
the F2 key on a unit field to select
between existing units.
The name of a fuel cannot be changed,
even though the cursor is apparently over
the correct field.
Fuel names can only be changed on the
Fuels screen. Use F2 on a fuel field to
select between existing fuels.
All of the checkmarks for a given unit
cannot be turned off at once on the Select
Compliance Options screen.
This is appropriate. The "Do Nothing" 1
option must be activated if all of the other 1
options are inactive.
Two checkmarks cannot be turned on at
the same time on the User Strategies
screen.
A strategy consists of no more than one
option per unit. To model two options at
once, construct a third option which is the
combination of the first two.
The probability pointer on the A llowance
Sale Prices screen cannot be changed.
This pointer is identical to the one on the
A llowance Purchase Price screen; changing
that pointer will change both.
The emissions field on the Display/Edit
Affected Units screen is zero and cannot
be changed.
This is a calculated field; the user should
check the unit's capacity, capacity factor,
existing control technology, existing fuel
blend, and fuel contents.
Note that if the Base Year on the Tax Rate
screen is set forward, every yearly value
before the new Base Y ear in the system,
including unit capacity factors, will no
longer be available; this could cause a lot
of values to go to zero.
The Existing Fuel Blend on the Define
Compliance Options screen cannot be
changed.
The base fuel for each unit may be entered
and edited on the Affected Units Operating
Factors screen.
(Continued)
C-5
-------
Changing Data Items (continued)
1 Problem
Explanation/Solution
An item cannot be deleted.
Many values and structures in the database
are interdependent; e.g., deleting a fuel that
is in use by one or more units or
compliance options could leave the
database in a confusing state. To avoid
this, references to an item must be
removed before the item itself. Pop-up
messages will provide guidance in this
process.
C-6
-------
Loading Files
Problem
Explanation/Solution j
No files are listed in the Load window.
There are no STARRSS databases (i.e.,
files with .SDB extensions) in the current
directory; change to a different directory
by typing S, then entering a new directory
name. g
The desired database is not listed in the
Load window.
The file may be in a different directory.
Change to the right directory (see above).
The database started to load, but there was
an error.
Look up the error message in the
Warnings appendix. Either STARRSS
tried to load a file that was not a valid
database, or not enough memory was
available.
A STARRS S database has been renamed to
something other than *.SDB, and it is
therefore not listed in the Load window.
Type S, then enter the exact name of the
file.
C-7
-------
Evaluating
Problem
Explanation/Solution J
The evaluator's costs appear to be
incorrect.
1) Go to the Input Summaries section and
verify that the inputs to the evaluator are
correct.
2) Examine the Detailed Information File
(see the Execution Paratneters discussion
in section 7.0)
A scrubber was not credited with bonus
allowances.
1) The Technology Efficiency field on the
Edit/Define Compliance Options screen
must indicate an efficiency of 90%, even if
overrides are specified for the option, for
bonus allowance calculations to be
triggered.
2) The EXISTING pollution control
technology, defined on the Affected Unit
Operating Factors screen, is irrelevant to
bonus calculations.
3) Bonus allowances may have been
deactivated by values entered in the Bonus
Allowance Supply Percentage table on the
Allowance Parameters screen.
The utility has no emissions.
Use the Input Summaries to verify that
appropriate values have been specified for
the following:
Each unit's capacity factors
The base case and option fuel blends
The fuel's S02 content
The unit's capacity
The unit's existing S02 removal
technology efficiency
The option's S02 removal efficiency
The option's derate, capacity factor
change, and emissions override values.
C-8
-------
Optimizing
Problem
Explanation/Solution
Heuristic #1 only finds a single strategy.
Heuristic #1 searches for a single best
strategy under each of a variety of
scenarios. In some cases, it may judge a
single strategy best under ALL scenarios.
This single strategy may, on evaluation
prove to have a relatively narrow
distribution of costs (low risk).
Heuristic #1 does not find any strategies.
If the Number of Iterations for Heuristic
#i field is set to zero, the Heuristic will do
nothing.
The Optimizer finds fewer strategies than
the number in the Number of Plans to Save
field.
The Full Optimizer can only find as many
strategies as there are combinations of
activated options; the Heuristics will
usually find even fewer.
C-9
-------
Reading Reports
Problem
Explanation/Solution
The best strategy turned out to be doing
nothing but allowance purchases.
Check to see if the allowance prices are
too low, or option prices, fuel prices, or
escalation rates are too high. |
The impact of some strategies is greater
than the Reduction Target.
STARRSS tries to match each strategy's j
impact with the reduction target, but it j
may overcomply if the marginal 1
compliance option overcomplies, and 1
allowance sale limits prohibit the resale of I
all the extra allowances generated. I
I A strategy includes more allowance
I purchases than the permitted A llowance
Purchase Limit.
STARRSS strategies will never
undercomply; violation of purchase limits
is always a last resort, and is flagged in
the reports with an asterisk (*).
Two of the strategies generated by the
optimizer are identical.
Look at the Detail Report ~ different
similar strategies may be given the same
name.
The reports do not appear to pertain to the
optimization or evaluation requested.
Check the date on the header of the
reports; if there was an eiTor during the
execution then reports from a previous run
may still be available.
No reports are available.
The evaluation or optimization failed for
some reason and no reports were created.
Strategy A is cheaper than strategy B
according to the Optimizer, but in the
Evaluator B is cheaper than A.
The number of iterations for the
Optimizers and the Evaluator may be set to
different values.
The cost of Strategy A according to the
Evaluator is different from the Optimizer's
evaluation.
Some reports are blank.
There will be no units listed in certain
reports if the only strategy(-ies) evaluated
consisted solely of allowance transactions.
The Optimizer's suggested plans are not
very good ones.
Try a different Optimizer; each has its
strengths and weaknesses.
C-10
-------
Reading Input Summaries
1 Problem
Solution j
I Some fields are "dashed out."
i
1) Option cost and impact overrides may
have been specified; dashes through other
fields indicate that they will be ignored.
2) Dashes can also indicate that there is no
change from the base case situation.
A unit's base case "S02 rate" is zero.
Check the following:
The unit's capacity factor
The unit's base case fuel blend
The fuels' S02 content
The unit's capacity
The unit's existing S02 removal
technology efficiency
C-ll
-------
APPENDIX D
UNIT CONVERSIONS
To convert from
to.
Multiply bv
barrel (bbl)
3
m
1.590 E-01
Btu
joules
1.055 E+03
Btu/h
watts
2.928 E-01
ft3
3
m
2.832 E-02
gallon
m3
3.785 E-03
lb
kg
4.536 E-01
ton
kg
9.078 E+02
ton
tonne
9.078 E-01
D-1
-------
APPENDIX E
REFERENCES
1. Rose, Burns, Coggins, Harunuzzaman, and Viezer, Public Utility Commission
Implementation of the Clean Air Act's Allowance Trading Program. The National
Regulatory Research Institute, Columbus, Ohio, (May, 1992).
2. United States Department of Energy, Energy Information Administration (DOE/EIA),
Cost and Quality of Fuels for Electric Utility Plants 1990. July, 1991.
3. Rothschild, Susan S., National Allowance Data Base Technical Support Document.
EPA-430/R-92-003, 1992.
4. Utility Data Institute (UDI), U.S. Coal Plant Statistics 1990. January, 1992.
5. United States Bureau of Labor Statistics, Producer Price Index. March, 1992.
6. Black & Veatch, Clean Air Act Compliance Studv: Southern Indiana Gas & Electric
Company. November, 1991.
7. Radcliffe, Paul, "FGD Economics", EPRI Journal. December, 1990.
8. Electric Power Research Institute, Retrofit FGD Cost-Estimating Guidelines. 1984.
9. United Engineers & Constructors, Inc., Allegheny Power System Strategy to Comply
With the Requirements of the Clean Air Act Amendments of 1990. Volume 4, January,
1991.
10. Environmental Protection Agency, Office of Air and Radiation, Proposed Rules, 40 CFR
Parts 72, 72, 75, and 77, November, 1991.
11. Environmental Protection Agency, Office of Research and Development, Integrated Air
Pollution Control System Version 4.0. EPA/600/7-90/022a,b,c, and d (NTIS PB91
506469).
E-l
-------
TECHNICAL REPORT DATA
(Please read Instructions on the reverse before completing)
1. REPORT NO. 2.
EPA- 600 / R- 94- 017
3. RECIPIENT'S ACCESSION-NO.
4. TITLE AND SUBTITLE
State Acid Rain Research and Screening System
Version 1.0 User's Manual
5. REPORT DATE
January 1994
6. PERFORMING ORGANIZATION CODE
7. AUTHOR(S)
C. A. Bogart, S.J, Epstein, K.S. Piper, and
A. S. Taylor
8. PERFORMING ORGANIZATION REPORT NO.
9, PERFORMING OROANIZATION NAME AND ADDRESS
RCG/Hagler, Bailly, Inc.
P. O. Drawer O
Boulder, Colorado 80306
10. PROGRAM ELEMENT NO.
11. CONTRACT/GRANT NO.
68-D9-0142, Tasks 3-4
through 3-8
12. SPONSORING AGENCY NAME AND ADDRESS
EPA, Office of Research and Development
Air and Energy Engineering Research Laboratory
Research Triangle Park, NC 27711
13. TYPE OF REPORT AND PERIOD COVERED
Task Final; 12/91 - 12'92
14. SPONSORING AGENCY CODE
EPA/600/13
15. supplementary NOTES AEERL project officer is Christopher D. Geron, Mail Drop 62,
919/541-4639. A diskette containing the program accompanies this manual.
i6. abstract -jhe report is a user's manual that describes Version 1.0 of EPA's STate
Acid Rain Research and Screening System (STARRSS), developed to assist utility
regulatory commissions in reviewing utility acid rain compliance plans. It is a
screening tool that is based on scenario analysis and risk management techniques.
Designed to run quickly on a personal computer, STARRSS focuses on the compre-
hensive analysis of many compliance strategies. Of particular interest is how these
strategies are affected by uncertainty and market volatility. Therefore, as a screen-
ing system, STARRSS is designed for breadth rather than depth. STARRSS was
developed to identify compliance strategies that deserve further, more detailed ana-
lysis. The system offers users three capabilities: the ability to research or veriify
the costs and operating impacts for compliance options at affected generating units;
the ability to evaluate and compare the costs and risks associated with specific com-
pliance strategies; and the ability to develop, evaluate, and compare suggested com-
pliance strategies that are generated by an optimization process.
17. KEY WORDS AND DOCUMENT ANALYSIS
a. DESCRIPTORS
b.IDENTIFIERS/OPEN ENDED TERMS
c. cosati Field/Group
Pollution Operating Costs
Sulfur Dioxide Operations Research
Electric Power Generation
Precipitation (Meteorology)
Acidification
Mathematical Models
Pollution Control
Stationary Sources
Acid Rain
13B 14A, 05A
07 B 12 B
10A
04 B
07 C
12 A
18. DISTRIBUTION STATEMENT
Release to Public
19. SECURITY CLASS (This Report)
Unclassified
21. NO. OF PAGES
282
20. SECURITY CLASS (This page)
Unclassified
22. PRICE
EPA Form 2220-1 <9-73)