EMS incorrectly reads output variable

asked 2019-09-06 18:38:57 -0500

mldichter gravatar image

updated 2019-09-09 19:55:38 -0500

I am trying to read the Facility Net Purchased Electric Energy output variable using EMS to change behavior of equipment in the simulation, but the value being read from the output variable and rewritten to a meter is not the value of the output variable in the CSV file. To show this, I have EMS read a Sensor for the Facility Net Purchased Electric Energy output variable and then write out that value into a custom meter.

image description

Most of the time, the difference is around 10^-13, but other times the difference is enormous.

Here is a google drive link to a minimal working example with the important objects listed below

There are quite a few places that could be messing up the EMS read and write:

    !- EnergyPlus Model Calling Point

    !- Update Frequency
    !- EMS Program or Subroutine Name

I don't know what the problem could be though. I tried a lot of plausible combinations of choices for those fields, but none of them have been close to correct for the entire simulation. Any ideas?


    Pre_EMS_Net_Electricity, !- Name
    Whole Building,          !- Output:Variable or Output:Meter Index Key Name
    Facility Net Purchased Electric Energy;  !- Output:Variable or Output:Meter Name


    Read_EMS_Write_Caller,   !- Name
    AfterPredictorAfterHVACManagers,  !- EnergyPlus Model Calling Point
    Read_Write_Net_Electricity;  !- Program Name 1


    Read_Write_Net_Electricity,  !- Name
    SET EMS_Net_Electricity = Pre_EMS_Net_Electricity;  !- Program Line 1


    EMS_Net_Electricity,     !- Name
    EMS_Net_Electricity,     !- EMS Variable Name
    Summed,                  !- Type of Data in Variable
    SystemTimestep,          !- Update Frequency
    Read_Write_Net_Electricity,  !- EMS Program or Subroutine Name
    J;                       !- Units

!-   ===========  ALL OBJECTS IN CLASS: OUTPUT:VARIABLE ===========

    Whole Building,          !- Key Value
    Facility Net Purchased Electric Energy,  !- Variable Name
    Hourly;                  !- Reporting Frequency

!-   ===========  ALL OBJECTS IN CLASS: OUTPUT:METER ===========

    EMS Net Facility Electricity Meter,  !- Key Name
    Hourly;                  !- Reporting Frequency

!-   ===========  ALL OBJECTS IN CLASS: METER:CUSTOM ===========

    EMS Net Facility Electricity Meter,  !- Name
    Electricity,             !- Fuel Type
    ,                        !- Key Name 1
    EMS_Net_Electricity;     !- Output Variable or Meter Name 1
edit retag flag offensive close merge delete


@rraustad Would you mind confirming if this is a bug or not? I don't want to submit an issue on github if it's my fault. Otherwise, please close the post.

mldichter gravatar imagemldichter ( 2019-10-16 11:27:11 -0500 )edit

You didn't list all the calling points you've tried but this one seems like it should work: EndOfSystemTimestepAfterHVACReporting, you might also need to use the output variable reporting frequency of ZoneTimestep with that calling point, I'm not sure.

rraustad gravatar imagerraustad ( 2019-10-16 12:19:57 -0500 )edit

@rraustad That helped, but there are still errors on the order of 10^7 at many of the timesteps. I added an issue here. https://github.com/NREL/EnergyPlus/is...

mldichter gravatar imagemldichter ( 2019-10-16 16:30:13 -0500 )edit

It has to be a calling point after the last time that meter is updated. Maybe EndOfZoneTimestepAfterZoneReporting would work better. It's probably better for someone on the E+ team to look at this and resolve one way or another.

rraustad gravatar imagerraustad ( 2019-10-17 10:51:53 -0500 )edit

@rraustad I think I tried that. After trying to figure out which choice was the right one didn't work, I just started trying all combinations. The different choices would give different results, but there would still be these 10^7 errors. EMS actually read correctly most of the time. 10^-13 error is quite reasonable for each timestep, but the 10^7 ruined the sum. The EMS also seemed to lag behind the CSV sometimes, and other times two consecutive timesteps would be wrong, but the sum would be correct. These an issue now, but seems like a low priority for the E+ team though. Oh well.

mldichter gravatar imagemldichter ( 2019-10-17 12:11:48 -0500 )edit