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

Use Experiment server in all run models when feature is enabled #3768

Merged
merged 1 commit into from
Sep 27, 2022

Conversation

berland
Copy link
Contributor

@berland berland commented Aug 16, 2022

Issue
Resolves #3413

Approach
runSimulations() in each run model has been ported to an async function alongside that uses the experiment server.

Pre review checklist

  • Added appropriate release note label
  • PR title captures the intent of the changes, and is fitting for release notes.
  • Commit history is consistent and clean, in line with the contribution guidelines.

Adding labels helps the maintainers when writing release notes. This is the list of release note labels.

@xjules
Copy link
Contributor

xjules commented Aug 16, 2022

You can check this one too: #3637 and close it afterwards.

@berland berland force-pushed the experiment_api branch 3 times, most recently from 656549d to f452e3c Compare August 17, 2022 08:36
@codecov-commenter
Copy link

codecov-commenter commented Aug 17, 2022

Codecov Report

Merging #3768 (c096236) into main (cd3b47b) will decrease coverage by 0.00%.
The diff coverage is 62.20%.

@@            Coverage Diff             @@
##             main    #3768      +/-   ##
==========================================
- Coverage   63.73%   63.73%   -0.01%     
==========================================
  Files         587      587              
  Lines       43828    43977     +149     
  Branches     3786     3786              
==========================================
+ Hits        27935    28029      +94     
- Misses      14770    14826      +56     
+ Partials     1123     1122       -1     
Impacted Files Coverage Δ
src/ert/experiment_server/_server.py 80.41% <0.00%> (ø)
...rc/ert/shared/models/iterated_ensemble_smoother.py 60.00% <14.51%> (-28.78%) ⬇️
src/ert/shared/models/single_test_run.py 94.73% <50.00%> (-5.27%) ⬇️
src/ert/shared/main.py 81.25% <66.66%> (+0.79%) ⬆️
src/ert/shared/models/ensemble_experiment.py 95.38% <75.00%> (-0.14%) ⬇️
src/ert/shared/models/ensemble_smoother.py 94.30% <92.00%> (-1.59%) ⬇️
src/ert/shared/models/base_run_model.py 89.64% <100.00%> (+0.08%) ⬆️
...rc/ert/shared/models/multiple_data_assimilation.py 96.44% <100.00%> (+1.10%) ⬆️
src/ert/data/record/_transformation.py 88.57% <0.00%> (-0.48%) ⬇️
src/clib/lib/res_util/block_fs.cpp 67.62% <0.00%> (+0.40%) ⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more


# Push ensemble, parameters, observations to new storage
ensemble_id = await loop.run_in_executor(
threadpool, self._post_ensemble_data, update_id
Copy link
Contributor Author

Choose a reason for hiding this comment

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

_post_ensemble_data calls self.setPhaseName() which should maybe invoke a call to the experiment server?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That will happen later when the experiment server supports it.

@berland berland linked an issue Aug 18, 2022 that may be closed by this pull request
@berland berland changed the title Complete experiment API adoption WIP: Use Experiment server in all run models Aug 18, 2022
@berland berland self-assigned this Aug 29, 2022
@berland berland marked this pull request as ready for review August 29, 2022 12:39
@berland berland changed the title WIP: Use Experiment server in all run models Use Experiment server in all run models Aug 29, 2022
experiment_logger.debug("evaluating")
await self._evaluate(run_context, evaluator_server_config)

num_successful_realizations = self._state_machine.successful_realizations(
num_successful_realizations = await self.successful_realizations(
Copy link
Contributor

@xjules xjules Aug 31, 2022

Choose a reason for hiding this comment

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

Agree, makes more sense to use the defined member 👍

prior_context.iteration,
)

self._checkMinimumActiveRealizations(prior_context)
Copy link
Contributor

@xjules xjules Aug 31, 2022

Choose a reason for hiding this comment

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

Use loop.run_in_executor? Not sure where should be a threshold for saying this function is "atomic" does not need to be async.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Tracing through the code, this seems to only involve trivial getters and an integer comparison. My gut feeling is then not to
yield through await since there might be some overhead with our switching between sync and async context? (this is partly speculation)

Copy link
Contributor

Choose a reason for hiding this comment

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


experiment_logger.debug("update complete")

await self.dispatch(
Copy link
Contributor

@xjules xjules Aug 31, 2022

Choose a reason for hiding this comment

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

We might consider creating a helper class for dispatch, which automatically injects the correct source string based on ids specified and creates an uuid.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good idea, implemented. Unsure of the name I chose, "_dispatch_ee"

"id": str(uuid.uuid1()),
},
{
"error": str(e),
Copy link
Contributor

@xjules xjules Sep 5, 2022

Choose a reason for hiding this comment

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

Wondering where this error field is actually used? This is essentially data argument in CloudEvent, but it's not really processed ...., or maybe I've missed it where; hence the question :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure, but I guess it does make sense to pass the error information on. The same data argument is used for hook names as far as I can see, maybe not picked up (yet!) either(?)

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. I wonder mainly whether this kind of general "data" field should be present for Protobuf objects (which of-course it can't, but we can supplement some error fields at least) ...
Anyway, for this I understand you would like to keep regardless it's being consumed or not?

@berland berland added the release-notes:new-feature Automatically categorise as new feature in release notes label Sep 6, 2022
@berland berland changed the title Use Experiment server in all run models Use Experiment server in all run models when feature is enabled Sep 6, 2022
@berland berland force-pushed the experiment_api branch 2 times, most recently from bc1c370 to c096236 Compare September 6, 2022 07:26
@berland
Copy link
Contributor Author

berland commented Sep 7, 2022

todo: Write test function for _dispatch_ee

@xjules
Copy link
Contributor

xjules commented Sep 7, 2022

todo: Write test function for _dispatch_ee

Considering _dispatch_ee again.... I think the code looks much more compact. Additional, since it only affects the evaluator than I would keep it without the test function since this call can be considered "atomic"; ie. essentially one liner ...

@lars-petter-hauge
Copy link
Contributor

Thanks for picking up on the continuation of #3438. With this implementation though we are adding a fair bit of duplicated code for the run function, from what I can see because:

  1. we want it to be async
  2. we want the function called from experiment_server to also send events.

Could we not use the samme pattern that we already implement for evaluate?

There we have both def evaluate and async def evaluate_async, in which they both call async def _evaluate_inner. The synchronous version has to call the async version with get_event_loop.run_until_complete.

I would really like us to avoid duplicating the runSimulations functionality, as it will be a real hassle to keep both up to date (we will likely fail..).

@berland berland force-pushed the experiment_api branch 2 times, most recently from 5daa7d2 to ca511b1 Compare September 19, 2022 15:05
The async versions are modified duplicates of the existing sync
run functions, and use the Experiment server feature.

Co-authored-by: Håvard Berland <havb@equinor.com>
@xjules
Copy link
Contributor

xjules commented Sep 26, 2022

Thanks for picking up on the continuation of #3438. With this implementation though we are adding a fair bit of duplicated code for the run function, from what I can see because:

  1. we want it to be async
  2. we want the function called from experiment_server to also send events.

Could we not use the samme pattern that we already implement for evaluate?

There we have both def evaluate and async def evaluate_async, in which they both call async def _evaluate_inner. The synchronous version has to call the async version with get_event_loop.run_until_complete.

I would really like us to avoid duplicating the runSimulations functionality, as it will be a real hassle to keep both up to date (we will likely fail..).

As discussed on our standup, we will do the "merging" process on one by one basis. The corresponding issue for the task is here: #3948.

Copy link
Contributor

@xjules xjules left a comment

Choose a reason for hiding this comment

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

Nice and LGTM! I linked to the corresponding issue to this PR.

@berland berland merged commit 96bfc31 into equinor:main Sep 27, 2022
@berland berland deleted the experiment_api branch October 18, 2022 12:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement release-notes:new-feature Automatically categorise as new feature in release notes
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Implement experiment interface in all run models
5 participants