Central Energy Facility Optimization with Integrated Incentive and Price-Based Demand Response Programs

Increasing efforts have been dedicated recently towards the development of advanced system controls to optimize Central Energy Facility (CEF) operations in order to reduce energy consumption, and, consequently, energy cost. Reduction of electric consumption is beneficial for both customers and the Regional Transmission Organization (RTO) managing the power grid. Therefore, RTOs have setup Incentive-Based Demand Response (IBDR) programs, such as Economic Load Demand Response (ELDR), and Price-Based Demand Response (PBDR), such as Peak Load Contribution (PLC), to incentivize customers to lower their electric consumption or shift their electric loads. These strategies also reduce the need for the RTO to commission additional or even invest in new power plants during peak hours. The ELDR program allows customers to choose when and by how much to curtail their electric consumption in response to market prices. The customer is then compensated for the amount of power curtailed at the real-time Locational Marginal Prices (LMP). PLC charge, which prompts customers to shave or shift their peak load consumption, is a demand charge structure based on a customer’s contribution to the demand peaks which occur in a region or a zone managed by an RTO at certain hours over a base period. Charges associated with PLC are significant and a customer is billed, in addition to the regular energy consumption and demand charges, a monthly charge during the billing period, based on their PLC during the base period in the prior year. Given the diversity of assets within a CEF, the challenge becomes how to efficiently run the facility and allocate assets while responding to market prices in the IBDR programs and minimizing cost due to PLC charges. In this work, a hierarchal approach for optimizing CEF operations with integrated IBDR and PBDR programs is developed. The approach is focused on the ELDR program and the PLC charge structure in the Pennsylvania, Jersey, Maryland (PJM) RTO region. However, it can be extended to accommodate other programs in different regions. Given predicted CEF loads, day-ahead and/or real-time LMP, PLC charges, and energy rates, the optimization problem is solved over a horizon into the future using a linear programming framework. Since PLC Coincidental Peaks (CP) are not known in advance, the optimization problem uses an hourly mask of projected CP hours, which can be either entered by the user or predicted based on the status of the region. The developed approach allows for an optimal allocation of assets to guarantee the curtailment commitment in the ELDR program, in addition to minimizing the customer’s PLC during projected CP hours. Furthermore, it is adaptive as it updates asset allocation based on feedback from the ELDR market and any changes in the projected CP hours. In this paper, a case study of the implementation of the developed approach at Kent State University (KSU) is presented, which shows the validity of the proposed solution

Large Scale Optimization Problems for Central Energy Facilities with Distributed Energy Storage

On large campuses, energy facilities are used to serve the heating and cooling needs of all the buildings, while utilizing cost savings strategies to manage operational cost. Strategies range from shifting loads to participating in utility programs that offer payouts. Among available strategies are central plant optimization, electrical energy storage, participation in utility demand response programs, and manipulating the temperature setpoints in the campus buildings. However, simultaneously optimizing all of the central plant assets, temperature setpoints and participation in utility programs can be a daunting task even for a powerful computer if the desire is real time control. These strategies may be implemented separately across several optimization systems without a coordinating algorithm. Due to system interactions, decentralized control may be far from optimal and worse yet may try to use the same asset for different goals. In this work, a hierarchal optimization system has been created to coordinate the optimization of the central plant, the battery, participation in demand response programs, and temperature setpoints. In the hierarchal controller, the high level coordinator determines the load allocations across the campus or facility. The coordinator also determines the participation in utility incentive programs. It is shown that these incentive programs can be grouped into reservation programs and price adjustment programs. The second tier of control is split into 3 portions: control of the central energy facility, control of the battery system, and control of the temperature setpoints. The second tier is responsible for converting load allocations into central plant temperature setpoints and flows, battery charge and discharge setpoints, and temperature setpoints, which are delivered to the Building Automation System for execution. It is shown that the whole system can be coordinated by representing the second tier controllers with a smaller set of data that can be used by the coordinating controller. The central plant optimizer must supply an operational domain which constrains how each group of equipment can operate. The high level controller uses this information to send down loadings for each resource a group of equipment in the plant produces or consumes. For battery storage, the coordinating controller uses a simple integrator model of the battery and is responsible for providing a demand target and the amount of participation in any incentive programs. Finally, to perform temperature setpoint optimization a dynamic model of the zone is provided to the coordinating controller. This information is used to determine load allocations for groups of zones. The hierarchal control strategy is successful at optimizing the entire energy facility fast enough to allow the algorithms to control the energy facility, building setpoints, and program bids in real-time

The Astropy Problem

The Astropy Project (http://astropy.org) is, in its own words, "a community effort to develop a single core package for Astronomy in Python and foster interoperability between Python astronomy packages." For five years this project has been managed, written, and operated as a grassroots, self-organized, almost entirely volunteer effort while the software is used by the majority of the astronomical community. Despite this, the project has always been and remains to this day effectively unfunded. Further, contributors receive little or no formal recognition for creating and supporting what is now critical software. This paper explores the problem in detail, outlines possible solutions to correct this, and presents a few suggestions on how to address the sustainability of general purpose astronomical software