Coder Social home page Coder Social logo

snapwell's Introduction

Snapwell is free software: you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free
Software Foundation, either version 3 of the License, or (at your option)
any later version.

Snapwell is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.

See the GNU General Public License at <http://www.gnu.org/licenses/gpl.html>
for more details.

Installation and usage

Snappwell is available on pypi and can be installed using pip install snapwell

On snapwell

Snapwell is a project for depth optimizing wellpaths by changing the TVD according to OWC. What exactly defines OWC at a given (x,y)-coordinate can be specified as number r between 0 and 1, and OWC is then the lowest point with SWAT=r. Future implementations might also take the permeability into account.

Changes in TVD are typically done by using a max increase of 0.5 m/30m to avoid making vertical segments.

Should avoid putting the majority of the well path in cells with non producible permeability.

Fileformat

snapwell input file

The filepath is relative to the config file, not the current working directory.

The config file is a yaml-file having the following format:

grid_file: "NORNE_ATW2013.EGRID"
restart_file: "NORNE_ATW2013.UNRST"
init_file: "NORNE_ATW2013.INIT"

output_dir: "norne-mid"
overwrite: False
delta_z: 0.003
log_keywords: ["PERMX", "OWC", "TVD_DIFF"]

wellpath_files:
  - {well_file: "norne-test-1-mid.w", date: "1997-05-1"}
  - {well_file: "norne-test-2-mid.w", date: "1998-01-1"}
  • Two keywords are mandatory, grid_file and restart_file, and should be followed by a path to the grid (GRID/EGRID) and restart files (UNRST), respectively (see example below).
  • The init_file is required for permeability output, and should be a path to an init file.
  • The following additional keywords are supported:
    • output --- the output directory (path), is set to cwd by default
    • overwrite --- a boolean (True/False) specifying whether the program is allowed to overwrite already existing files. Defaulted to False; use with care.
    • delta_z --- the maximum elevation per 100 meters, given as a float. 0.0167 is 0.5m/30m.
    • owc_definition --- The keyword used for saturation and threshold value used to determine owc
owc_definition:
  keyword: "SWAT"
  value: 0.7
  • owc_offset --- a number (eg. 0.5). Will place the wellpoint 0.5m above OWC
  • log_keywords --- list of values written to the well file:
    • OWC --- actual OWC for given date and (x,y) coordinate
    • OLD_TVD --- the old TVD specified in the input Wellpath
    • DIFF --- The difference between OLD_TVD and new TVD
    • SWAT, SOIL, SGAS, PERMX --- value in wellpoint cell for keyword
    • LENGTH --- the distance between this (x,y) coordinate and the previous
  • wellpath_files --- list of files in the wellpath format
    • well_file --- path to the wellpath file
    • date --- YYYY-MM-DD The date to look up values for in the restart file.
    • window_depth --- The depth to start optimizing the well for.
    • depth_type --- Type of depth in the well file, either "MD" or "TVD".

WellPath format (RMS well format)

The wellpath format is given as follows: (blank lines and lines starting with -- ignored)

<version>
<well type>
<well name> <x> <y> <rkb>
<number of well logs>
<log name 1> <unit> <scale>
...
<log name n> <unit> <scale>
<x> <y> <z> <p1> ... <pn>
...
<x> <y> <z> <p1> ... <pn>

An example is the following:

1.0
PRODUCTION
TEST_WELL 1068.000 0.000 0.0000
3
MD 1 lin
Incl 1 lin
Az 1 lin
1068.0    0.0    38.0    38.0    109.0    359.0
1069.0    5.0    39.0    50.0    109.0    359.0

Here, the X, Y, and Z numbers are UTM* easting, UTM northing, UTM TVD (true vertical depth), and then follow the three log parameters defined, MD, INC and AZ, being measured_depth, inclination and azimuth.

We safely ignore all but the three first numbers in each row (actually, only x and y are really interesting).

  • UTM is Universal Transverse Mercator coordinate system

Run tests

tox is used as the test facilitator, to run the full test suite:

# Test
pip install tox
tox

or to run it for a particular Python version (in this case Python 3.7):

# Test
pip install tox
tox -e py37

or to run it for a the current Python version on PATH:

# Test
pip install tox
tox -e py

pytest is used as the test runner, so for quicker iteration it is possible to run:

# Test
pytest

this requires that the pytest is installed.

# Install pytest
pip install pytest

pre-commit is used to comply with the formatting standards. The complete formatting tests can be run with:

pip install tox
tox -e style

See .pre-commit-config.yaml for the complete steps.

pre-commit can also provide git hooks to run on every commit to avoid commiting with formatting errors. This will only run on the diff so is quite fast. To configure this, run:

pip install pre-commit
pre-commit install

After this the hook will run on every commit.

If you would like to remove the hooks, run:

pre-commit uninstall

snapwell's People

Contributors

eivindjahren avatar oyvindeide avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

snapwell's Issues

Add test

Add test that

  1. Downloads and builds ert
  2. Downloads Norne grid and restart file
  3. Run an integration test / validation test / smoke test on a single config path

Make ERT hooks

Should be optional, for example installed with pip install snapwell[ert-hooks]

Allow the user to constrain snapping within zones

There is no support in snapwell for confining the well to a zone or region, aside for the fact that it will stay clear of inactive cells. It would be good to support some basic constraints, such as within a zone. This would expand the application to many more use cases.

image

Allow snapwell to complete succesfully even though some snaps fail

Because snapwell is being used as a forward model, a -1 return code might not be wanted when at least some operations finish successfully.

A couple of options as far as I can see:

  • Add an option to only fail if a certain number (or percentage) of snaps fail (command line probably)
  • We have two different entry points, we could have slight different behavior in the ert entry point.

Several tests in test_snapconfig.py are failing

Several tests in test_snapconfig.py are failing and are marked as xfail, we need to figure out why. Same error message, so probably the same reason.

Relevant tests:

Refactor: ResSlice

Make snapecl construct a ResSlice (wall) of the wellpath before running algorithm.

Instead of running findOwc and activeColumn successively on the wellpoints, construct the entire wall first (with inactive cells).

Consider splitting the wall vertically and adjusting for height (TVD).

This facilitates the use of DP / genetic algorithms.

Let RESTART files be optional in snapwell if INIT file is provided

In snapwell, if RESTART is not provided but INIT is, we may still perform snapping, but using the SWATINIT keyword, and without a given date.

This might be interesting for users without a proper UNRST file.

What needs to be done: Check in snapecl.snap whether argument rest (restart EclFile) is None and init (init EclFile) is not None. If so, we need to ignore (and probably output) all dates, and use the SWATINIT keyword instead of SWAT. Should this be a user concern? I.e., should the user be forced to set SWATINIT as OWC_DEFINITION, should we set SWATINIT as keyword, or should we append INIT to the provided keyword?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.