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

Ert3 examples #1

Open
wants to merge 166 commits into
base: master
Choose a base branch
from
Open

Ert3 examples #1

wants to merge 166 commits into from

Conversation

kvashchuka
Copy link
Owner

Issue
Resolves #my_issue

Approach
Short description of the approach

sondreso and others added 30 commits December 2, 2020 11:33
Add first iteration of the API for the ensemble evaluator

Co-authored-by: Frode Aarstad <[email protected]>
Co-authored-by: Morten Bendiksen <[email protected]>
Co-authored-by: Jonas Grønås Drange <[email protected]>
Co-authored-by: Sondre Sortland <[email protected]>
Co-authored-by: Frode Aarstad <[email protected]>
Co-authored-by: Jonas G. Drange <[email protected]>
Co-authored-by: Sondre Sortland <[email protected]>
The Qt5 backend provides the same classes as Qt4, so it is a drop-in
replacement. According to the documentation page below, 'FigureCanvas'
is an alias of 'FigureCanvasQTAgg', so the import 'as' is unnecessary.

https://doc.ebichu.cc/matplotlib/api/backend_qt5agg_api.html
Launch ert storager server if no server is found
This commit includes the following major changes:
- Conversion from Flask to FastAPI
- Removal of RdpApi and StorageApi classes, preferring to use SqlAlchemy
  without any additional wrappers. (It should be noted that the FastAPI
  cookiecutter project implements a bunch of CRUD functions that we
  could also implement. I decided not to because it's unnecessary at
  this point in time.)
- Addition of POST-ing endpoints
- Extraction now posts data via HTTP rather than directly via SqlAlchemy
- "New Storage/Old Plotting" has been removed. It was a proof-of-concept
  which we intend to reimplement within the Webviz framework (webviz-ert)
When refactoring for FastAPI, the create_update function was incorrectly
transferred. The lack of ensemble updates came from a bug where a
function was inlined naively, causing an early return.

The usage of the term 'misfit' is incorrect but I've chosen not to touch
it. It should rather be called an update or a synonym thereof.
Starlette (and therefore FastAPI) explicitly disables float nans when
using the `JSONResponse` object, which is the default one used by
FastAPI. We replace the default with our own copy that has
`allow_nan=True`.
This is a hack in order to avoid the latency from NFS. In the future
this will be done properly by having a separate centralised database
server to which ERT will connect to and thus we won't be on NFS anymore.
This PR introduces the use of Prefect as the workflow manager/queue
system.  The initial implementation can run both locally and on the
Equinor LSF cluster. It uses a newly introduced configuration file to
set up a Prefect ensemble that can run a UnixStep (a user-configured
python script) as part of a forward model.

Depending on the configuration of inputs and outputs of the UnixSteps
that define the forward-model the steps can run either in parallel or
sequentially.

A UnixStep has the following assumptions:

 * Access to shared disk for all of the jobs
 * Data is loaded from the shared disk
 * Integration it with the current CLI/GUI
 * Supports only a programmatic interface.

This first iteration has been tested using a poly case example.

Resolves equinor#1125
Co-authored-by: Markus Dregi <[email protected]>
Co-authored-by: Øyvind Eide <[email protected]>
Co-authored-by: Anette Uttisrud <[email protected]>
Co-authored-by: Lars Petter Øren Hauge <[email protected]>
Co-authored-by: Helena Nandi Formentin <[email protected]>
Co-authored-by: Sondre Sortland <[email protected]>
Co-authored-by: anna.kvashchuk <[email protected]>
verveerpj and others added 29 commits March 11, 2021 10:24
* Have ert3.engine stop closing passed streams

A stream is passed to ert3.engine such that records can be loaded and
persisted in storage. The stream is opened outside of the engine, but
currently closed within. This is a bad design pattern and a remenant
from when the engine code lived as part of the console submodule!
Instead the one opening the stream should also be responsible for
closing it.

* Open files using context managers

* Close record file explicitly after loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.