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

Store ert<->everest realization mapping #9767

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

yngve-sk
Copy link
Contributor

@yngve-sk yngve-sk commented Jan 16, 2025

Note: Should not be merged until a consistent realization mapping is received from ROPT, replacing the logic in the second commit of this PR.

Issue
Resolves #9751
Resolves #9674

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

@yngve-sk yngve-sk self-assigned this Jan 16, 2025
Copy link

codspeed-hq bot commented Jan 16, 2025

CodSpeed Performance Report

Merging #9767 will not alter performance

Comparing yngve-sk:25.01.16.add-everest-realization-info-to-ert (3990831) with main (3abaf02)

Summary

✅ 25 untouched benchmarks

@yngve-sk yngve-sk force-pushed the 25.01.16.add-everest-realization-info-to-ert branch 8 times, most recently from 4e70ffd to be7341e Compare January 27, 2025 08:20
@yngve-sk yngve-sk force-pushed the 25.01.16.add-everest-realization-info-to-ert branch from 2202375 to 3990831 Compare February 3, 2025 07:55
Copy link
Contributor

@verveerpj verveerpj left a comment

Choose a reason for hiding this comment

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

Some comments but basically solid.


realization_mapping: dict[int, EverestRealizationInfo] = {
idx: EverestRealizationInfo(
geo_realization=self._everest_config.model.realizations[real],
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we internally already move from geo to model, I think we should encourage that in the long run.

class EverestRealizationInfo(TypedDict):
geo_realization: int
perturbation: int | None # None means it stems from unperturbed controls
# Q: Maybe we also need result ID, or no? Ref if we have multiple evaluations
Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, we will probably, let's not worry about it now.

Comment on lines +54 to +60
for e in self.ensembles:
ens_parameters = {
group: e.ert_ensemble.load_parameters(group)
.to_dataarray()
.data.reshape((e.ert_ensemble.ensemble_size, -1))
for group in parameter_values
}
Copy link
Contributor

Choose a reason for hiding this comment

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

you think may need some caching here, or is there already in the storage?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This just points to parameters saved in xr files in ERT storage

else None
),
)
for idx, real in enumerate(evaluator_context.realizations)
Copy link
Contributor

Choose a reason for hiding this comment

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

This maps the indices of the control vectors to realizations/perturbations. Is that the intention? Because if the intention is to map simulation ID (= ert realization?) then this will fail if some control vectors are not evaluated due to being cached or being marked as inactive. You would need to do the same as I did in my recent PR to get the simulation ID's for the simulations that actually did run.

)["values"]

cached_data = (
objectives.to_numpy() * -1,
Copy link
Contributor

Choose a reason for hiding this comment

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

Be careful after rebasing, the -1 is probably not needed anymore.

if constraints is not None:
assert cached_constraints is not None
constraints[control_idx, ...] = cached_constraints
for control_idx, (
Copy link
Contributor

Choose a reason for hiding this comment

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

I think caching is now always assumed to be on? We do have a flag for in in the configuration, maybe we should kill it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Ready for Review
Development

Successfully merging this pull request may close these issues.

Add Everest realization metadata to ERT storage Use ERT storage for Everest simulator cache
2 participants