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

Fix the Thermal Comfort CEN 15251 Running Mean Temperature Calculation #8175

Merged

Conversation

airallergy
Copy link
Contributor

@airallergy airallergy commented Jul 26, 2020

Pull request overview

  1. fix the skipping line number in epw for the initialisation
    before: skip 9 lines; after: skip 8 lines

  2. 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

comparison

  • Reference

The running mean temperature equation comes from BS EN 15251:2007, a snippet is given below:
image

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

@airallergy airallergy marked this pull request as ready for review July 27, 2020 22:12
@Myoldmopar Myoldmopar added the Defect Includes code to repair a defect in EnergyPlus label Jul 28, 2020
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.

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.

src/EnergyPlus/ThermalComfort.cc Outdated Show resolved Hide resolved
src/EnergyPlus/ThermalComfort.cc Outdated Show resolved Hide resolved
src/EnergyPlus/ThermalComfort.cc Outdated Show resolved Hide resolved
src/EnergyPlus/ThermalComfort.cc Outdated Show resolved Hide resolved
src/EnergyPlus/ThermalComfort.cc Show resolved Hide resolved
epwFile.readLine();
}
jStartDay = DayOfYear - 1;
calcStartDay = jStartDay - 7;
if (calcStartDay > 0) {
calcStartHr = 24 * (calcStartDay - 1) + 1;
calcStartHr = 24 * calcStartDay + 1;
Copy link
Member

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?

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 am not sure about the original intent, but I think this could be one explanation.

Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Member

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.

tst/EnergyPlus/unit/ThermalComfort.unit.cc Outdated Show resolved Hide resolved
@mjwitte mjwitte added this to the EnergyPlus 9.4.0 milestone Aug 28, 2020
src/EnergyPlus/ThermalComfort.cc Outdated Show resolved Hide resolved
src/EnergyPlus/ThermalComfort.cc Show resolved Hide resolved
@Myoldmopar
Copy link
Member

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.

@nrel-bot-3
Copy link

@airallergy @lgentile it has been 28 days since this pull request was last updated.

4 similar comments
@nrel-bot-2b
Copy link

@airallergy @lgentile it has been 28 days since this pull request was last updated.

@nrel-bot-3
Copy link

@airallergy @lgentile it has been 28 days since this pull request was last updated.

@nrel-bot-3
Copy link

@airallergy @lgentile it has been 28 days since this pull request was last updated.

@nrel-bot-3
Copy link

@airallergy @lgentile it has been 28 days since this pull request was last updated.

@nrel-bot-3
Copy link

@airallergy @lgentile it has been 28 days since this pull request was last updated.

1 similar comment
@nrel-bot
Copy link

@airallergy @lgentile it has been 28 days since this pull request was last updated.

@airallergy
Copy link
Contributor Author

@mitchute done!

Copy link
Collaborator

@mitchute mitchute left a 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.

src/EnergyPlus/ThermalComfort.cc Outdated Show resolved Hide resolved
src/EnergyPlus/ThermalComfort.cc Show resolved Hide resolved
src/EnergyPlus/ThermalComfort.cc Outdated Show resolved Hide resolved
tst/EnergyPlus/unit/ThermalComfort.unit.cc Show resolved Hide resolved
src/EnergyPlus/ThermalComfort.cc Show resolved Hide resolved
@mitchute
Copy link
Collaborator

OK, I ran some tests and this looks ready. @airallergy it would be good if you could address this comment, quoted below:

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.

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.

@airallergy
Copy link
Contributor Author

@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.

@mitchute
Copy link
Collaborator

mitchute commented Sep 1, 2021

@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.

@Myoldmopar
Copy link
Member

It's probably because the PR list is too long and CI doesn't see it.

@mitchute
Copy link
Collaborator

mitchute commented Sep 1, 2021

OK, running tests locally.

@mitchute
Copy link
Collaborator

mitchute commented Sep 1, 2021

Hmm, I'm a little confused here. I ran full regressions locally and get the following results.

Screen Shot 2021-09-01 at 10 48 33 AM

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:

Screen Shot 2021-09-01 at 10 48 48 AM

Big diffs in the HVAC Rejected Heat?? How does the thermal comfort code affect that??

@mitchute
Copy link
Collaborator

mitchute commented Sep 2, 2021

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.

Screen Shot 2021-09-02 at 3 27 18 PM

However, when I run those files with diffs by themselves I don't see any diffs.

Anyone have thoughts here?

@rraustad
Copy link
Contributor

rraustad commented Sep 2, 2021

Are you using the same weather file used for the full test suite? See ...\testfiles\CMakeLists.txt

@mitchute
Copy link
Collaborator

mitchute commented Sep 2, 2021

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.

@airallergy
Copy link
Contributor Author

Why did one test seem to fail without running? Do I need to pull from develop once more?

@rraustad
Copy link
Contributor

rraustad commented Sep 7, 2021

@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.

@airallergy
Copy link
Contributor Author

@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?

@rraustad
Copy link
Contributor

rraustad commented Sep 7, 2021

Done.

@rraustad
Copy link
Contributor

rraustad commented Sep 7, 2021

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.

@airallergy
Copy link
Contributor Author

Sure, will do it later today.

for (i = 1; i <= 8; ++i) { // Headers
epwLine = epwFile.readLine().data;
}
WeatherManager::OpenEPlusWeatherFile(state, ErrorsFound, false);
Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

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.

Copy link
Contributor Author

@airallergy airallergy Sep 7, 2021

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.

Copy link
Member

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.

Copy link
Contributor Author

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.

@airallergy airallergy marked this pull request as draft September 7, 2021 19:29
@airallergy airallergy marked this pull request as ready for review September 7, 2021 21:41
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.

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) {
Copy link
Member

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:

  1. LOCATION
  2. DESIGN CONDITIONS
  3. TYPICAL/EXTREME PERIODS
  4. GROUND TEMPERATURES
  5. HOLIDAYS/DAYLIGHT SAVINGS
  6. COMMENTS 1
  7. COMMENTS 2
  8. DATA PERIODS

if (state.dataEnvrn->CurrentYearIsLeapYear) {
DaysInYear = 366;
} else {
DaysInYear = 365;
Copy link
Member

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;
Copy link
Member

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;
Copy link
Member

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;
Copy link
Member

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;
Copy link
Member

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.

@Myoldmopar
Copy link
Member

@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.

@Myoldmopar
Copy link
Member

Looking good. Going ahead and merging. Thanks all!

@Myoldmopar Myoldmopar merged commit eb5c6a1 into NREL:develop Sep 8, 2021
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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Zone Thermal Comfort CEN 15251 Adaptive Model Running Average Outdoor Air Temperature Error
10 participants