-
Notifications
You must be signed in to change notification settings - Fork 318
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
feature: self-contained notebooks, API for example models #1872
Comments
A few more considerations. Example models are currently defined directly as input files. Is this the right way for programmatic access to models? If so, which models to bundle and which to download? The largest subdirs of
An alternative may be to define in flopy and generate/cache on first request. I'm not sure how straightforward it is to convert existing input files to flopy code. It seems like an examples module could offer the same API either way. Maybe it is worth experimenting to see if it is generally faster to pull big models over the wire or write them fresh (maybe the recent pandas speedup helps here). For files distributed with flopy, the examples module could internally use |
An example models module would also simplify flopy and mf6 autotests, by removing the need for custom fixtures to fetch/prepare models for testing. There has been some effort to standardize the approach for this but it's still patchy. Maybe devtools could provide programmatic access to examples, flopy could add a hard devtools dependency, and pass the same API through for convenience. This seems reasonable because
|
Small step towards #1872. Move geometry info to a YAML file under examples/data/ and move utils into scripts to remove common/ module import and sys.path manipulation. A later PR may introduce pooch as we have done for the mf6 examples: - MODFLOW-USGS/modflow6-examples#137 - MODFLOW-USGS/modflow6-examples#153
#2264 removed the notebook_utils.py module but neglected to remove this dependency from 3 examples: * export_vtk_tutorial.py * plot_cross_section_example.py * plot_map_view_example.py This is why these are missing from the develop version of the RTD site. This PR inlines the shared models which previously lived in notebook_utils.py. This duplication will go away once we have a models API as proposed in #1872.
First step towards #1872. Use pooch for data access. This is ugly, but it makes notebooks runnable (provided exes and python environment) out of the box. Local files will be used if detected, otherwise downloaded, following the pattern in the mf6 example models. An eventual models API could hide all the details of model access. Also mention the optional dependencies requirement on the tutorials and examples gallery pages.
Another variation on what this could look like, from import xugrid as xu
ds = xu.data.adh_san_diego(xarray=True) https://deltares.github.io/xugrid/examples/quick_overview.html#from-xarray-dataset |
Heavily edited after more consideration
Is your feature request related to a problem? Please describe.
This repo contains example model data in
examples/data/
. A download link was recently added to example notebooks rendered on ReadTheDocs, but many are not immediately runnable after download as they rely on example data. To run the notebooks first requires cloning the repo, or downloading files from the GitHub web UI, etc. This adds friction for first-time use and (from a maintainer perspective) complicates the docs build.Describe the solution you'd like
One option is a module (and maybe CLI) providing access to example models. Small models could be included in the package, larger ones downloaded/cached on demand. Projects like PyVista and scikit-image do this. Or model input files could be generated on demand. Models in the following repos could be included:
modflowpy/flopy
, inexamples/data/
MODFLOW-USGS/modflow6-examples
MODFLOW-USGS/modflow6-testmodels
MODFLOW-USGS/modflow6-largetestmodels
PyVista usage looks like:
skimage looks like:
The latter seems mildly preferable for brevity and because the data may already be cached (if downloaded) or generated (no downloads).
In flopy's case, maybe e.g.
Alternatively, it could return a
Path
to the model/simulation directory instead of theModflow
/MFSimulation
/etc itself. The model/simulation seems preferable as the path is retrievable from it anyway. To avoid polluting the cache with output files and to support the common case of loading then switching to a new workspace before rewriting/running, aworkspace
orsim_path
option may be convenient, perhaps defaulting to a temporary directory.Notebooks and tests would then be able to use the example model interface. Removing implicit filesystem expectations leaves notebooks dependent only on a python/flopy env and modflow binaries.
PyVista uses Pooch to do the fetching/caching, some of whose source skimage appears to vendor in their own implementation. If we generate model input files instead of downloading them, this would not be necessary.
The text was updated successfully, but these errors were encountered: