Question-and-Answer Resource for the Building Energy Modeling Community
Get started with the Help page
Ask Your Question
11

misleading hourly output values

asked 2015-09-02 12:16:09 -0600

updated 2017-09-25 15:35:04 -0600

This is to serve as a warning for users as well as a request to the EnergyPlus development team (and potentially also for OpenStudio developers) for some re-programming:

As I found out, EnergyPlus does not necessarily distinguish between values that are not defined and the numeric value zero (0). This leads to incorrect output values e.g. when calculating hourly averages. I have tested this with outputs for PLR and COP values for a Chiller (EIR). As an example see following results:

HourlyValuesCalculation

On the left you see how EnergyPlus calculates hourly averages for PLR and COP (results are in red). Results are incorrect because when Chiller is switched off, COP is undefined. Therefore averages should only be taken only from times when Chiller is actually running. The right hand side shows how hourly averages could be calculated, taking into account missing or undefined values (results in green).

My proposal therefore would be to introduce distinctions for numbers in source code, perhaps similar to conventions in the CRAN R language:

NA =  not available
NaN =  not a number    (0/0 = NaN)
Inf   = infinity       (1/0 = Inf)

Calculating averages then would usually be done by excluding all values which are NA.

ResultsViewer also would have to be adapted to handle correctly time series with missing values.

This could help to avoid potential sources of dangerous errors that may be difficult to identify, and of misinterpretations of output data.

Dear developers, what's your opinion ?

edit retag flag offensive close merge delete

Comments

@OS-user-AT, these kinds of issues and discussions are exactly why we just launched http://openstudio.uservoice.com/ and http://energyplus.uservoice.com/. Have at it!

__AmirRoth__'s avatar __AmirRoth__  ( 2015-09-02 17:58:39 -0600 )edit

if UserVoice is for improvement ideas and suggestions, and GitHub for bug-reports, would you like NOT to see bug-reports and improvements suggestions any more on UnmetHours ? The example above may be seen as a support issue, because users may have difficulty interpreting output results; it could be seen as a bug report, and it contains suggestions for improvements. To avoid necessity of multiple logins and additional passwords, what about creating a "CC:" or cross-link mechanism to UserVoice and GitHub (depending on karma ) for posts that are relevant to these websites ?

OS-user-AT's avatar OS-user-AT  ( 2015-09-03 01:08:03 -0600 )edit

No, I think it's fine to post it here because it's informational and people should know about it. I was only trying to say that you should __also__ post some version of this to either uservoice or github issues depending on whether you see this as a new feature request or a bug report.

__AmirRoth__'s avatar __AmirRoth__  ( 2015-09-03 12:39:34 -0600 )edit

1 Answer

Sort by » oldest newest most voted
7

answered 2015-09-04 07:54:26 -0600

updated 2015-09-04 09:03:24 -0600

The output processor currently averages or sums all time series data without qualification. There are some variables where any aggregation beyond a single timestep is not meaningful. COP is a particularly tricky one, because even an average COP during on times is not exactly what most users want to see. For this particular output variable, this is discussed in the Input Output Reference:

Chiller COP [W/W] This output is the coefficient of performance for the chiller during cooling operation. It is calculated as the evaporator heat transfer rate (Chiller Evaporator Cooling Rate) divided by the “fuel” consumption rate by the chiller. For the constant COP and electric chillers, the “fuel” is electricity so the divisor is Chiller Electric Power [W]. For the absorption chiller, the “fuel” is steam so the divisor is Steam Consumption Rate [W]. Note that this variable is reported as zero when the chiller is not operating. When reported for frequencies longer than "detailed" (such as timestep, hourly, daily, monthly or environment), this output will only be meaningful when the chiller is operating for the entire reporting period. To determine an average COP for a longer time period, compute the COP based on total evaporator heat transfer divided by total electric or fuel input over the desired period.

Output:Table:Monthly (and soon Output:Table:Annual in v8.4) offer additional aggregation rules for custom output reports.

edit flag offensive delete link more

Comments

1

Thanks & PROPOSAL: Since this is a potential trap for users, the software should NOT make available hourly COP output values based on standard averaging method (red colored) at all. Instead either issue warnings in err-file or implement the algorithm that the user currently is supposed to perform manually.

BTW, checking the RDD file for manual calculations, only finding Chiller Condenser Heat Transfer Energy. Is this the output variable (cumulated) to use instead of total evaporator heat transfer in this case ?

OS-user-AT's avatar OS-user-AT  ( 2015-09-07 02:01:54 -0600 )edit
1

HVAC,Sum,Chiller Evaporator Cooling Energy [J] divided by HVAC,Sum,Chiller Electric Energy [J]

MJWitte's avatar MJWitte  ( 2015-09-09 21:37:12 -0600 )edit
1

And there have been some discussions among the development team regarding the best solution to improve output processing for variables which don't aggregate well over time.

MJWitte's avatar MJWitte  ( 2015-09-09 21:43:32 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Training Workshops

Careers

Question Tools

3 followers

Stats

Asked: 2015-09-02 12:16:09 -0600

Seen: 482 times

Last updated: Sep 07 '15