[Bldg-sim] Energyplus Schedules and Daylight Saving Time

sansregret.simon at lte.ireq.ca sansregret.simon at lte.ireq.ca
Wed Oct 16 09:44:08 PDT 2013


Interesting findings Ryan. 

I'm also working with Daylight Saving Time in EnergyPlus because we're doing hourly calibration on short run period. If I understand well, the results from your csv file should be

 03/05  23:00:00, 3.0524

 03/05  24:00:00, 3.0601

 03/06  01:00:00, 3.0602

Instead of

 03/05  23:00:00, 3.0524

 03/05  24:00:00, 3.0501

 03/06  01:00:00, 3.0602

 

I agree this could be problematic if schedule values differs from 24h to 1h.

I tested differently.  Instead of using a compact schedule definition as you did, I used a Schedule:File object using the same naming value as you proposed (See attached scheduleFile attached). I taught that maybe the wording (Throught : mm/dd) in compact schedule definition could be the cause. But no, It react the same... With Schedule:file object definition, I got also

 03/05  23:00:00, 3.0524

 03/05  24:00:00, 3.0501

 03/06  01:00:00, 3.0602

 

Good to know

 

 

Simon Sansregret, ing., M. Sc. A.

Chercheur

Institut de Recherche d'Hydro-Québec
+ Laboratoire des Technologies de l'Énergie (LTE)
       600, Avenue de la Montagne
       Shawinigan, (Québec), Canada
       G9N 7N5

' interne (HQ) : 274-1555

' externe : 819-539-1400 (poste 1555)
:  sansregret.simon at lte.ireq.ca

De : bldg-sim-bounces at lists.onebuilding.org [mailto:bldg-sim-bounces at lists.onebuilding.org] De la part de Ryan Tanner
Envoyé : 15 octobre 2013 14:47
À : Jim Dirkes
Cc : bldg-sim at lists.onebuilding.org
Objet : Re: [Bldg-sim] Energyplus Schedules and Daylight Saving Time

 

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/20131016/33412f56/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1ZoneUncontrolledResLayers_DSTexample2.csv
Type: application/octet-stream
Size: 12929 bytes
Desc: 1ZoneUncontrolledResLayers_DSTexample2.csv
URL: <http://lists.onebuilding.org/pipermail/bldg-sim-onebuilding.org/attachments/20131016/33412f56/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1ZoneUncontrolledResLayers_DSTexample2.idf
Type: application/octet-stream
Size: 35611 bytes
Desc: 1ZoneUncontrolledResLayers_DSTexample2.idf
URL: <http://lists.onebuilding.org/pipermail/bldg-sim-onebuilding.org/attachments/20131016/33412f56/attachment-0007.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ScheduleFile.csv
Type: application/octet-stream
Size: 72286 bytes
Desc: ScheduleFile.csv
URL: <http://lists.onebuilding.org/pipermail/bldg-sim-onebuilding.org/attachments/20131016/33412f56/attachment-0008.obj>


More information about the Bldg-sim mailing list