-
Notifications
You must be signed in to change notification settings - Fork 384
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flag added to toggle daylight saving when used with Schedule:File #9251
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good so far. I think the next step is to do the input processing here.
idd/Energy+.idd.in
Outdated
A6 ; \field Daylight Savings Toggle | ||
\note Toggles between daylight savings ON and Off (default) | ||
\type choice | ||
\key Yes | ||
\key No | ||
\default No |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some minor suggested changes to the wording here.
A6 ; \field Daylight Savings Toggle | |
\note Toggles between daylight savings ON and Off (default) | |
\type choice | |
\key Yes | |
\key No | |
\default No | |
A6 ; \field Adjust Schedule for Daylight Savings | |
\note Turn ON to adjust the schedule for DST | |
\note Turn OFF to use the schedule directly (default) | |
\type choice | |
\key Yes | |
\key No | |
\default No |
src/EnergyPlus/ScheduleManager.hh
Outdated
@@ -165,11 +165,12 @@ namespace ScheduleManager { | |||
Real64 CurrentValue; // For Reporting | |||
bool EMSActuatedOn; // indicates if EMS computed | |||
Real64 EMSValue; | |||
bool UseDaylightSaving; // Toggles between daylight saving ON and OFF (default) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems light the right place to put this.
src/EnergyPlus/ScheduleManager.hh
Outdated
|
||
// Default Constructor | ||
ScheduleData() | ||
: ScheduleTypePtr(0), WeekSchedulePointer(366, 0), Used(false), MaxMinSet(false), MaxValue(0.0), MinValue(0.0), CurrentValue(0.0), | ||
EMSActuatedOn(false), EMSValue(0.0) | ||
EMSActuatedOn(false), EMSValue(0.0), UseDaylightSaving(false) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the same data structure used for all schedules in EnergyPlus. So, for every schedule except the Schedule:File
this should be true. As such I think it makes sense to default it here to true
.
… idd and ScheduleManager.hh
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@prsh5175 With the help of the E+ team, I found out how to add a file to the repo and add it to a test here. I've done the coding part but not the actual adding the file part. I'll leave that to you. I've also made notes (and pointed to them) for places you will want to add tests.
// TODO: create this file with test data in it. | ||
// This test will fail until you do that. | ||
fs::path scheduleFile = configured_source_directory() / "tst/EnergyPlus/unit/Resources/schedule_file1.csv"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
☝️
// TODO: Add additional Schedule:File blocks above that test other possibilities to make sure they work right | ||
// such as: 1.) Setting to "No" | ||
// 2.) Leaving empty (should default to "No") | ||
// 3.) Omitting the last field (should default to "No") | ||
// Test that each option sets UseDaylightSaving correctly on the each schedule. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And ☝️
// TODO: Call LookUpScheduleValue with DSTIndicator on and off and check that the correct hour of data is being returned. | ||
|
||
state->dataEnvrn->DSTIndicator = 0; // Tells the simulation that we're NOT in daylight savings |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh and I forgot to put it in the comments as well, but also test to make sure that it's pulling the correct values from the schedule when the simulation is not in daylight savings for both the cases of schedules with and without the "observe DST" switch we put in. So both would not jump forward an hour.
…n the current state - need to discuss more to mitigate current errors. Dummy schedule file csv added in the repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's coming along. See below for comments and guidance on next steps to get things working.
@@ -831,6 +832,7 @@ TEST_F(EnergyPlusFixture, ScheduleFileColumnSeparator) | |||
" 8760, !- Number of Hours of Data", | |||
" Space, !- Column Separator", | |||
" No; !- Interpolate to Timestep"}); | |||
// Enter N4 and A6 fields here? (based on what is now defined in the IDD) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's something we'll need to do for backwards compatibility. Also with all the regression test files. And there's a version translator fortran thing you have to do as well. We'll get to that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this still a to-do item?
" Comma, !- Column Separator", // Changed the "space" separators to "comma" | ||
" No, !- Interpolate to Timestep", | ||
" 60, !- Minutes per item", | ||
" Yes, !- Adjust Schedule for Daylight Savings", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
" Yes, !- Adjust Schedule for Daylight Savings", | |
" Yes; !- Adjust Schedule for Daylight Savings", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it.. done
" Comma, !- Column Separator", | ||
" No, !- Interpolate to Timestep", | ||
" 60, !- Minutes per item", | ||
" No, !- Adjust Schedule for Daylight Savings", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
" No, !- Adjust Schedule for Daylight Savings", | |
" No; !- Adjust Schedule for Daylight Savings", |
" No, !- Interpolate to Timestep", | ||
" 60, !- Minutes per item", | ||
" ; !- Adjust Schedule for Daylight Savings", | ||
" ", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd also add one here that omits that last field. Something like:
"Schedule:File,",
" Test4, !- Name",
" , !- Schedule Type Limits Name",
" " + scheduleFile.string() + ", !- File Name",
" 1, !- Column Number",
" 0, !- Rows to Skip at Top",
" 8760, !- Number of Hours of Data",
" Comma, !- Column Separator",
" No, !- Interpolate to Timestep",
" 60; !- Minutes per item",
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it.
// TODO: Add additional Schedule:File blocks above that test other possibilities to make sure they work right | ||
// such as: 1.) Setting to "No" | ||
// 2.) Leaving empty (should default to "No") | ||
// 3.) Omitting the last field (should default to "No") | ||
|
||
// (PS: TODO items above -- Done) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Third one isn't done. See comment above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right. Test 4 is now added in the new version.
EXPECT_EQ(state->dataGlobal->HourOfDay + state->dataEnvrn->DSTIndicator, | ||
ScheduleManager::LookUpScheduleValue(*state, state->dataScheduleMgr->Schedule(sch1idx), state->dataGlobal->HourOfDay, state->dataGlobal->TimeStep)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What you're saying here is that you expect the hour of the day + the daylight savings indicator to be equal to the schedule value from the file. That's probably not going to work.
First, HourOfDay
hasn't been set for this test. You'll need to do that. The best way to see what's going on is to put a debugger on this test and a breakpoint on this line and follow the values you're using. Step through LookUpScheduleValue
and make sure variables from the state that it is using are set in your test.
Once you get that sorted out and it's pulling the value out of the schedule file. You'll want to compare the value of the schedule at a given day and hour not the hour itself. The test schedule file you added above is very realistic, but maybe not the best for testing. It may be useful to have the schedule with like a value of 1
for the hour before the one you want and 2
for the hour you want, or something like that. The rest can be filled with whatever. That way testing for values becomes pretty straightforward.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. That make a lot more sense now. OK, trying this part now. Thanks Noel.
idd/Energy+.idd.in
Outdated
\note Turn ON to adjust the schedule for DST | ||
\note Turn OFF to use the schedule directly (default) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the key choices are Yes/No, the notes should use those words instead of Turn On/Off.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noted, thanks. Changing the notes as follows in the new version: "
\note "Yes" means include Daylight Savings Time to the schedule
\note "No" means do not include Daylight Savings Time in the schedule, instead, use the schedule directly from the Schedule:File csv (default) "
Decision from EnergyPlus technicalities call:
|
…dule:File csv updated with first 24 hours of value 1 and rest 0.
@prsh5175 I think I got the unit test and the default functionality working right. Let's see what comes out of the CI runs overnight. If that comes back clean, I think all we have left is the Input/Output Reference. |
… Group - Schedules > Schedule:File > Field: Adjust Schedule for Daylight Savings
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@prsh5175 See my suggested edits to the docs below. I think we'll also want to do something with this warning as well. I'm on the fence of whether to remove it entirely or move it somewhere and only call it when we think someone is doing something dumb.
Decision: remove the warning since there's an explicit switch for it now. Bonus: should make things faster since it was being called a lot. |
Co-authored-by: Noel Merket <[email protected]>
\paragraph{Field: Adjust Schedule for Daylight Savings}\label{adjust-schedule-for-daylight-savings-1} | ||
|
||
This field indicates whether or not to shift the schedule forward an hour during daylight savings time. If "Yes" the schedule skips forward an hour in the CSV on the "spring forward" day and repeats an hour on the "fall back" day. If "No", the schedule is read and applied in standard time, without adjusting for daylight savings time. This indicator is defaulted to "Yes" if no input is provided. | ||
|
||
Here is an IDF example: | ||
|
||
\begin{lstlisting} | ||
Schedule:File, | ||
TestName, !- Name | ||
Any Number, !- Schedule Type Limits Name | ||
schedulefile.csv, !- File Name | ||
2, !- Column Number | ||
1, !- Rows to Skip at Top | ||
8760, !- Number of Hours of Data | ||
Comma, !- Column Separator | ||
No, !- Interpolate to Timestep | ||
60, !- Minutes per Item | ||
No; !- Flag to Adjust Schedule for Daylight Savings | ||
\end{lstlisting} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a paragraph in the documentation detailing the use of the optional flag to choose whether or not to shift the schedule values when daylight savings time is being included with a "Yes" value for the indicator.
idd/Energy+.idd.in
Outdated
\note "Yes" means include Daylight Savings Time to the schedule | ||
\note "No" means do not include Daylight Savings Time in the schedule, instead, use the schedule directly from the Schedule:File csv (default) | ||
\type choice | ||
\key Yes | ||
\key No | ||
\default Yes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Description of "Yes" and "No" options.
src/EnergyPlus/ScheduleManager.cc
Outdated
if (lAlphaBlanks(6)) Alphas(6) = "YES"; | ||
if ((Alphas(6)) == "YES") { | ||
state.dataScheduleMgr->Schedule(SchNum).UseDaylightSaving = true; | ||
} else if ((Alphas(6)) == "NO") { | ||
state.dataScheduleMgr->Schedule(SchNum).UseDaylightSaving = false; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If Alphas(6) field is a "Yes" or a blank, assign a "true" value to the UseDaylightSaving boolean, otherwise assign a "false" value. This boolean is then used in an if statement to decide whether or not to shift the schedule by one hour forward.
src/EnergyPlus/ScheduleManager.cc
Outdated
@@ -2776,7 +2765,13 @@ namespace ScheduleManager { | |||
// so, current date, but maybe TimeStep added | |||
|
|||
// Hourly Value | |||
int thisHour = ThisHour + state.dataEnvrn->DSTIndicator; | |||
int thisHour; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initialized "thisHour" outside the scope of the if statement. Its value is changed based on whether the UseDaylightSaving boolean has a "true" or a "false" value.
src/EnergyPlus/ScheduleManager.cc
Outdated
if (state.dataScheduleMgr->Schedule(ScheduleIndex).UseDaylightSaving) { | ||
thisHour = ThisHour + state.dataEnvrn->DSTIndicator; | ||
} else { | ||
thisHour = ThisHour; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the "UseDaylightSaving" boolean has a "true" value, the "thisHour" variable adds the DSTIndicator (value of 1 hour) to the "ThisHour" variable (note the capital vs small lettering in the variable names), otherwise, the hour value is unchanged (i.e., daylight savings time effect is not accounted for).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think Yoda taught me that booleans are simply 0 or 1, so I think this entire if/else could be reduced to
int const thisHour = ThisHour + state.dataEnvrn->DSTIndicator * state.dataScheduleMgr->Schedule(ScheduleIndex).UseDaylightSaving;
@Myoldmopar would this be the best solution?
" Comma, !- Column Separator", | ||
" No, !- Interpolate to Timestep", | ||
" 60, !- Minutes per item", | ||
" ; !- Adjust Schedule for Daylight Savings", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: Putting nothing here in the IDF for the flag (neither a "Yes" nor a "No").
" Comma, !- Column Separator", | ||
" No, !- Interpolate to Timestep", | ||
" 60; !- Minutes per item", | ||
" ", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Omitting the field all together, per the comment from @nmerket
state->dataGlobal->NumOfTimeStepInHour = 1; | ||
state->dataGlobal->MinutesPerTimeStep = 60; | ||
state->dataGlobal->TimeStep = 1; // Checking to see if omitting this is OK here | ||
state->dataEnvrn->DayOfWeek = 1; // Sunday | ||
state->dataEnvrn->DayOfWeekTomorrow = 2; // Monday | ||
state->dataEnvrn->DayOfYear_Schedule = 1; | ||
state->dataGlobal->HourOfDay = 24; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initiation of these variables within the unit testing scope.
state->dataEnvrn->DayOfYear_Schedule = 1; | ||
state->dataGlobal->HourOfDay = 24; | ||
|
||
// Test 1 condition |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Testing four different conditions each starting with a comment line that says "// Test X condition "...
EXPECT_TRUE(sch1.UseDaylightSaving); // Checks that the member variable got set correctly. | ||
|
||
state->dataEnvrn->DSTIndicator = 1; // Tells the simulation that we're currently observing daylight savings | ||
EXPECT_DOUBLE_EQ(ScheduleManager::LookUpScheduleValue(*state, sch1idx, state->dataGlobal->HourOfDay, state->dataGlobal->TimeStep), 0.0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comparing the value from the CSV file that is looked up against the expected value of 0 for the 24th hour of the day.
The regression test diffs are OK because there are new field(s) with defaults, and new field(s) which are being defaulted (because the existing files don't have the new field present, thus they get defaulted). |
The following warning has been removed from ScheduleManager.cc since the indicator value is actively being assigned in the IDF now, and removing this warning will also speed up the run since there are fewer checks needed: if (!state.dataScheduleMgr->ScheduleDSTSFileWarningIssued) { |
@@ -542,6 +542,26 @@ \subsubsection{Inputs}\label{inputs-9-019} | |||
60; !- Minutes per Item | |||
\end{lstlisting} | |||
|
|||
\paragraph{Field: Adjust Schedule for Daylight Savings}\label{adjust-schedule-for-daylight-savings-1} | |||
|
|||
This field indicates whether or not to shift the schedule forward an hour during daylight savings time. If "Yes" the schedule skips forward an hour in the CSV on the "spring forward" day and repeats an hour on the "fall back" day. If "No", the schedule is read and applied in standard time, without adjusting for daylight savings time. This indicator is defaulted to "Yes" if no input is provided. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please fix the quote marks. Use ``text''.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
idd/Energy+.idd.in
Outdated
\note "Yes" means include Daylight Savings Time to the schedule | ||
\note "No" means do not include Daylight Savings Time in the schedule, instead, use the schedule directly from the Schedule:File csv (default) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
move "(default)" to the first note.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Default moved to the first note.
src/EnergyPlus/ScheduleManager.cc
Outdated
if (lAlphaBlanks(6)) Alphas(6) = "YES"; | ||
if ((Alphas(6)) == "YES") { | ||
state.dataScheduleMgr->Schedule(SchNum).UseDaylightSaving = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit picking. But the first 2 lines here are not necessary. Start with line 1654, then reset it if Alphas(6) = No.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed per comment.
src/EnergyPlus/ScheduleManager.cc
Outdated
if (state.dataScheduleMgr->Schedule(ScheduleIndex).UseDaylightSaving) { | ||
thisHour = ThisHour + state.dataEnvrn->DSTIndicator; | ||
} else { | ||
thisHour = ThisHour; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think Yoda taught me that booleans are simply 0 or 1, so I think this entire if/else could be reduced to
int const thisHour = ThisHour + state.dataEnvrn->DSTIndicator * state.dataScheduleMgr->Schedule(ScheduleIndex).UseDaylightSaving;
@Myoldmopar would this be the best solution?
Comma, !- Column Separator | ||
No, !- Interpolate to Timestep | ||
60, !- Minutes per Item | ||
No; !- Flag to Adjust Schedule for Daylight Savings |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove "Flag to " from field comment to match IDD.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Flag to " removed.
\paragraph{Field: Adjust Schedule for Daylight Savings}\label{adjust-schedule-for-daylight-savings-1} | ||
|
||
This field indicates whether or not to shift the schedule forward an hour during daylight savings time. If "Yes" the schedule skips forward an hour in the CSV on the "spring forward" day and repeats an hour on the "fall back" day. If "No", the schedule is read and applied in standard time, without adjusting for daylight savings time. This indicator is defaulted to "Yes" if no input is provided. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe add a reference to the DST object? Via Latex, not the web (hopefully that was obvious, just easier for me to find the web version 😀)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DST object referenced in LaTeX.
I think that if the flag is set to 'yes' this warning can be skipped. This means the user wants it this way. If it is set to 'no' (the default, especially if the optional field is not there) then the warning continues like it always has. Basically, a 'yes' gets rid of the warning? |
The default and previous behavior is "Yes". That means we're currently throwing the warning in the "Yes" case. We don't want to throw this warning if the user selects "No". Are you suggesting that we differentiate between whether the user allows this field to be defaulted to "Yes" or whether they explicitly enter a "Yes" on the object and then only throw the warning in the former case? That seems like a hassle to me. I guess I figure that since there's a documented input for the behavior now, we just don't need this anymore. |
My bad. I got the default mixed up. Sorry for the confusion. I think we're saying the same thing. To reiterate: If 'yes' (previous and default) keep the warning. Basically no change. If 'no' (new option) then warning is skipped. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, decided to test this using 5ZoneTDV. Extended the Schedule:File object with blank fields and then added the DST flag. It crashed. Why? Because Minutes per Item didn't have a default and came in as zero.
Did some IDD cleanup and tried again. Now it runs. Compared with DST = Yes and No. Identical results. Hmmmm. Duh, 5ZoneTDV doesn't have daylight savings. Well, ok, so these should be identical.
Added DST and compared again with schedule DST = Yes and No. Voila! Different source energy.
Pushing up idd changes and some changes to 5ZoneTDV to extend the object with all fields and No for DST ('cause that's probably correct for the TDV schedules). And added output variables for source energy 'cause that's of most interest. This shouldn't trigger any CI diffs (yah, sure it won't).
Will merge in the morning assuming CI comes back clean.
And this showed a 0.36% speedup. Whoop whoop!!
@bonnema I'm all for it personally. This spring forward thing is 🤬 . I always come back to this segment from John Oliver |
So, will EnergyPlus accept a DST period from Jan 1 - Dec 31? I suppose it should. Then the entire schedule should shift, or not, or ? And that will bring into question the timing of weather data if we're always on DST will it be recorded with ST timestamps? Head is starting to spin... |
😄 It would make everyone's life so much easier if the permanent situation
was ST (instead of DST)..like the rest of the world! (and same for SI
system...and maybe a bunch of other things but for now let's leave it at SI
system).
…On Tue, Mar 15, 2022 at 4:26 PM Michael J. Witte ***@***.***> wrote:
So, will EnergyPlus accept a DST period from Jan 1 - Dec 31? I suppose it
should. Then the entire schedule should shift, or not, or ? And that will
bring into question the timing of weather data if we're always on DST will
it be recorded with ST timestamps? Head is starting to spin...
—
Reply to this email directly, view it on GitHub
<#9251 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKYK2HSJ3B3AMYENUCVKRS3VAEE7ZANCNFSM5M4YJB4Q>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
That's a good question @mjwitte. Seems like it should be able to, but I think we'd need to try it to make sure. Ultimately, it's just the same as being on standard time with a different offset from UTC. Seems like this could be easily achieved by modifying the epw file to shift everything by an hour. I imagine that TMY3 would be updated to reflect that (TMY4?). |
But let's wait on all that until congress actually passes something. I'll believe this when I see it. |
Pull request overview
An optional field has been added to the IDD to indicate whether or not to shift the schedule forward an hour during daylight savings time. If the value is a "Yes", the schedule skips forward an hour in the CSV on the "spring forward" day and repeats an hour on the "fall back" day. If "No", the schedule is read and applied in standard time, without adjusting for daylight savings time. This indicator is defaulted to "Yes" if no input is provided.
NOTE: ENHANCEMENTS MUST FOLLOW A SUBMISSION PROCESS INCLUDING A FEATURE PROPOSAL AND DESIGN DOCUMENT PRIOR TO SUBMITTING CODE
Pull Request Author
Add to this list or remove from it as applicable. This is a simple templated set of guidelines.
If any diffs are expected, author must demonstrate they are justified using plots and descriptionsIf changes fix a defect, the fix should be demonstrated in plots and descriptionsIf any defect files are updated to a more recent version, upload new versions here or on DevSupportIf IDD requires transition, transition source, rules, ExpandObjects, and IDFs must be updated, and add IDDChange labelIf structural output changes, add to output rules file and add OutputChange labelReviewer
This will not be exhaustively relevant to every PR.