feat(netcdf): support creating and loading model netcdf input files

[mjreno]

Initial support for NetCDF model utility classes:

• currently focused on input arrays (no timeseries)
• dependent on FloPy discretization classes
• support creating, loading and modifying grid associated array data
• create or load "layered mesh" (structured(DIS)/vertex(DISV)) or "structured" (structured(DIS)) format types
• creates files suitable as MODFLOW 6 inputs when dataset is associated with a MODFLOW 6 model
• integrated into mf6 core module: reads and writes MODFLOW 6 input files that follow NETCDF variable formats as described in the mf6io guide

[codecov]

Codecov Report

Attention: Patch coverage is 90.04093% with 73 lines in your changes missing coverage. Please review.

Project coverage is 76.3%. Comparing base (7eb7c88) to head (95bcd97).
Report is 9 commits behind head on develop.

Files with missing lines	Patch %	Lines
flopy/utils/model_netcdf.py	89.2%	65 Missing ⚠️
flopy/mf6/data/mfdataarray.py	92.0%	2 Missing ⚠️
flopy/mf6/mfmodel.py	94.8%	2 Missing ⚠️
flopy/mf6/mfpackage.py	83.3%	2 Missing ⚠️
flopy/mf6/data/mffileaccess.py	94.7%	1 Missing ⚠️
flopy/mf6/utils/codegen/filters.py	0.0%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##           develop   #2417     +/-   ##
=========================================
+ Coverage     76.1%   76.3%   +0.2%     
=========================================
  Files          296     297      +1     
  Lines        64215   64934    +719     
=========================================
+ Hits         48885   49564    +679     
- Misses       15330   15370     +40     

Files with missing lines	Coverage Δ
flopy/mf6/data/mfdataplist.py	79.8% <100.0%> (+<0.1%)	⬆️
flopy/mf6/data/mfdatastorage.py	75.7% <100.0%> (+0.3%)	⬆️
flopy/mf6/data/mfstructure.py	74.0% <100.0%> (+0.2%)	⬆️
flopy/mf6/mfsimbase.py	75.6% <100.0%> (ø)
flopy/mf6/data/mffileaccess.py	76.9% <94.7%> (+0.3%)	⬆️
flopy/mf6/utils/codegen/filters.py	0.0% <0.0%> (ø)
flopy/mf6/data/mfdataarray.py	68.4% <92.0%> (+1.2%)	⬆️
flopy/mf6/mfmodel.py	84.4% <94.8%> (+0.4%)	⬆️
flopy/mf6/mfpackage.py	82.1% <83.3%> (+0.1%)	⬆️
flopy/utils/model_netcdf.py	89.2% <89.2%> (ø)

... and 4 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[wpbonelli]

is there a specification of the necessary annotations (modflow_model, modflow_grid, etc) somewhere? flopy4 will need to know about them too, right?

[wpbonelli]

This is basically our own convention about what's expected in a netcdf dataset, on top of whichever other conventions we may use internally, right?

[mjreno]

The annotations have been in flux with the dynamic (timeseries) input work ongoing in MODFLOW 6 now (GHBA, etc). After that PR goes in (or with it), documentation will be updated to formalize and share these annotations. The first place might be the MODFLOW 6 wiki but could also be mf6io/markdown files, etc. And yes, these are are own annotations, the most important of which are associated with individual variables, e.g. modflow_input which represents the mempath. These annotations identify the file as a valid input source for MODFLOW 6.

[mjreno]

As far as alternative approaches- I would say that sort of approach is consistent with pyphoenix and maybe would help with integration or a cutover. xarray itself wouldn't be sufficient though as this utility also supports creating UGRID compliant inputs- we would have needed to also use xugrid or something similar. At the time, it was unclear what the path would be in pyphoenix, and I took what I thought was an Flopy3 consistent approach. Maybe we should talk about this more before it is merged- I'll need to update some tests first at any rate to bring what it there up to level with where MODFLOW 6 is.

[wpbonelli]

Ah, ok- so we'll have to use xugrid objects. That makes sense.

I dunno if functions are the best way. It doesn't really matter if they stand alone or live on a class. I just feel like we should be wary of redefining a data model, and try to lean on xarray/xugrid/etc as much as possible. I'd say as soon as you get the tests up to date it can come in and we can refactor as we go?

[mjreno]

Yeah that sounds good to me, updates will be needed soon for timeseries data and then whatever refactoring makes sense.

[wpbonelli]

Since this provides the functionality we need for now, I say bring it in.

But I wonder about introducing a new class hierarchy. Could we instead have factory functions creating xr.Dataset? What do we get here by wrapping a custom class around a dataset?