Addresses #5214, EpwFile getTimeSeries fails for leap year weather file w/no leap day

[joseph-robertson]

Pull request overview

• Fixes #5214

As far as I can tell, the Bad Date: year = 2009, month = Feb(2), day = 29. error is thrown for each of the following scenarios:

• AMY leap year missing 2/29 -- This will just be considered a TMY (file should contain Feb 29 for leap years...)
• TMY leap Feb w/out 2/29 -- This is what the issue wants to support
• TMY leap Feb with 2/29 -- getTimeSeries will still fail (the assumed 2009 year will be used, and so Feb 29 would never be supported...)

Possible solutions:

• [ ] optional isActualOverride bool supplied to EpwFile::getTimeSeries (demonstrated in this PR)
• [ ] increase the 1 day delta tolerance here so, e.g., Feb28 - Mar1 doesn't trigger
• [ ] specifically except the Feb28 - Mar1 1 day delta here for leap years
• [x] intercept loading of m_data to change xxxx-Feb-29 00:00:00 to xxxx-Mar-01 00:00:00 for TMY with leap Feb

Pull Request Author

• [ ] Model API Changes / Additions
• [ ] Any new or modified fields have been implemented in the EnergyPlus ForwardTranslator (and ReverseTranslator as appropriate)
• [ ] Model API methods are tested (in src/model/test)
• [ ] EnergyPlus ForwardTranslator Tests (in src/energyplus/Test)
• [ ] If a new object or method, added a test in NREL/OpenStudio-resources: Add Link
• [ ] If needed, added VersionTranslation rules for the objects (src/osversion/VersionTranslator.cpp)
• [ ] Verified that C# bindings built fine on Windows, partial classes used as needed, etc.
• [ ] All new and existing tests passes
• [ ] If methods have been deprecated, update rest of code to use the new methods

Labels:

• [ ] If change to an IDD file, add the label IDDChange
• [ ] If breaking existing API, add the label APIChange
• [ ] If deemed ready, add label Pull Request - Ready for CI so that CI builds your PR

Review Checklist

This will not be exhaustively relevant to every PR.

• [ ] Perform a Code Review on GitHub
• [ ] Code Style, strip trailing whitespace, etc.
• [ ] All related changes have been implemented: model changes, model tests, FT changes, FT tests, VersionTranslation, OS App
• [ ] Labeling is ok
• [ ] 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

[joseph-robertson]

After a bit of digging, it appears that realYear (and therefore epw.isActual) gets set to false here since we have a delta greater than 1 day in the epw file. I'm assuming this works as intended for TMY where months jump years.

Therefore we fall into this block instead of this one.

If epw.isActual were set to true, is the issue resolved here? If so, perhaps we could provide some type of override on isActual (either in the epw ctor, or as a setter somewhere)?

[joseph-robertson]

Ah ha, here's the core issue. For all 3 of the above scenarios, m_data has dateTimes that look like:

2012-Feb-28 20:00:00
2012-Feb-28 21:00:00
2012-Feb-28 22:00:00
2012-Feb-28 23:00:00
2012-Feb-29 00:00:00 => Bad Date: year = 2009, month = Feb(2), day = 29.
2012-Mar-01 01:00:00
2012-Mar-01 02:00:00
2012-Mar-01 03:00:00
2012-Mar-01 04:00:00

This is the line that fails. The assumedYear in the Data ctor here is 2009, and so fails on the line above.

Why doesn't the EpwDataPoint have a dateTime of 2012-Mar-01 00:00:00 instead of 2012-Feb-29 00:00:00?

Answer:

pt = OpenStudio::EpwDataPoint.fromEpwStrings(2012, 2, 28, 24, 0, ["foo"] * 35)
pt.dateTime => 2012-Feb-29 00:00:00

[ci-commercialbuildings]

CI Results for 17d344f9327a96d078cc0a19ac0ac63ecc9f1c2c:

• Ubuntu 20.04:

  • OpenStudio-3.8.0+17d344f932-Ubuntu-20.04-x86_64.deb
  • OpenStudio-3.8.0+17d344f932-Ubuntu-20.04-x86_64.tar.gz
  • perf_test/results.html

• Ubuntu 22.04:

  • OpenStudio-3.8.0+17d344f932-Ubuntu-22.04-x86_64.deb
  • OpenStudio-3.8.0+17d344f932-Ubuntu-22.04-x86_64.tar.gz

• Darwin:

  • OpenStudio-3.8.0+17d344f932-Darwin-x86_64.dmg
  • OpenStudio-3.8.0+17d344f932-Darwin-x86_64.tar.gz

• Windows:

  • OpenStudio-3.8.0+17d344f932-Windows.exe
  • OpenStudio-3.8.0+17d344f932-Windows.tar.gz

• Code Coverage:

[ckirney]

The fix looks good. I tried it on Windows with a couple of different weather files that had the issue before and everything seems to work. Thanks for resolving this.