Example 4. Halt Program Based on Constraint[LINK]
Problem Statement[LINK]
Heavy users of EnergyPlus explore the enormous parameter space associated with building design options. Computational requirements often limit what can be accomplished in a given study. For optimizations and other parametric studies, there is usually a tension between having a very detailed model that is comfortably accurate, and a simpler model that executes faster.
For most studies many trial simulations are discarded because they violate some constraint. To save computation time, you might consider “fatal–out” simulations where early calculations show that some predetermined constraints will not be met in the final result. Many studies could save considerable computing resources by prematurely quitting models rather than always letting each simulation run to completion. All types of constraints such as poor comfort, excessive system iterations, and high energy costs could be used to kill a run. You should ask, Is there a way to use the EMS to expedite my optimal searches by stopping models prematurely if they fail some test?
EMS Design Discussion[LINK]
As an example, let us assume that the criterion for early exit is that the model fails to be sufficiently comfortable. We will start with the Small Hotel Reference Building example file (RefBldgSmallHotelNew2004_Chicago.idf). Short periods of discomfort are tolerated, but if the space is uncomfortable over time, we want to abandon the simulation and save computational expense. A simulation can be stopped from within an Erl program by calling the built-in function “@FatalHaltEp.” The EMS system has only numeric data types, so we cannot generate text for the error message. Therefore, we choose a particular real-numbered value to use as an error code that provides some detail on which constraint caused early termination. In this example, we choose the value “1002.50” to indicate an average PMV exceeds 2.5 and the value “9001.30” indicates the average PMV less than 1.3. We will formulate the constraint by using the result of the Fanger comfort model for PMV for the building’s core zone named “Core_ZN.” If the occupants will be too cold, we will call @FatalHaltEp with the error code 9001.30. If the occupants will be too warm during a summer design day, we will fatal out with the error code 1002.50. (These values were chosen arbitrarily to demonstrate EMS; PMV of 1.3 is not necessarily a problem.)
To monitor PMV, we will use a trend variable, which we create by using the EnergyManagementSystem:TrendVariable input object. A trend variable is a log of historical values for Erl variables. A trend log is an array that goes farther and farther back in time. For this example, we assume the constraint is to monitor the average PMV for the previous 2-hour period. The example file has 6 timesteps per hour, so each trend point is 10 minutes and a 2-hour average needs 12 timesteps. So the field Number of Timesteps to be Logged must be 12 or larger. To access the values stored in a trend variable, the built-in functions provided for accessing trends must be used. The @TrendAverage function called with an index of 12 will return the 2-hour running average. To monitor this result of running average PMV, we set up custom output variable using an EnergyManagementSystem:OutputVariable input object.
The EMS input objects for this example follow and are contained in the example file called “EMSTestMAthAndKill.idf.”
EnergyManagementSystem:ProgramCallingManager,
Average Building Temperature , ! Name
EndOfZoneTimestepBeforeZoneReporting , ! EnergyPlus Model Calling Point
updateMy_averagePMV; ! Program Name 1
EnergyManagementSystem:Sensor,
PMV5, !Name
Core_ZN , ! Output:Variable or Output:Meter Index Key Name
Zone Thermal Comfort Fanger Model PMV ; ! Output:Variable Name
EnergyManagementSystem:TrendVariable,
PMVtrendLog1,
PMV5,
300;
EnergyManagementSystem:GlobalVariable,
PMVrunningAvg;
EnergyManagementSystem:OutputVariable,
Running Two Hour Average PMV [PMVunits], ! Name
PMVrunningAvg, ! EMS Variable Name
Averaged, ! Type of Data in Variable
ZoneTimeStep ; ! Update Frequency
EnergyManagementSystem:Program,
UpdateMy_averagePMV,
Set PMVrunningAvg = @TrendAverage PMVtrendLog1 12, ! two hour running average.
RUN Kill_Run_if_Uncomfortable;
EnergyManagementSystem:Subroutine,
Kill_Run_if_Uncomfortable,
IF PMVrunningAvg > 2.5,
SET tmpError = @FatalHaltEp 1002.50, ! error code "1002.50" for comfort avg over 2.5
ENDIF,
IF PMVrunningAvg < 0.0 - 1.3,
SET tmpError = @FatalHaltEp 9001.30, ! error code "9001.30" for comfort avg under - 1.3
ENDIF;
Example 4. Halt Program Based on Constraint[LINK]
Problem Statement[LINK]
Heavy users of EnergyPlus explore the enormous parameter space associated with building design options. Computational requirements often limit what can be accomplished in a given study. For optimizations and other parametric studies, there is usually a tension between having a very detailed model that is comfortably accurate, and a simpler model that executes faster.
For most studies many trial simulations are discarded because they violate some constraint. To save computation time, you might consider “fatal–out” simulations where early calculations show that some predetermined constraints will not be met in the final result. Many studies could save considerable computing resources by prematurely quitting models rather than always letting each simulation run to completion. All types of constraints such as poor comfort, excessive system iterations, and high energy costs could be used to kill a run. You should ask, Is there a way to use the EMS to expedite my optimal searches by stopping models prematurely if they fail some test?
EMS Design Discussion[LINK]
As an example, let us assume that the criterion for early exit is that the model fails to be sufficiently comfortable. We will start with the Small Hotel Reference Building example file (RefBldgSmallHotelNew2004_Chicago.idf). Short periods of discomfort are tolerated, but if the space is uncomfortable over time, we want to abandon the simulation and save computational expense. A simulation can be stopped from within an Erl program by calling the built-in function “@FatalHaltEp.” The EMS system has only numeric data types, so we cannot generate text for the error message. Therefore, we choose a particular real-numbered value to use as an error code that provides some detail on which constraint caused early termination. In this example, we choose the value “1002.50” to indicate an average PMV exceeds 2.5 and the value “9001.30” indicates the average PMV less than 1.3. We will formulate the constraint by using the result of the Fanger comfort model for PMV for the building’s core zone named “Core_ZN.” If the occupants will be too cold, we will call @FatalHaltEp with the error code 9001.30. If the occupants will be too warm during a summer design day, we will fatal out with the error code 1002.50. (These values were chosen arbitrarily to demonstrate EMS; PMV of 1.3 is not necessarily a problem.)
To monitor PMV, we will use a trend variable, which we create by using the EnergyManagementSystem:TrendVariable input object. A trend variable is a log of historical values for Erl variables. A trend log is an array that goes farther and farther back in time. For this example, we assume the constraint is to monitor the average PMV for the previous 2-hour period. The example file has 6 timesteps per hour, so each trend point is 10 minutes and a 2-hour average needs 12 timesteps. So the field Number of Timesteps to be Logged must be 12 or larger. To access the values stored in a trend variable, the built-in functions provided for accessing trends must be used. The @TrendAverage function called with an index of 12 will return the 2-hour running average. To monitor this result of running average PMV, we set up custom output variable using an EnergyManagementSystem:OutputVariable input object.
EMS Input Objects[LINK]
The EMS input objects for this example follow and are contained in the example file called “EMSTestMAthAndKill.idf.”
Documentation content copyright © 1996-2015 The Board of Trustees of the University of Illinois and the Regents of the University of California through the Ernest Orlando Lawrence Berkeley National Laboratory. All rights reserved. EnergyPlus is a trademark of the US Department of Energy.
This documentation is made available under the EnergyPlus Open Source License v1.0.