[Bldg-sim] Energyplus Schedules and Daylight Saving Time

[Ryan Tanner]

Hi Jim,
For my controls investigations, it makes a difference every day during the
DST period, specifically I'm optimizing window open/close schedules for
natural ventilation - and when the windows open at hour 24 instead of hour
1, on a given day (say, on a day x it's a good idea to open windows at hour
1, and a bad idea to open them at hour 24) it really screws with my
results.

For a generic repeating schedule, i agree that it doesn't make much
difference in an annual simulation, but i'm looking at specific days, and
sometimes using actual weather data - so it really is important that i get
the controls implemented on the right day, at the right time.

Thanks for your help,
Ryan


On Tue, Oct 15, 2013 at 12:30 PM, Jim Dirkes <
jim at buildingperformanceteam.com> wrote:

> Ryan,****
>
> The E+ “hour” value is the hour preceding the value.  e.g., Hour 1 is
> 00:01 – 1:00****
>
> That means if you move everything back one hour, what previously was 00:01
> – 01:00 becomes 23:01 – 24:00.  It should not be the same day, but does it
> make an important difference for two hours out of the year?****
>
> ** **
>
> ** **
>
> *From:* bldg-sim-bounces at lists.onebuilding.org [mailto:
> bldg-sim-bounces at lists.onebuilding.org] *On Behalf Of *Ryan Tanner
> *Sent:* Tuesday, October 15, 2013 2:24 PM
> *To:* bldg-sim at lists.onebuilding.org
> *Subject:* [Bldg-sim] Energyplus Schedules and Daylight Saving Time****
>
> ** **
>
> 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****
>
> ...****
>
> ...****
>
> ...****
>



-- 
cell.401.932.6121
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/bldg-sim-onebuilding.org/attachments/20131015/8e0061cc/attachment-0002.htm>