-
Notifications
You must be signed in to change notification settings - Fork 389
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
Fix the Thermal Comfort CEN 15251 Running Mean Temperature Calculation #8175
Fix the Thermal Comfort CEN 15251 Running Mean Temperature Calculation #8175
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.
I'd like the global variable thing taken back out and instead add an argument to the function that returns the variable value. In general, we are trying to reduce the global state of the program these days.
I think your calculation changes in the function are reasonable, but I'll have to think through the calcStartDay thing to make sure I understand the original intent and effect of the change.
Finally it would be good if you could comment on what you are using as a validation in the unit tests. The unit test is straightforward enough, I just want to make sure the function is producing what you would expect, hopefully from a third party tool/resource.
Thanks for this contribution, I think with just a bit of discussion and tweaks we can get this in.
epwFile.readLine(); | ||
} | ||
jStartDay = DayOfYear - 1; | ||
calcStartDay = jStartDay - 7; | ||
if (calcStartDay > 0) { | ||
calcStartHr = 24 * (calcStartDay - 1) + 1; | ||
calcStartHr = 24 * calcStartDay + 1; |
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 I guess the - 1
wasn't needed because we already offset DayOfYear by 1 a couple lines up?
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 am not sure about the original intent, but I think this could be one explanation.
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.
24 * (calcStartDay - 1)
is a conversion to hours. Why exactly was this changed when calcStartDay wasn't changed?
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.
Because it was wrong by offsetting one excessive day here. This was also an issue with the ASHRAE comfort calculation function above, which was fixed in #6474.
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, this code is wrapping the epw to 24*calcStartDay as the number of hours last year and +1 is the first hour of this year. If you pulled develop this would not show as a diff. Never mind that right now.
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 whole thing appears to be built around an assumption that the weather file has hourly data, which makes me feel funny. This PR isn't changing it, just handling this part better, and that is acceptable here.
I'd like to see this go in, but I think it's too much to get done by our freeze which is....soon. I'm changing the milestone for the next release, but if you can bring this up to date with develop and address the review comments in very short order, it could still go in. |
@airallergy @lgentile it has been 28 days since this pull request was last updated. |
4 similar comments
@airallergy @lgentile it has been 28 days since this pull request was last updated. |
@airallergy @lgentile it has been 28 days since this pull request was last updated. |
@airallergy @lgentile it has been 28 days since this pull request was last updated. |
@airallergy @lgentile it has been 28 days since this pull request was last updated. |
@airallergy @lgentile it has been 28 days since this pull request was last updated. |
1 similar comment
@airallergy @lgentile it has been 28 days since this pull request was last updated. |
@mitchute 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.
There are a few changes requested here, but nothing major. I'll do some testing before this merges.
OK, I ran some tests and this looks ready. @airallergy it would be good if you could address this comment, quoted below:
Also, pull in develop one more time while you're at it. I'm not sure why it hasn't picked this one up yet but we should pull it up one more time anyway. |
@mitchute, I have addressed this comment before, please check the pr overview which includes a screenshot of detailed calculation using excel, and a diagram of existing and expected annual results. Kindly let me know if you think any further information is required. Will do another pull shortly. |
@Myoldmopar any idea why CI isn't picking this up? I think it's ready if we can get a CI run to confirm its status. |
It's probably because the PR list is too long and CI doesn't see it. |
OK, running tests locally. |
Hmm, I'm a little confused here. I ran full regressions locally and get the following results. The unsuccessful runs are OK, and the run with big math diffs is expected and OK. However, the runs with big table diffs are showing up with the following: Big diffs in the HVAC Rejected Heat?? How does the thermal comfort code affect that?? |
OK, so I pulled develop in one more time, but I have some strange results. I ran the full test suite again and am getting similar, althought not identical results. Some of the files with table diffs match up, but not all of them. Nor do the magnatude of the diffs. However, when I run those files with diffs by themselves I don't see any diffs. Anyone have thoughts here? |
Are you using the same weather file used for the full test suite? See ...\testfiles\CMakeLists.txt |
I’m using the regression tool in both instances. Except one time I’m running the full suite and the next time I’m just running the ones with diffs. No changes otherwise. |
Why did one test seem to fail without running? Do I need to pull from develop once more? |
@airallergy that happened to me last week. Click on the Details link. At the top of the next page, click the red button Delete results and force rebuild and then click the accept? button. That way you don't run all the other CI servers. |
@rraustad , thanks for point this out, but since I don’t have the writing access to that repo, I have to do a pr for deleting it. Would you minding doing it for me? |
Done. |
There are some unexplained diffs in this branch that I assume are due to this branch in the forked repo being behind NREL's develop. Maybe the best thing to do here is to pull the latest NREL develop into this branch and push it back up for fresh CI results. |
Sure, will do it later today. |
src/EnergyPlus/ThermalComfort.cc
Outdated
for (i = 1; i <= 8; ++i) { // Headers | ||
epwLine = epwFile.readLine().data; | ||
} | ||
WeatherManager::OpenEPlusWeatherFile(state, ErrorsFound, 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.
Is this change necessary? It feels like it could have side effects, and is muddying up the changes here. Maybe I'm misunderstanding why this is necessary.
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.
Do you refer to the change in the ASHRAE function while this pr is mainly about CEN15251? Or do you refer to the use of OpenEPlusWeatherFile
in both functions?
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'm wondering why you needed to change from
auto epwFile = state.files.inputWeatherFilePath.open(state, "CalcThermalComfortAdaptiveASH55");
to
WeatherManager::OpenEPlusWeatherFile(state, ErrorsFound, false);
I'm not actually saying the previous is correct, but I am wondering if that actually affects your bug fix here. I'm trying to minimize the number of lines that your PR is changing to make sure we can get it reviewed and merged. If this is an important change then it would be good to know why. If it's not an important change, then it could potentially just make it tougher to review if it causes changes in results.
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, I understand your point and totally agree with you, I was just trying to figure out which part should be altered. So let me put it this way.
These few lines involve skipping the epw header, and I currently changed that for both CEN and ASH. Changing of that for ASH to OpenEPlusWeatherFile
is not essential for the sake of this pr, there was no error as to these specific lines (apart from some variable name changes in develop, but that was handled by pulling from upstream). I just did it to keep some consistency, as I was recommended to use OpenEPlusWeatherFile
in CEN instead of hard coding the skipping.
In terms of OpenEPlusWeatherFile
, I didn't find any of its usage outside WeatherManager.cc
, and there are hard-coded skipping instead. Maybe you want to do a standalone pr for that.
Kindly let me know what you would like me to do here, I am ok with either way.
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.
My intent really is to just minimize the changes in this PR so that we can get this in for you. I hate that this has taken so much effort and the amount of effort in reviewing goes up as the number of lines go up. (Not always, but I think you get my point.)
I would cut this down as far as possible just to the bare minimum set of changes so that we can look at the results changes and feel comfortable with them changing.
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.
Now no touching the ASH function, no use of OpenEPlusWeatherFile
, diffs should be much cleaner now. waiting to see ci runs.
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'm happy with this as long as CI comes back clean (I believe we'll still have 1 diff expected).
auto epwFile = state.files.inputWeatherFilePath.open(state, "CalcThermalComfortAdaptiveCEN15251"); | ||
for (i = 1; i <= 9; ++i) { // Headers | ||
for (i = 1; i <= numHeaderRowsInEpw; ++i) { |
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 went from 9 to 8 in this PR. Makes sense with 8 header rows:
- LOCATION
- DESIGN CONDITIONS
- TYPICAL/EXTREME PERIODS
- GROUND TEMPERATURES
- HOLIDAYS/DAYLIGHT SAVINGS
- COMMENTS 1
- COMMENTS 2
- DATA PERIODS
if (state.dataEnvrn->CurrentYearIsLeapYear) { | ||
DaysInYear = 366; | ||
} else { | ||
DaysInYear = 365; |
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 still a good change.
epwFile.readLine(); | ||
} | ||
jStartDay = DayOfYear - 1; | ||
calcStartDay = jStartDay - 7; | ||
if (calcStartDay > 0) { | ||
calcStartHr = 24 * (calcStartDay - 1) + 1; | ||
calcStartHr = 24 * calcStartDay + 1; |
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 whole thing appears to be built around an assumption that the weather file has hourly data, which makes me feel funny. This PR isn't changing it, just handling this part better, and that is acceptable here.
@@ -3080,7 +3089,7 @@ namespace ThermalComfort { | |||
if (state.dataGlobal->BeginDayFlag && !state.dataThermalComforts->firstDaySet) { | |||
// Update the running average, reset the daily avg | |||
state.dataThermalComforts->runningAverageCEN = | |||
0.2 * state.dataThermalComforts->runningAverageCEN + 0.8 * state.dataThermalComforts->avgDryBulbCEN; | |||
alpha * state.dataThermalComforts->runningAverageCEN + (1.0 - alpha) * state.dataThermalComforts->avgDryBulbCEN; | |||
state.dataThermalComforts->avgDryBulbCEN = 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.
Thanks for adding the reference information in the PR, this should be totally acceptable.
@@ -3031,9 +3040,9 @@ namespace ThermalComfort { | |||
} | |||
} else { // Do special things for wrapping the epw | |||
calcEndDay = jStartDay; | |||
calcStartDay += 365; | |||
calcStartDay += DaysInYear; |
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.
Using the new dynamically determined days in year is great.
calcEndHr = 24 * calcEndDay; | ||
calcStartHr = 24 * (calcStartDay - 1) + 1; | ||
calcStartHr = 24 * calcStartDay + 1; |
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'm willing to accept this as the corrected start by shifting a day.
@mitchute you are still showing changes requested. I believe that's just out of date at this point. I ran full tests and regressions locally and this is all in good shape to go in, just the one diff file. CI is looking super happy so far. I'm inclined to merge but I will wait a little while. May merge before sleepy time. Let me know if anyone is waiting on anything else here. |
Looking good. Going ahead and merging. Thanks all! |
Pull request overview
Fixes Zone Thermal Comfort CEN 15251 Adaptive Model Running Average Outdoor Air Temperature Error #8174: to fix bugs in the first-day and following-up calculation of the running mean temperature for the CEN 15251 adaptive model stated in the issue.
Calculation validation
Note: T_od is calculated directly from the weather file, which is derived from the ep database.
Major changes comparison
fix the skipping line number in epw for the initialisation
before: skip 9 lines; after: skip 8 lines
fix the wrong formula for the rest of days
before: T_rm = 0.2 * T_rm-1 + 0.8 * T_od-1; after: T_rm = 0.8 * T_rm-1 + 0.2 * T_od-1
The running mean temperature equation comes from BS EN 15251:2007, a snippet is given below:
Pull Request Author
Add to this list or remove from it as applicable. This is a simple templated set of guidelines.
Reviewer
This will not be exhaustively relevant to every PR.