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 walltime computation bug #9228

Merged
merged 1 commit into from
Nov 15, 2024
Merged

Conversation

berland
Copy link
Contributor

@berland berland commented Nov 15, 2024

Because we logged finished step events before the current batch of events were processed, there were situations where the snapshot from a previous failed realization was out of date.

This solves that problem. There is still a residual problem that will surface if walltime is to be computed for all steps: If a failure event for a step and its success event from the subsequent run is in the same batch of events, we can get a negative walltime computed. This problem is ignored as the walltime computation is only interesting (currently) for walltimes > 120 seconds, where this cannot happen (max time between batches is 2 seconds).

Issue
Resolves #9216

Approach
Short description of the approach

(Screenshot of new behavior in GUI if applicable)

  • PR title captures the intent of the changes, and is fitting for release notes.
  • Added appropriate release note label
  • Commit history is consistent and clean, in line with the contribution guidelines.
  • Make sure unit tests pass locally after every commit (git rebase -i main --exec 'pytest tests/ert/unit_tests -n logical -m "not integration_test"')

When applicable

  • When there are user facing changes: Updated documentation
  • New behavior or changes to existing untested code: Ensured that unit tests are added (See Ground Rules).
  • Large PR: Prepare changes in small commits for more convenient review
  • Bug fix: Add regression test for the bug
  • Bug fix: Create Backport PR to latest release

Because we logged finished step events before the current batch
of events were processed, there were situations where the snapshot from a previous
failed realization was out of date.

This solves that problem. There is still a residual problem that will surface if
walltime is to be computed for all steps: If a failure event for a step and its
success event from the subsequent run is in the same batch of events, we can get
a negative walltime computed. This problem is ignored as the walltime computation
is only interesting (currently) for walltimes > 120 seconds, where this cannot
happen (max time between batches is 2 seconds).
@berland berland self-assigned this Nov 15, 2024
@berland berland added the release-notes:bug-fix Automatically categorise as bug fix in release notes label Nov 15, 2024
Copy link
Contributor

@andreas-el andreas-el left a comment

Choose a reason for hiding this comment

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

Gotta process all! 💯

@berland berland merged commit 90c7a4c into equinor:main Nov 15, 2024
42 checks passed
@berland berland deleted the fix_walltime_bug branch December 27, 2024 11:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release-notes:bug-fix Automatically categorise as bug fix in release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Bug in walltime computation for logged forward model steps
2 participants