Add option to internally remap gridded forcing data to HRUs, given a set of weights

[wknoben]

Description of feature

Add the option to internally map gridded forcing inputs to HRU-averaged forcing variables, given a set of weights that specify how much each grid cell contributes to the forcing in a given HRU.

A further enhancement would be to also provide an option (possibly through another netCDF input file) to specify further HRU-specific modifications of (some of) the forcing variables, such as temperature lapse rates.

Example implementation of the remapping step exists in mizuRoute: https://github.com/ESCOMP/mizuRoute/blob/main/route/build/src/remap.f90

Description of the problem the feature addresses

With larger domains, specifying all forcing at the HRU level can take a lot of space. This is especially the case when HRU areas are (much) smaller than forcing grid cells, which leads to a duplication of data (see #477 ). Doing the remapping inside SUMMA means that, once appropriate weights are found, the forcing data can live at its native resolution instead of needing to be specified at the HRU level.

Will the proposed feature be backward compatible?

Yes, provided that current forcing reading is implemented as default and that the new internal remapping needs to be activated through a model decision (or similar).

Will the proposed feature change the science results of SUMMA?

No.

[andywood]

How is this different from issue 477? Is it mainly more general, ie going from grids or any arbitrary spatial definition instead of GRUs to HRUs?

[wknoben]

I'd say this is slightly more general yes, though very similar in concept which is why I tagged #477 in the description. Going from GRUs to HRUs can save space, but I think we can take that one step further and go from native forcing resolution to HRUs directly. In the global case we're currently looking at, each GRU contains 1 HRU, but any given forcing grid cell can contain a large number of GRUs, so even at the GRU-level the input files are much larger than the native forcing files.

I wasn't sure if you had specific reason to specify GRU-level forcing outside SUMMA and have GRU-to-HRU mapping inside the code, so it seemed better to open a separate issue. I can merge them if you think we're effectively thinking about the same thing.

[andywood]

I think this is a better generalization of the earlier issue but the same in concept (ie they would achieve the same desired efficiencies, same motivation), and require the same functionality (ie remapping from a potentially coarser forcing source, and applying some internal downscaling, ie lapsing). The one way this one is not sufficiently general is that it seems to specify the source being grids (versus potentially GRUs). I could close the earlier issue with the comment that it has been generalized into this issue, but perhaps better to merge them with the change that an arbitrary spatial input forcing (grids, GRUs, even points), can be mapped to HRUs & GRUs internally.

[wknoben]

I'm happy to move this into #477

The mizuRoute approach has (as far as I understand) the ability to map from arbitrary shape to arbitrary shape, so if we retain that example in whichever issue remains open we have something to base this off. The image at the bottom of this page is what I base this on: https://mizuroute.readthedocs.io/en/latest/Input_data.html#runoff-mapping-data

[andywood]

Either way, up to you :). But we should generalize out from grids (or GRUs). If points can somehow be accommodated (seems easy) then SUMMA can run off station data too. CTSM, incidentally, can run off arbitrary spatial forcing inputs, using esmf-based remapping (mesh files).

[wknoben]

Added a comment to #477 to summarize this discussion, thanks for the input!