Revision history [back]

This isn't a bug in Year — the EMS variable is stable. The spikes come from how your EnergyManagementSystem:OutputVariable blocks are configured.

You set Type of Data in Variable = Summed and Update Frequency = SystemTimestep. With that combination, EnergyPlus adds up the value once per HVAC system sub-iteration inside each zone timestep. When cooling peaks, the HVAC solver subdivides the zone timestep into more sub-iterations to converge — say N of them — and the reported value becomes Year × N (and YearBaseline × N), which is why both variables spike in sync. It's the OutputProcessor doing exactly what Summed asks for, but Year isn't something you want summed.

## The fix

Change all three of your WIP_Year / WIP_YearDiff / WIP_YearBaseline output variables to:

  EnergyManagementSystem:OutputVariable,
    WIP_Year, Year, Averaged, ZoneTimestep, , ;

i.e. Summed → Averaged and SystemTimestep → ZoneTimestep. These are state values, not rates, so Averaged is the right choice.

## Verifying it's the sub-iteration mechanism

If you divide your reported WIP_Year by 2030 you get an integer — literally the number of HVAC sub-iterations that zone timestep used. Running your IDF on current develop (26.2.0), the distribution across all 26,352 timesteps of your RunPeriod:

   N    count    %run    WIP_Year
   1   25,429   96.50%     2030
   2      369    1.40%     4060
   3      206    0.78%     6090
   4      147    0.56%     8120
   5       60    0.23%    10150
   6       28    0.11%    12180
   7       26    0.10%    14210
   8       20    0.08%    16240
   9       20    0.08%    18270
  10       47    0.18%    20300

Every spike is exactly 2030 × N. 96.5% of timesteps are N=1 (no subdivision, correct value), which is why the spikes look sporadic. You can also request

  Output:Variable,*,HVAC System Solver Iteration Count,Timestep;

and you'll see it track the spikes too (it reports 3 × N on your model).

## One surprise: Year = 2030, not 2025

EnergyPlus reads the calendar year from the EPW file each step (ESP_Sevilla.083910_SWEC_2030.epw → year 2030), so Year is 2030 in your run even though RunPeriod Begin Year = 2025. If you want the RunPeriod year instead, the built-in CalendarYear is the one to use — it tracks the RunPeriod, not the weather file. Your YearDiff will then be 10 as expected.

So: - Use Averaged, ZoneTimestep to stop the spikes - Use CalendarYear instead of Year if you want 2025 - 2015 = 10

I also posted a detailed write-up with the full proof on GitHub issue https://github.com/NatLabRockies/EnergyPlus/issues/7569 for reference.