Different Hourly Values for Winter and Summer

5 posts / 0 new
Last post

Hello all,
While looking at eQuest Hourly Results for lighting end-use I came across a
situation where 24-hr lighting end-use had different values for WD during
winter and summer. Please see the results below.

LTG WD [7.44kW] 2-Jan 7-Apr 28-Oct
0.45 3.3481 1.11603 3.3481
0.15 1.11603 1.11603 1.11603
0.15 1.11603 1.11603 1.11603
0.15 1.11603 1.11603 1.11603
0.15 1.11603 3.3481 1.11603
0.45 3.3481 6.69619 3.3481
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 3.3481 6.69619

It looks like the values shifted roughly around the week of 4/7, one hour
upwards so overall usage remained the same every weekday but again changed
to actual one on 10/28. Connected lighting load is 7.44kW and the schedule
is as per column one,
*There is only one schedule throughout the year[12/31]*. I'm using the
simulation year of 1996. I'm trying to estimate the average peak usage
between 2 pm-6 pm. Since the values change between winter week and summer
week, I'm unable to estimate exact peak usage. Any help would
be appreciated!

Thank you
Siddharth

Siddharth

patilsiddharth5@gmail.com's picture
Joined: 2016-06-13
Reputation: 0

If the question is the hourly shift, it may be daylight savings time which would occur during the April dates and would be standard time in January and would normally switch to Standard Time around that date in October or early November. (Always occurs on a weekend as opposed to a fixed date.)

Check one week earlier in October and it may be the savings time again. You should be able to turn off DST in the Model simulation variables, I forget exactly which menu.

David
Sent from my iPad

David Eldridge's picture
Offline
Joined: 2012-05-08
Reputation: 1

Hi Siddharth,

I shall try to help you out in the following certain way.

The problem that you are looking at is the non-able to read the hourly
report as per the modeled schedule.

The schedule provided has the input as 18 working hours input in the
schedule mighty to be the likely input for the working hours which
seemingly to be the output as 6.69619 Watts.
The other rather inputs are just after and before these hours whose output
in the hourly report is 3.3481 Watts.
The other rather given inputs can be for four consecutive hours whose
response is coming as 1.11603 Watts. So in overall the total number of
hours are coming as the sum-up which is 24 hours in consecutive pattern.
Now as the schedule is for total year in weekly pattern so the hours are
repeating in such a sense that the hourly report can be read in minding the
24 hour daily basis hourly report.

So might be reading the hourly report in this way can help you someway.

Hope this might help.

*Thanks,*
Sharad.Kumar
Freelancer
India.

.......................................................................................................................................................

From: siddharth patil
To: equest-users at lists.onebuilding.org

Date: Sat, 18 Apr 2020 13:25:32 -0700
Subject: [Equest-users] Different Hourly Values for Winter and Summer
Hello all,
While looking at eQuest Hourly Results for lighting end-use I came across a
situation where 24-hr lighting end-use had different values for WD during
winter and summer. Please see the results below.

LTG WD [7.44kW] 2-Jan 7-Apr 28-Oct
0.45 3.3481 1.11603 3.3481
0.15 1.11603 1.11603 1.11603
0.15 1.11603 1.11603 1.11603
0.15 1.11603 1.11603 1.11603
0.15 1.11603 3.3481 1.11603
0.45 3.3481 6.69619 3.3481
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 6.69619 6.69619
0.9 6.69619 3.3481 6.69619

It looks like the values shifted roughly around the week of 4/7, one hour
upwards so overall usage remained the same every weekday but again changed
to actual one on 10/28. Connected lighting load is 7.44kW and the schedule
is as per column one,
*There is only one schedule throughout the year[12/31]*. I'm using the
simulation year of 1996. I'm trying to estimate the average peak usage
between 2 pm-6 pm. Since the values change between winter week and summer
week, I'm unable to estimate exact peak usage. Any help would
be appreciated!

Thank you
Siddharth

_______________________________________________
Equest-users mailing list
Equest-users at lists.onebuilding.org
http://lists.onebuilding.org/listinfo.cgi/equest-users-onebuilding.org

Sharad Kumar2's picture
Offline
Joined: 2015-05-21
Reputation: 0

Siddharth;

The issue isn?t the hourly schedules or some misalignment. It?s probably USA daylight saving time. Until 2005 in the USA daylight saving time extended from first Sunday in April (4/7/1996) to last Sunday in October (10/25/1996). (It has been extended in US by ~2 weeks on both sides). Note: I believe eQuest uses the older dates as it predates the change, so there?s a fun legacy fact.

There is an option within eQuest to disable accounting for daylight saving time. This should force hours to align with expectations.

Thanks,
DARIC R ADAIR PE, CEM, BEMP
Mechanical Engineer, Energy Analyst

Henderson Engineers
daric.adair at hendersonengineers.com

Licensed in KS

Daric Adair's picture
Offline
Joined: 2017-10-21
Reputation: 0

If you have enabled the doe2.3 engine, the input you are looking for is here:
[cid:image004.png at 01D61703.58948F00]
If you are using the doe2.2 engine, this dropdown is in the same screen, but a different position.

For further reading, see the following in the doe2 reference manual entry (Help --> DOE-2 Help?) : Volume 2: Dictionary > Envelope Components > SITE-PARAMETERS > Daylight Savings Invervals

I?ll also observe: If as-stated your concern is establishing the peak load between 2 and 6pm, this whole matter does not impact your query as your simulation appears to always resolving to 6.69619 kWh load during that timeframe. The only seasonal variation identified is during the midnight and 5AM hours. If you are uncertain/distrustful of the ?rainbow reports? provided by eQuest (I always encourage the spirit of ?trust but verify? with energy simulation), I might suggest using Excel to create a quick pivot chart displaying maximum total meter draw, grouped by month/hour, to assert that with absolute certainty.

Further, I might challenge the assumption that there is even a problem here (if there is one). Observing the hourly fractional values of this schedule are probably intended to reflect an aggregate of lighting control devices (automated and/or occupant-controlled), you might really need to start with answering this prompt: ?To what extent were these lights affected when clocks shifted forward and backward due to daylight savings time in 1996?? If the majority of lights are turned on/off by people who are adjusting their workday to reflect daylight savings, or with astronomical timeclocks (which self-adjust to reflect the varying sunrise/sunset times through the year, then what?s being simulated may well be a pretty accurate result. In that case, you might not want to change anything.

~Nick

[cid:image002.jpg at 01D61703.79B71270]
Nick Caton, P.E., BEMP
Senior Energy Engineer
Energy and Sustainability Services
Energy Performance Contracting
D
M
E

913 . 564 . 6361
785 . 410 . 3317
nicholas.caton at se.com
15200 Santa Fe Trail Drive
Suite 204
Lenexa, KS 66219

[cid:image003.png at 01D61700.6061F680]

Nicholas Caton2's picture
Offline
Joined: 2019-03-25
Reputation: 0