Release 6.6.3 #2531
Closed
Release 6.6.3 #2531
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Post release 6.6.2 reset
Support remote or local model access in the external model tests via an identical pattern. This uses some new stuff in the models API. This is relevant for anyone needing to modify test models during MF6 development.
By default, as has been the case since we started using the models API recently, the tests will use the GitHub-backed Pooch registry. To test against local models, introduce a --models-path pytest CLI option. If one or more is provided, the paths will be searched for models and tests will be run against those instead of models from the official registry.
By default, only MF6 models are discovered. There is a --namefile-pattern option to relax the discovery for MF2005 etc.
E.g. to run MF6 models in a local checkout of the modflow6-testmodels repo, from <project root>/autotest/ of the MODFLOW 6 repo
pytest -m "external" --models-path ../../path/to/modflow6-testmodels/
# or pixi run autotest -m ...
Or to run mf5to6 converter tests against the mf2005 models
pytest -m "external" --models-path ../../path/to/modflow6-testmodels/mf5to6 --namefile-pattern "*.nam"
This PR updates the developer docs to reflect the above. Previously they described the old fixtures pattern.
Also update the CI to checkout the external model repos and use the new local registry mechanism rather than using the official registry. Since moving to the models API we have tested the models as frozen by the official registry but we want to test the latest. (Speaking of which, we will need to move to the develop/master branching strategy in test models and large test models repos so the official registry has something stable to point at — or consider moving those models into this repo.)
Also consolidate the external model tests from
test_testmodels_mf6.py
test_testmodels_mf5to6.py
test_largetestmodels.py
into a single file test_external_models.py.
Neglected to do this in #2321
These were marked as removed in 6.6.1 but they were removed in 6.6.0.
No longer need to delete/copy the flopy DFN directory since we removed DFNs from flopy. Also, just invoke flopy codegen directly in the update-flopy pixi task like python -m flopy.mf6.utils.generate_classes --dfnpath doc/mf6io/mf6ivar/dfn, instead of running update_flopy.py. The script doesn't do much anymore, besides saving some typing. I considered removing it, but I know not everyone uses pixi.
#2337 missed a couple issues in the error messages
the job was failing because of brew's complaint that gcc (15) was being reinstalled (over 13)
…2254) * write optional crs user input string to binary grid file * first pass mf6io update * add disu * add remaining discretizations * add baseline tests * add release note --------- Co-authored-by: mjreno <[email protected]>
…envs (#2345) * Add test-drive and pkg-config to pixi and conda envs * Remove test-drive workflow from CI
These are not being used and need some attention if we want to use them. They are causing compile-time warnings. Remove them for now. Nothing is ever truly gone with source control.
Clarify how to use the dfn2f90.py script and why it's necessary. And move IDM.md to the project root so other docs can reference its location consistently from github or RTD, anticipating the addition of the IDM document to the RTD dev docs in #2331.
Fix path in conf.py
Seems like the pixi run bash -e {0} trick has stopped working on Windows. I used tmate-action to log into the runner and tried running pixi shell and got a shell not configured error. Use pixi run --manifest-path ... instead.
Also fix the path to copy mf6 exes to, on Windows bash $HOME and ~ now seem to resolve not to the real runner home directory c/Users/runneradmin but to a fake bash home directory. Also a recent runner change?
) Update windows extended build: netcdf-fortran 4.6.2 netcdf-c 4.9.3 disable new cmake environment checks that are not CI relevant Disabled checks: netcdf-c netCDFConfig.cmake: #set_and_check(netCDF_INSTALL_PREFIX "C:/Program Files (x86)/netCDF") #set_and_check(netCDF_INCLUDE_DIR "C:/Program Files (x86)/netCDF/include") #set_and_check(netCDF_LIB_DIR "C:/Program Files (x86)/netCDF/lib") #if (netCDF_HAS_HDF4 OR netCDF_HAS_HDF5) # include(CMakeFindDependencyMacro) # find_dependency(HDF5) #endif ( netcdf-fortran CMakeLists.txt #FIND_PACKAGE(HDF5 COMPONENTS C HL REQUIRED)
Discussion has been had regarding behavior at the water table. This may be refined in future. Behavior just introduced in #2478 and #2495 keeps particles immobile/active at the water table if they reach it from below with DRY_TRACKING_METHOD DROP or STAY, while with STOP particles would terminate on reaching the water table. This is in hindsight overfitting to the expected Keating result at the expense of design aims It seems more correct to interpret DRY_TRACKING_METHOD as only applying to particles which are dry after the flow solution is available, before the particle track is solved for the time step. Trying to find distinct interpretations in various contexts within the tracking method, e.g. if a particle obtains a valid exit solution through the "top" (i.e. water table) of a partially saturated cell, could explode the scope of the dry tracking method option so seems best avoided With this, particles terminate if they reach the water table from below. This is consistent with MP7. DRY_TRACKING_METHOD applies only if the water table drops below them during the simulation, or if particles are released above the water table into a Newton flow system. This does imply accepting some particles will stop early in Keating for some compilers and optimization options; numerical noise in the flow solution will try to send some of them back upwards after they drop to the water table, so they fall straight to water and terminate. Most will keep doing the "waterfall"/cascade down the sides of the perched aquifer as we expect. Maybe the flow system can be tweaked to fix the noisy flows and get them all to cooperate? Separately, recent commits got a face numbering calculation in MethodCell.f90 wrong in the general case, but in such a way as to happen to work for the rectilinear case Also miscellaneous cleanup
Following on #2499, update the DFN spec developer document. Also mark a few tests developmode to prep for the upcoming patch release
…rho*eta == 0 (#2487) * - continue with outer iteration when linear solver has reached rho*eta == 0, same as in IMS * - add release note * - update spelling
Revise #2441 such that an event is still emitted when a particle is dropped to the water table, but introduce a new event and reason code (6) for it
Modify update_version.py, mf6ivar.py and build_docs.py to filter prerelease variables out of the intermediate markdown/latex artifacts in develop mode, and likewise in the io guide with a new ifdevelopmode conditional
needed so ifdevelop is defined for the mf6io latex build
#2478 introduced and #2496 revised special handling at the water table. This revises it again. Rather than immobilizing the particle and/or applying special termination conditions if it reaches a water table from below, "cap" cells containing a water table at zero upwards flow in the absence of an assigned top boundary face. This guarantees that a particle exiting through the top of a cell is carried not by negligible Newton flows but legitimate flow through an assigned boundary face.
…2513) fix --original-regression, it got broken somewhere along the way. remove some unneeded workspace setup functions and just use copytree instead. tidy up relevant bits and pieces of the test framework and dev docs
#2514) make naming consistent and reflect the fact that these routines load data onto the cell
…2517) Intel has removed ifort from their distributions, reflect that in DEVELOPER.md
just the build job for now. update docs/dist jobs later.
Add a --patch argument to the mk_releasenotes.py script which turns develop.toml into LaTeX. Add corresponding option to build_docs.py. This switch will omit everything but fixes from the release notes, suitable for a patch release. (In future maybe consider a more specific LaTeX tag than \ifdevelop, indicating something is a new feature? Then --patch could omit those sections. Maybe --patch could also diff the DFNs and find/omit new options too, so we don't need to mark them with prerelease true. Just thinking ahead.) Also restore a couple new feature items that got accidentally dropped recently
Follow up on #2523. Add a corresponding input for workflow dispatch. If the release is triggered by pushing a branch, it will diff the new version number against the latest tag on master, determine if this is a patch release, and behave accordingly.
need to check out mf6 in the set_options job before looking at tags
skip unit tests on arm mac, test-drive seems to collect results incorrectly
…ild (#2528) some reorganization in the release workflow to consistently pass test markers and filters to the test step (if testing is activated) for both regular and extended build flavors
macos fancy business before running get-exes since it rebuilds the prev release
subsections weren't filtered properly causing some items to go unrendered
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
MODFLOW 6.6.3 release
The release can be approved by merging this PR into
master. Merging rather than squashing is necessary to preserve the commit history.When this PR is merged, a final job will be triggered to draft a tagged GitHub release, then upload assets (OS distributions and release notes).