Add functionality to read gridded domain info and land use from input netcdf file

[GreyREvenson]

PURPOSE

This PR modifies the gridded version of the Noah-OM model to read gridded domain info (e.g., n_x, n_y, dx, and dy) and land use (i.e., vegtyp) values from a NetCDF input file. Subsequent PRs will add functionality to read additional gridded model variables (e.g., soils, slope, etc).

ADDITIONS

This PR adds GridInfoType.f90, which defines gridinfo_type. The gridinfo_type has member variables to hold read-in gridded input variables. The gridinfo_type has one public type-bound subroutine (gridinfo_type%ReadGridInfo).

The PR-added public gridinfo_type%ReadGridInfo subroutine is primarily intended to make calls to the gridinfo_type's private type-bound subroutines.

The PR-added subroutine gridinfo_type%ReadSpatialInfo reads spatial information (i.e., n_x, n_y, dx, dy, and latitude and longitude values) from the NetCDF file identified by its arguments. The subroutine (i.e., gridinfo_type%ReadSpatialInfo) is intended to be called for every NetCDF file (with the assumption that every gridded input variable will be provided via a separate NetCDF file) to ensure that all variables are provided over the same grid.

This PR adds the 'private' type-bound subroutine gridinfo_type%ReadVegtyp, which is called within gridinfo_type%ReadGridInfo. The primary purpose of gridinfo_type%ReadVegtyp is to read-in gridded land use data.

This PR adds data/netcdf_dummy.nc to facilitate testing. It is a dummy NetCDF file having gridded land use data in the format expected by this PR's code additions. The latitude, longitude, and vegtyp values for grid cell (1,1) match those for the control model run as listed in the pre-PR namelist.inputfile such that the output from grid cell (1,1) should match the control run while the output from other grid cells is expected to vary.

This PR adds test/analysis/create_dummy_netcdf.py was added to create data/netcdf_dummy.nc. This script was added to facilitate changes to the organization and contents of the input NetCDF file per PR feedback.

CHANGES

namelist.input was modified to remove the scalar vegtyp entry and add an entry for vegtyp_filename, which is the directory/name of the input NetCDF file passed to gridinfo_type%ReadVegtyp.

Changes were made to several of the initialization subroutines for the gridded derived data type members of noahowpgrid_type. Several of these subroutines were modified to take an instance of the gridinfo_type as an argument, often to provide access to n_x and n_y for allocating allocatable arrays. Note that land use values are transferred from gridinfo_type to domaingrid_type when gridinfo_type is given as an argument to domaingrid_type%InitTransfer.

TESTING

The PR-modified model was successfully compiled and executed in stand-alone on MacOS using GNU Fortran (Homebrew GCC 13.1.0) 13.1.0.

The PR-added example input NetCDF file (i.e., data/netcdf_dummy.nc contains gridded land use data in the format expected by this PR's code additions. The latitude, longitude, and vegtyp values for grid cell (1,1) match those for the control model run as listed in run/namelist.input in the main branch. Thus, model output from grid cell (1,1) should match the control run while the output from other grid cells may vary. test/analysis/compare_outputnc.py was executed and I observed that all tests passed for grid cell (1,1) while at least one or more tests failed for all other grid cells -- this was the expected result. The output from test/analysis/compare_outputnc.py is: output.txt

The unit tests (test/noahowp_driver_test.f90) were re-executed and output was normal. The output from test/noahowp_driver_test.f90 is: output.txt

NOTES

I'm expecting one gridded model input per NetCDF file. In this case, we can add additional private type-bound subroutines to open and read from specific NetCDF files. Each added type-bound subroutine must make a call to gridinfo_type%ReadSpatialInfo immediately after opening the NetCDF file to ensure that the variable is given on the expected grid.

However, if we elect to assume that all gridded inputs will be provided in a singular NetCDF, this code can be easily modified to facilitate that expectation.

Checklist

• [x] PR has an informative and human-readable title
• [x] Changes are limited to a single goal (no scope creep)
• [x] Code can be automatically merged (no conflicts)
• [x] Code follows project standards (link if applicable)
• [x] Passes all existing automated tests
• [x] Any change in functionality is tested
• [x] New functions are documented (with a description, list of inputs, and expected output)
• [ ] Placeholder code is flagged / future todos are captured in comments
• [ ] Visually tested in supported browsers and devices (see checklist below :point_down:)
• [ ] Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)
• [x] Reviewers requested with the Reviewers tool

[GreyREvenson]

@SnowHydrology, I think we're ready for you to have another look. Note that I revised the PR-description to incorporate your comments. But to address the specific points in your previous comment:

• netcdf_dummy.nc now has valid lat/longs in agreement with provided dx and dy values following revisions to the script used in its creation (test/analysis/create_dummy_netcdf.py)
• The revised netcdf_dummy.nc has the lat, long, and land use values from the test case (i.e., run/namelist.input in main branch) while all other grid cells have different lat, long, and land use values.
• I changed gridlist_type to gridinfo_type