[Bldg-sim] Energyplus Schedules and Daylight Saving Time

Ryan Tanner ryanatanner at gmail.com
Tue Oct 15 11:47:02 PDT 2013


Jim,

Another example: suppose a building needs 8 hours to pre-cool before
occupancy on a Monday in order to meet comfort requirements, and the
cooling system is off on weekends. With the current energyplus DST
schedule-shifting, your building will only get 7-hours of pre-cooling on
Monday morning, and will get an extra hour of cooling on Friday night.

schedule might look something like:
For: Weekdays,
Until: 8:00,
1,
Until: 24,
0,
For: Weekends,
Until: 24:00,
0,
...

Ryan


On Tue, Oct 15, 2013 at 12:39 PM, Ryan Tanner <ryanatanner at gmail.com> wrote:

> 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
>



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


More information about the Bldg-sim mailing list