Greetings,
Can someone explain to me why energyplus behaves the way that it does when
daylight saving time is used?
Specifically, scheduled values are shifted in the following way:
In a simulation, during DST, (summer), a schedule with 24 unique values for
a single day will have values [2:24] used during hours 1:23, and value [1]
used during hour 24. The first part seems reasonable, shift scheduled
values back by one hour, but the last part seems wrong, shifting a
scheduled value from hour 1 to hour 24 of the same day.
Since I'm doing controls studies, and I use schedules to define when some
systems are on or off, this issue is particularly troubling. When I intend
for a system to be ON during hour 1 and OFF during hour 2, the schedule is
adjusted by energyplus so that during the simulation the system is OFF
during hour 1, and ON during hour 24...not exactly what I intended.
Have any other users experienced this? Any suggestions for a workaround? I
would like to have DST in effect, so that occupancy, lighting schedules,
equipment schedules, etc. are correct relative to the sun's position and
the local weather conditions - and I would ALSO like for my controls
schedules to be used as intended, not shifted forward or backward, so that
when I schedule a system to be ON during hour 1, it is ON during hour 1,
whether it's winter or summer in simulation.
An example file and complete results are attached; file description and
results sample are included below.
Cheers,
Ryan
----
I've attached an example IDF that demonstrates the issue, as well as the
CSV output, my file is adapted from the example
file: 1ZoneUncontrolledResLayers.idf; I made the following changes:
1. added a RUNPERIODCONTROL:DAYLIGHTSAVINGTIME object that applies DST from
March 5 to November 5
2. added a schedule:compact object called DST_test_schedule
**this schedule has the following format, each hour for each day has a
unique value which should match that day and time; so the value for March
2, hour 5 is 3.0205, the value for March 4, hour 7 is 3.0407, etc.
3. added an output for the above schedule, removed all other outputs
4. removed annual runperiod, added two shorter runperiods that encompass
the DST start and end dates.
In the InputOutputReference, the following note is provided:
----
Note: For EnergyPlus Output:Variable and Output:Meter reporting, the time
stamps are always in standard time. When daylight saving time is active,
scheduled loads and controls will shift one hour relative to standard time.
----
**this is not accurate, since MOST values are shifted (backward) by 1 hour,
but values scheduled during hour 1 are shifted (forward) by 23 hours.
--excerpt from results CSV--
Date/Time, DST_TEST_SCHEDULE:Schedule Value [](Hourly)
...
...
...
03/03 22:00:00, 3.0322
03/03 23:00:00, 3.0323
03/03 24:00:00, 3.0324
03/04 01:00:00, 3.0401
03/04 02:00:00, 3.0402
03/04 03:00:00, 3.0403
03/04 04:00:00, 3.0404
03/04 05:00:00, 3.0405
03/04 06:00:00, 3.0406
03/04 07:00:00, 3.0407
03/04 08:00:00, 3.0408
03/04 09:00:00, 3.0409
03/04 10:00:00, 3.041
03/04 11:00:00, 3.0411
03/04 12:00:00, 3.0412
03/04 13:00:00, 3.0413
03/04 14:00:00, 3.0414
03/04 15:00:00, 3.0415
03/04 16:00:00, 3.0416
03/04 17:00:00, 3.0417
03/04 18:00:00, 3.0418
03/04 19:00:00, 3.0419
03/04 20:00:00, 3.042
03/04 21:00:00, 3.0421
03/04 22:00:00, 3.0422
03/04 23:00:00, 3.0423
03/04 24:00:00, 3.0424
03/05 01:00:00, 3.0502
03/05 02:00:00, 3.0503
03/05 03:00:00, 3.0504
03/05 04:00:00, 3.0505
03/05 05:00:00, 3.0506
03/05 06:00:00, 3.0507
03/05 07:00:00, 3.0508
03/05 08:00:00, 3.0509
03/05 09:00:00, 3.051
03/05 10:00:00, 3.0511
03/05 11:00:00, 3.0512
03/05 12:00:00, 3.0513
03/05 13:00:00, 3.0514
03/05 14:00:00, 3.0515
03/05 15:00:00, 3.0516
03/05 16:00:00, 3.0517
03/05 17:00:00, 3.0518
03/05 18:00:00, 3.0519
03/05 19:00:00, 3.052
03/05 20:00:00, 3.0521
03/05 21:00:00, 3.0522
03/05 22:00:00, 3.0523
03/05 23:00:00, 3.0524
03/05 24:00:00, 3.0501
03/06 01:00:00, 3.0602
03/06 02:00:00, 3.0603
03/06 03:00:00, 3.0604
...
...
...
