Skip to content
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

Add new people schedule columns to EIO/initialization summary to address #10314 #10437

Merged
merged 25 commits into from
May 3, 2024

Conversation

JasonGlazer
Copy link
Contributor

@JasonGlazer JasonGlazer commented Mar 14, 2024

Pull request overview

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.

  • Title of PR should be user-synopsis style (clearly understandable in a standalone changelog context)
  • Label the PR with at least one of: Defect, Refactoring, NewFeature, Performance, and/or DoNoPublish
  • Pull requests that impact EnergyPlus code must also include unit tests to cover enhancement or defect repair
  • Author should provide a "walkthrough" of relevant code changes using a GitHub code review comment process
  • If any diffs are expected, author must demonstrate they are justified using plots and descriptions
  • If changes fix a defect, the fix should be demonstrated in plots and descriptions
  • If any defect files are updated to a more recent version, upload new versions here or on DevSupport
  • If IDD requires transition, transition source, rules, ExpandObjects, and IDFs must be updated, and add IDDChange label
  • If structural output changes, add to output rules file and add OutputChange label
  • If adding/removing any LaTeX docs or figures, update that document's CMakeLists file dependencies

Reviewer

This will not be exhaustively relevant to every PR.

  • Perform a Code Review on GitHub
  • If branch is behind develop, merge develop and build locally to check for side effects of the merge
  • If defect, verify by running develop branch and reproducing defect, then running PR and reproducing fix
  • If feature, test running new feature, try creative ways to break it
  • CI status: all green or justified
  • Check that performance is not impacted (CI Linux results include performance check)
  • Run Unit Test(s) locally
  • Check any new function arguments for performance impacts
  • Verify IDF naming conventions and styles, memos and notes and defaults
  • If new idf included, locally check the err file and other outputs

@JasonGlazer JasonGlazer added the Defect Includes code to repair a defect in EnergyPlus label Mar 14, 2024
@JasonGlazer JasonGlazer added this to the EnergyPlus 24.2 milestone Mar 14, 2024
@JasonGlazer JasonGlazer self-assigned this Mar 14, 2024
@JasonGlazer JasonGlazer marked this pull request as ready for review March 14, 2024 20:25
@JasonGlazer
Copy link
Contributor Author

This is impacting every EIO file that has lighting or internal equipment, in other words, all of them. But It is simply renaming two columns and adding six new columns to the internal load reports so that is expected. I spot checked a bunch of files and they are doing as expected and nothing more.

The 2.7% decrease in speed does not make sense to me. @Myoldmopar is that possibly due to something else going on? This only impacts the routine that populates the EIO file from internal games.

Based on this, I think this is ready to review. Since this is changing output it is on track for 24.2 so it is not critical this week.

@JasonGlazer
Copy link
Contributor Author

The documentation updates should be done soon.

@JasonGlazer JasonGlazer added the OutputChange Code changes output in such a way that it cannot be merged after IO freeze label Mar 18, 2024
break;
case DayTypeGroup::WeekEndHoliday:
dayTypeFilter = {true, false, false, false, false, false, true, true, false, false, false, false};
break;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there something else needed here to include holidays?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first true is Sunday, then five falses are Monday to Friday, then true for Saturday and then true for Holiday.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, my comment shows Sunday twice. I should probably verify which one is really Sunday :-)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The other thing I noticed is that this dayTypeFilter array is a constexpr for each day type. It would be nice to set these up at compile time and somehow use the correct array in the loop below.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I fixed the comment based on the enumeration:

enum class DayType
{
Invalid = -1,
Dummy = 0,
Sunday = 1,
Monday,
Tuesday,
Wednesday,
Thursday,
Friday,
Saturday,
Holiday,
SummerDesignDay,
WinterDesignDay,
CustomDay1,
CustomDay2,
Num
};

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And changed to using std::array so I can make these constexpr.

@rraustad
Copy link
Contributor

rraustad commented Mar 19, 2024

This does look like a change only to output reporting yet there are other diffs. For example,

FCfactor data is not reported, which looks correct for 5ZoneAirCooledWithSpaceHeatBalance and 5ZoneAirCooledWithSpaces, but what change caused that diff?

 ! ,Jan{C},Feb{C},Mar{C},Apr{C},May{C},Jun{C},Jul{C},Aug{C},Sep{C},Oct{C},Nov{C},Dec{C}
  Site:GroundTemperature:BuildingSurface,  20.03,  20.03,  20.13,  20.30,  20.43,  20.52,  20.62,  20.77,  20.78,  20.55,  20.44,  20.20
-! ,Jan{C},Feb{C},Mar{C},Apr{C},May{C},Jun{C},Jul{C},Aug{C},Sep{C},Oct{C},Nov{C},Dec{C}
- Site:GroundTemperature:FCfactorMethod,  -1.89,  -3.06,  -0.99,   2.23,  10.68,  17.20,  21.60,  22.94,  20.66,  15.60,   8.83,   2.56
 ! ,Jan{C},Feb{C},Mar{C},Apr{C},May{C},Jun{C},Jul{C},Aug{C},Sep{C},Oct{C},Nov{C},Dec{C}
  Site:GroundTemperature:Shallow,  13.00,  13.00,  13.00,  13.00,  13.00,  13.00,  13.00,  13.00,  13.00,  13.00,  13.00,  13.00

and the actual input file location object info is reported now, not the weather file used (../testfiles/CMakeLists.txt). Maybe because this branch is behind develop? I would think if we report the input file location, then we should also report the weather file used?

-Site:Location,Chicago Ohare Intl Ap IL USA TMY3 WMO#=725300,41.98,-87.92,-6.00,201.00,98934,1.1759
+Site:Location,CHICAGO_IL_USA TMY2-94846,41.78,-87.75,-6.00,190.00,99063,1.1774

and a small diff radiant to convective decay curve data (0.30 vs 0.31) which may be the reason for the zone and component sizing diffs.

-Radiant to Convective Decay Curves for Cooling,SPACE2-1,C2-1, 0.275, 0.073, 0.062, 0.051, 0.044, 0.039, 0.036, 0.033, 0.030, 0.028, 0.026, 0.025, 0.022, 0.022, 0.019, 0.018, 0.017, 0.016, 0.015, 0.014, 0.013, 0.013, 0.012, 0.011, 0.011, 0.010, 0.009, 0.009, 0.008, 0.008, 0.007, 0.007, 0.007, 0.006, 0.006, 0.006
+Radiant to Convective Decay Curves for Cooling,SPACE2-1,C2-1, 0.275, 0.073, 0.062, 0.051, 0.044, 0.039, 0.036, 0.033, 0.031, 0.028, 0.026, 0.025, 0.022, 0.022, 0.019, 0.018, 0.017, 0.016, 0.015, 0.014, 0.013, 0.013, 0.012, 0.011, 0.011, 0.010, 0.009, 0.009, 0.008, 0.008, 0.007, 0.007, 0.007, 0.006, 0.006, 0.006

@JasonGlazer
Copy link
Contributor Author

@rraustad I'm going to remerge and try it again since I only added documentation changes last time and time before that I was only showing the EIO diffs.

if (dayTypeFilter[jType - 1]) {
auto &daySch = state.dataScheduleMgr->DaySchedule;
MinValue = min(MinValue, minval(daySch(weekSch.DaySchedulePointer(jType)).TSValue));
MaxValue = max(MaxValue, maxval(daySch(weekSch.DaySchedulePointer(jType)).TSValue));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And here:

auto &daySch = state.dataScheduleMgr->DaySchedule(weekSch.DaySchedulePointer(jType));

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it, thanks

@rraustad
Copy link
Contributor

Noticing an issue when the day type (e.g., SummerDesignDay vs WinterDesignDay) is called out in different "For" groups. Using 5ZoneAirCooledWithSpaceHeatBalance.idf.

Schedule:Compact,
  EQUIP-1,                 !- Name
  Fraction,                !- Schedule Type Limits Name
  Through: 12/31,          !- Field 1
  For: WeekDays SummerDesignDay CustomDay1 CustomDay2, !- Field 2
  Until: 8:00,0.02,        !- Field 3
  Until: 9:00,0.4,         !- Field 5
  Until: 14:00,0.9,        !- Field 7
  Until: 15:00,0.8,        !- Field 9
  Until: 16:00,0.7,        !- Field 11
  Until: 18:00,0.5,        !- Field 13
  Until: 20:00,0.3,        !- Field 15
  Until: 24:00,0.02,       !- Field 17
  For: Weekends WinterDesignDay Holiday, !- Field 19
  Until: 24:00,0.2;        !- Field 20

The data is correct (i.e., the minimum for all design days is a 0.02 multiplier), however, I am wondering if internal gains on a summer design day vs winter design day are important enough for a dedicated column? Here the minimum for a winter design day should match Weekends/Holidays column using a 0.2 multiplier.

image

Develop results as a comparison for reviewer:

image

@rraustad
Copy link
Contributor

And wondering if CustomDay1 and 2 need their own columns?

@rraustad
Copy link
Contributor

I pulled develop and the unit tests run successfully.

@JasonGlazer
Copy link
Contributor Author

And wondering if CustomDay1 and 2 need their own columns?

I considered it but decided that they were not used much (at least as far as I could tell).

@JasonGlazer
Copy link
Contributor Author

JasonGlazer commented Apr 9, 2024

internal gains on a summer design day vs winter design day are important enough for a dedicated column

Interesting idea so you are suggesting separate min and max for summer design day and for winter design day. Another two columns. I can do that if you think it would be useful. I would guess for many modelers the design day values for these are constant so the min for the winter and the max for the summer will probably show the values they care about. But if you think it will be useful, I can add them.

@rraustad
Copy link
Contributor

rraustad commented Apr 9, 2024

@JasonGlazer I'm not sure if it is useful or not. @mjwitte ?

ShowFatalError(state, "getScheduleMinMaxByDayType called with ScheduleIndex out of range");
} else if (ScheduleIndex > 0) {
std::array<bool, maxDayTypes> dayTypeFilter;
std::fill(dayTypeFilter.begin(), dayTypeFilter.end(), false);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this initialization (4517) really necessary if you are going to fill this array anyway with one of the below? Also, ScheduleIndex < 1 (line 4513) is after testing for ScheduleIndex == -1 (4507) and == 0 (4510). Is it even possible for a schedule index to be less than -1? if not, then ScheduleIndex < 1 at line 4515 is not needed (not sure that fatal is needed either but it's safe). Ideally, if the fatal were not there then if (ScheduleIndex > 0) could be first in the IF ladder since it is most common. This is probably way too picky for something that has limited use for the new table columns.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rraustad thanks for the careful review. I think I addressed your suggestions with the latest comit.

@JasonGlazer
Copy link
Contributor Author

I looked through all the warnings and the EIOs changed as expected. I spot checked a bunch. This is ready for review.

@JasonGlazer JasonGlazer requested a review from rraustad April 15, 2024 11:33
Copy link
Contributor

@rraustad rraustad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good now.

"Convected,Sensible Fraction Calculation,Activity level,ASHRAE 55 Warnings,Carbon Dioxide Generation Rate,"
"Minimum Number of People for All Day Types,Maximum Number of People for All Day Types,"
"Minimum Number of People for Weekdays, Maximum Number of People for Weekdays, "
"Minimum Number of People for Weekends/Holidays, Maximum Number of People for Weekends /Holidays,"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The extra space in the maximum column (Weekends /Holidays) actually has a good result on the column heading.

image

false, false, false, false, false, false, false, false, false, true, false, false};
constexpr std::array<bool, maxDayTypes> dayTypeFilterNone = {
false, false, false, false, false, false, false, false, false, false, false, false};
if (ScheduleIndex > 0 && ScheduleIndex <= state.dataScheduleMgr->NumSchedules) {
Copy link
Contributor

@rraustad rraustad Apr 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am trying to convince myself that it is even possible for ScheduleIndex > NumSchedules. Not all functions in ScheduleManager use this check (i.e., ScheduleIndex <= NumSchedules). The only way to get an index is to call GetScheduleIndex, which uses FindItemInList and will either return a valid index or 0. I'm not convinced yet so nothing to do here. While investigating this I noticed in GetScheduleIndex that WeekSchedule(Schedule().WeekSchedulePointer()).Used and WeekSchedule(Schedule().WeekSchedulePointer()).DaySchedulePointer().Used are set but never used anywhere.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Used variables are never used. Alanis would be proud of that irony.

// store for the next call of the same schedule
curSch.MaxByDayType[curDayTypeGroup] = MaxValue;
curSch.MinByDayType[curDayTypeGroup] = MinValue;
curSch.MaxMinByDayTypeSet[curDayTypeGroup] = true;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is another loop over people schedules in DetermineSystemPopulationDiversity. Not sure if this could help there or if when checking those people schedules these 3 values could be set to save even more simulation time.

@rraustad
Copy link
Contributor

The new design day columns also highlight what is happening on the design days. That was a good addition.

image


People Internal Gains,~ SPACE1-1 PEOPLE 1, OCCUPY-1, SPACE1-1, 99.16, 11.0, 11.0, 0.111, 9.015, 0.300, 0.700, AutoCalculate, ACTSCHD, No, 3.8200E-008, 0, 11
People Internal Gains Nominal, SPACE1-1 PEOPLE 1, OCCUPY-1, SPACE1-1, 90.00, 10.0, 10.0, 0.111, 9.009, 0.300, 0.700, 0.550, ACTSCHD, No, 3.8200E-008, 0.0, 10.0, 0.8, 4.0, 0.6, 2.5, 9.5, 10.0, 0.0, 0.5,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Noticed here that for all the internal gain tables the word Nominal was added to the table title. That is important enough to note in OutputChanges.

image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correction. The word "Nominal" is added to the eio title and was already included in the html using develop. So nothing to do here.

This numeric field is the calculated maximum amount of lighting in Watts based on the calculated lighting level (above) * the maximum value (annual) for the lights schedule. It may be useful in diagnosing errors that occur during simulation.
\subsubsection{Field: Minimum Lighting Level for Weekdays \{W\}}\label{field-minimum-lighting-level-for-weekdays-w}

This numeric field is the calculated minimum amount of lighting in Watts based on the calculated lighting level (above) * the minimum value for the lights schedule for weekday day types (Monday through Friday).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Noting that the wording from here forward is different from the description of people.

based on the number of people field

based on the calculated lighting level (above)


std::tie(schMin, schMax) = getScheduleMinMaxByDayType(*state, index, DayTypeGroup::WinterDesignDay);
EXPECT_EQ(0.16, schMin);
EXPECT_EQ(0.25, schMax);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It took me a minute to see the 2 WinterDesignDay in the HIGHLOW02 schedule. Same for other schedule types. Good unit test.

@rraustad
Copy link
Contributor

Pulled develop and unit tests run to completion.

@rraustad
Copy link
Contributor

I think because there was [decent_ci_skip] in the last commit there are no results to review.

@mjwitte
Copy link
Contributor

mjwitte commented Apr 15, 2024

I think because there was [decent_ci_skip] in the last commit there are no results to review.

There are results under the previous commit.
image

b912be3#comments

@JasonGlazer
Copy link
Contributor Author

JasonGlazer commented Apr 15, 2024

I think because there was [decent_ci_skip] in the last commit there are no results to review.

There are results under the previous commit.

Sorry, I didn't realize that adding [decent_ci_skip] would make accessing those previous CI results more difficult.

@rraustad
Copy link
Contributor

Yes, the only diffs are shown in the eio file for internal gains information. For 1ZoneDataCenterCRAC_wApproachTemp the schedule is always 1 so the new data for min/max internal gains for all day types is the same as the peak value of 50000 W.

Schedule:Constant,Data Center Operation Schedule,Any Number,1.0;

-! ,Name,Schedule Name,Zone Name,Zone Floor Area {m2},# Zone Occupants,Equipment Level {W},Equipment/Floor Area {W/m2},Equipment per person {W/person},Fraction Convected,CPU End-Use SubCategory,Fan End-Use SubCategory,UPS End-Use SubCategory,Nominal Minimum Equipment Level {W},Nominal Maximum Equipment Level {W}, Design Air Volume Flow Rate {m3/s}
- ElectricEquipment:ITE:AirCooled Internal Gains Nominal, DATA CENTER SERVERS,DATA CENTER OPERATION SCHEDULE,MAIN ZONE,232.26,0.0,50000.000,215.278,1.0,ITE-CPU,ITE-Fans,ITE-UPS,5000.000,50000.000,5.0000000000
+! ,Name,Schedule Name,Zone Name,Zone Floor Area {m2},# Zone Occupants,Equipment Level {W},Equipment/Floor Area {W/m2},Equipment per person {W/person},Fraction Convected,CPU End-Use SubCategory,Fan End-Use SubCategory,UPS End-Use SubCategory,Minimum Equipment Level for All Day Types {W},Maximum Equipment Level for All Day Types {W},Minimum Equipment Level for Weekdays {W}, Maximum Equipment Level for Weekdays {W},Minimum Equipment Level for Weekends/Holidays {W}, Maximum Equipment Level for Weekends /Holidays {W},Minimum Equipment Level for Summer Design Days {W}, Maximum Equipment Level for Summer Design Days {W},Minimum Equipment Level for Winter Design Days {W}, Maximum Equipment Level for Winter Design Days {W},Design Air Volume Flow Rate {m3/s}
+ ElectricEquipment:ITE:AirCooled Internal Gains Nominal, DATA CENTER SERVERS,DATA CENTER OPERATION SCHEDULE,MAIN ZONE,232.26,0.0,50000.000,215.278,N/A,1.0,ITE-CPU,ITE-Fans,ITE-UPS,5000.000,50000.000,50000.000,50000.000,50000.000,50000.000,50000.000,50000.000,50000.000,50000.000,5.0000000000

@rraustad
Copy link
Contributor

@JasonGlazer are there any other changes planned? @Myoldmopar this is ready to go if no other changes planned.

@JasonGlazer
Copy link
Contributor Author

@JasonGlazer are there any other changes planned? @Myoldmopar this is ready to go if no other changes planned.

@rraustad thanks for the careful review. I have no other changes planned so this is ready to go.

@Myoldmopar Myoldmopar added the HighComplexityApproved Used for subcontractor defect complexity requests label Apr 24, 2024
Comment on lines 4535 to 4540
for (int jType = 1; jType <= maxDayTypes; ++jType) {
if (dayTypeFilter[jType - 1]) {
auto &daySch = state.dataScheduleMgr->DaySchedule(weekSch.DaySchedulePointer(jType));
MinValue = min(MinValue, minval(daySch.TSValue));
MaxValue = max(MaxValue, maxval(daySch.TSValue));
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than cycle through the entire schedule for every daytype group, why not cycle through once and store the max/min for each day type first? Then cycle through those to sort into the DayTypeGroups.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mjwitte I did some optimization of this loop that should greatly improve it's performance although it is not exactly using the approach you suggested.

@JasonGlazer
Copy link
Contributor Author

This is running slightly faster than develop now!

@JasonGlazer
Copy link
Contributor Author

All the warnings are EIO diffs. I spot checked them again and saw nothing that we weren't expecting. I think this is ready for a final review and (hopefully) merge.

@Myoldmopar Myoldmopar self-assigned this Apr 30, 2024
Copy link
Member

@Myoldmopar Myoldmopar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No problem here.

false, false, false, false, false, false, false, false, false, true, false, false};
constexpr std::array<bool, maxDayTypes> dayTypeFilterNone = {
false, false, false, false, false, false, false, false, false, false, false, false};
if (ScheduleIndex > 0 && ScheduleIndex <= state.dataScheduleMgr->NumSchedules) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Used variables are never used. Alanis would be proud of that irony.

@@ -69,6 +69,7 @@ struct EnergyPlusData;
namespace ScheduleManager {

constexpr int ScheduleAlwaysOn = -1;
constexpr int ScheduleAlwaysOff = 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Much better than a magic number used everywhere, nice.

std::array<bool, static_cast<int>(DayType::Num)> MaxMinByDayTypeSet{
false}; // minimum and maximum values by daytype have been stored for this schedule
std::array<Real64, static_cast<int>(DayType::Num)> MinByDayType{0.0}; // minimum values by daytype for this schedule
std::array<Real64, static_cast<int>(DayType::Num)> MaxByDayType{0.0}; // maximum values by daytype for this schedule
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Multiple arrays allocated to the same size hints that they may be nicer as a single struct. Not a big deal since there are just 3 arrays, but if it grew to more, it might be worthwhile.

@Myoldmopar
Copy link
Member

EIO diffs as expected, but builds and tests happily locally. I think this is ready to go, I'm going to merge. Thanks @JasonGlazer !

@Myoldmopar Myoldmopar merged commit 54ea3ea into develop May 3, 2024
15 checks passed
@Myoldmopar Myoldmopar deleted the Fix10314-AddingScheduleColumns branch May 3, 2024 14:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Defect Includes code to repair a defect in EnergyPlus HighComplexityApproved Used for subcontractor defect complexity requests OutputChange Code changes output in such a way that it cannot be merged after IO freeze
Projects
None yet
10 participants