EMS incorrectly reads output variable
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.
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:
EnergyManagementSystem:ProgramCallingManager
!- EnergyPlus Model Calling Point
EnergyManagementSystem:OutputVariable
!- 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?
!- =========== ALL OBJECTS IN CLASS: ENERGYMANAGEMENTSYSTEM:SENSOR ===========
EnergyManagementSystem:Sensor,
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
!- =========== ALL OBJECTS IN CLASS: ENERGYMANAGEMENTSYSTEM:PROGRAMCALLINGMANAGER ===========
EnergyManagementSystem:ProgramCallingManager,
Read_EMS_Write_Caller, !- Name
AfterPredictorAfterHVACManagers, !- EnergyPlus Model Calling Point
Read_Write_Net_Electricity; !- Program Name 1
!- =========== ALL OBJECTS IN CLASS: ENERGYMANAGEMENTSYSTEM:PROGRAM ===========
EnergyManagementSystem:Program,
Read_Write_Net_Electricity, !- Name
SET EMS_Net_Electricity = Pre_EMS_Net_Electricity; !- Program Line 1
!- =========== ALL OBJECTS IN CLASS: ENERGYMANAGEMENTSYSTEM:OUTPUTVARIABLE ===========
EnergyManagementSystem:OutputVariable,
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 ===========
Output:Variable,
Whole Building, !- Key Value
Facility Net Purchased Electric Energy, !- Variable Name
Hourly; !- Reporting Frequency
!- =========== ALL OBJECTS IN CLASS: OUTPUT:METER ===========
Output:Meter,
EMS Net Facility Electricity Meter, !- Key Name
Hourly; !- Reporting Frequency
!- =========== ALL OBJECTS IN CLASS: METER:CUSTOM ===========
Meter:Custom,
EMS Net Facility Electricity Meter, !- Name
Electricity, !- Fuel Type
, !- Key Name 1
EMS_Net_Electricity; !- Output Variable or Meter Name 1
@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.
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 ofZoneTimestep
with that calling point, I'm not sure.@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...
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 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.