-
Notifications
You must be signed in to change notification settings - Fork 394
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 #10399 - Long elapsed times are not recorded correctly #10529
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.
Yeah this is nice. I'll do a quick build and check CI, but it's good here.
@@ -602,6 +602,8 @@ set(SRC | |||
TARCOGParams.hh | |||
TarcogShading.cc | |||
TarcogShading.hh | |||
Timer.cc | |||
Timer.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.
Hey I've seen that before!
https://github.com/NREL/EnergyPlusArchive/blob/master/SourceCode/Timer.h
t.m_start = | ||
Timer::ClockType::now() - (std::chrono::hours(2) + std::chrono::minutes(25) + std::chrono::seconds(51) + std::chrono::milliseconds(341)); | ||
t.tock(); | ||
EXPECT_EQ("02hr 25min 51.34sec", t.formatAsHourMinSecs()); |
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.
Hmmm... This feels... Probably fine...
Confirmed everything is 💯 here, merging. Thanks @jmarrec |
std::string Timer::formatAsHourMinSecs() const | ||
{ | ||
// We're working with ms as base. | ||
// TODO: do we want to report elapsed time of 25 hours as 1 day 1hr 0min 0sec or 25hr 0min 0sec? |
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.
@Myoldmopar forgot to flag this
Do we want 1 days 1 hr xxx or 2hr
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 do not care... Possibly 1 day 1 hr ?? I think either is fine though. This would only matter in a corner case where (runtime is **enormously** long) .and. (the user cant handle a 25 hour time stamp)
which should round down to zero percent of the EnergyPlus use cases. Anyway, whatever is happening right now is fine.
// We're working with ms as base. | ||
// TODO: do we want to report elapsed time of 25 hours as 1 day 1hr 0min 0sec or 25hr 0min 0sec? | ||
// constexpr auto num_ms_in_day = 1000 * 3600 * 24; | ||
// if (duration().count() > num_ms_in_day) { | ||
// return fmt::format("{:.2%j days %Hhr %Mmin %Ssec}\n", duration()); | ||
// } else { | ||
// return fmt::format("{:%Hhr %Mmin %Ssec}\n", duration()); | ||
// } |
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.
@Myoldmopar Assuming we want to keep 25 hr as an output format, just apply this:
// We're working with ms as base. | |
// TODO: do we want to report elapsed time of 25 hours as 1 day 1hr 0min 0sec or 25hr 0min 0sec? | |
// constexpr auto num_ms_in_day = 1000 * 3600 * 24; | |
// if (duration().count() > num_ms_in_day) { | |
// return fmt::format("{:.2%j days %Hhr %Mmin %Ssec}\n", duration()); | |
// } else { | |
// return fmt::format("{:%Hhr %Mmin %Ssec}\n", duration()); | |
// } | |
// We're working with ms as base. |
tst/EnergyPlus/unit/Timer.unit.cc
Outdated
EXPECT_EQ(124, t.duration().count()); | ||
EXPECT_EQ(0.124, t.elapsedSeconds()); |
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 just realized that Marvin actually reported 128. I'll adjust the test, we don't want it to fail when the system is busy.
It's really hidden to see the green check mark and just get an email. @Myoldmopar
- Do we have a test failure threshold or something? Is that warranted?
- We really need to bring back PR annotations
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.
For test failure threshold, we should have it set to fail if any unit test fails. If regressions fail, that will be fine, but we should still see the warnings. I'm still upset at GH for just disabling commit comments on the PR page without an easy way to bring them back.
IIRC, in my development branch of Decent CI, I operate on PRs directly where possible. So it's easy to move the comments to directly on the PRs. I'm open to pushing on that again, it's just a big distraction.
61cf218
to
8d6d7a2
Compare
8d6d7a2
to
8776c96
Compare
Obviously if I were to sleep for like 10 seconds, the % difference would be much smaller. But this is a dumb test, and it's the fourth time I push (I squashed earlier)
This is all happy, let's get it in to get today's merge queue moving. Thanks for adding the robustness to the time test, @jmarrec |
Pull request overview
I implemented a Timer class, that I made re-startable (even though not needed right now) like a stopwatch, in case we do want to use that for timings specific bits of the code.
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.