feat(sim options block packages): Support for packages declared in simulation name file's options block

[spaulins-usgs]

Added support for declaring packages in the simulation name file's options block using the FILEIN keyword. Currently the only package that can be defined in the name file's options block is the HPC package, which is included in this pull request.

When creating packages that can be declared in the simulation name file's options block follow the same procedure for creating the dfn as you would for other subpackages, but make sure to set the parent package type to MFSimulation and add the filein record to the simulation name file dfn.

Adding and removing these packages in flopy is similar to how packages are added and removed from a model. Just create the HPC package object passing in the MFSimulation object and flopy will take care of updating the namefile for you. For example:

hpc = ModflowUtlhpc(sim, dev_log_mpi=True, partitions=partitions, filename="test.hpc")

To get the package object use the MFSimulation object's get_package method.

hpc_instance = sim.get_package("hpc")

The MFSimulation object's remove_package method allows you to remove the package (updating the namefile for you):

sim2.remove_package(hpc)

[langevin-usgs]

Hey @spaulins-usgs, this all seems to look okay. Would you mind writing in the github PR description how this works and how someone can add a new package? You've added support for the HPC package, but would this same pattern also work for a model name file? Also, I notice that the dfn's have some new flopy tags that would be good to describe somewhere.

[spaulins-usgs]

Hey @spaulins-usgs, this all seems to look okay. Would you mind writing in the github PR description how this works and how someone can add a new package? You've added support for the HPC package, but would this same pattern also work for a model name file? Also, I notice that the dfn's have some new flopy tags that would be good to describe somewhere.

@langevin-usgs, I added a text explaining how to use this to the github PR description. Currently, the same pattern is not supported in the model name file. Adding support for the model name file should be straightforward, but at this time I did not implement that feature since I have no packages to test it with. I used the "subpackage" flopy tags in the dfns, which are already documented in the MODFLOW-6 repository under the "Creating a New Subpackage Definition File" section here:

https://github.com/MODFLOW-USGS/modflow6/blob/develop/doc/mf6io/mf6ivar/readme.md

[codecov]

Codecov Report

Attention: Patch coverage is 30.76923% with 45 lines in your changes are missing coverage. Please review.

Project coverage is 35.0%. Comparing base (029a4e1) to head (9dd3fcc).
Report is 6 commits behind head on develop.

❗ Current head 9dd3fcc differs from pull request most recent head 13967f9. Consider uploading reports for the commit 13967f9 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##           develop   #2164      +/-   ##
==========================================
- Coverage     68.3%   35.0%   -33.4%     
==========================================
  Files          260     260              
  Lines        57947   58031      +84     
==========================================
- Hits         39611   20333   -19278     
- Misses       18336   37698   +19362     

Files	Coverage Δ
flopy/mf6/mfbase.py	75.5% <100.0%> (+0.7%)	⬆️
flopy/mf6/modflow/__init__.py	100.0% <100.0%> (ø)
flopy/mf6/modflow/mfsimulation.py	100.0% <100.0%> (ø)
flopy/mf6/mfpackage.py	61.3% <57.1%> (-2.8%)	⬇️
flopy/mf6/mfsimbase.py	61.8% <21.7%> (-0.7%)	⬇️
flopy/mf6/utils/createpackages.py	6.4% <0.0%> (-0.3%)	⬇️

... and 212 files with indirect coverage changes

[mjr-deltares]

Hi @spaulins-usgs , do you have an idea why that documentation check is still failing on macos-latest? And is there anything I can do to bring this to completion? (CC @langevin-usgs)

[wpbonelli]

@mjr-deltares @spaulins-usgs I ran into the same issue, it's fixed by #2171 if you want to rebase.

[jdhughes-usgs]

@wpbonelli should our single OS jobs use the oldest python version (3.8) or the latest (3.12)?

[mjr-deltares]

Thanks @wpbonelli. @spaulins-usgs : can you update the branch?

[wpbonelli]

@jdhughes-usgs I think there's a case for both. My reasoning for going with the oldest is

• many developers are probably using the latest locally, so we already have some coverage there
• newer language features unsupported by old pythons could sneak in unnoticed if we don't CI test the oldest