L2 L1 resolution compatibility issues in mo_spatial_agg_disaggregation while producing L1 meteorology
Issue
When L2 > L1, mHM downscales the L2 meteorology to generate L1 meteorology. When L2 < L1, mHM upscales the L2 meteorology to generate L1 meteorology. This calculation takes place in mo_spatial_agg_disaggregation.
Refer to figure below. The extent of model input (blue border) varies based on the catchment (grey shadow). In the current form, the mo_spatial_agg_disaggregation upscaling and downscaling routines is based on ceiling function and has following effect -
- (left) Extent of L1 exactly covers L2 extent/ data extent + L2 is a multiple of L1 : correct L1 meteorology
- (centre) Extent of L1 exactly covers L2 extent/ data extent but L2 is NOT a multiple of L1 : errors induced in L1 meteorology as L1 cell gets value of one L2 cell, but still works
- (right) Extent of L1 is not equal to L2 extent/ data extent and L2 is NOT a multiple of L1 : mHM fails in debug mode at mo_spatial_agg_disaggregation
Proposal
The ceiling based downscaling in mo_spatial_agg_disaggregation is incompatible to the latter two scenarios mentioned above. A better alternative would be area based calculation where L0 area (grey shadow) and L2 area/s are used to downscale L2 to L1. This would, in principle, improve scalability compromises previously induced in mHM from L1 meteorology. This corresponds to the approach of SCC in mLM as well.
We should bear in mind that, if accepted, this approach would change the reference for mHM test cases.
Issues in mLM development
Below is a screenshot showing a test case of mLM exhibiting the above issue of incorrect L1 meteorology. The extent was as in the third case, and nodata count is > 0 whenever L2 is not a multiple of L1, during downscaling. However, this is not the case with upscaling although the domain average tmax and tmin calculated from L1 values deviate a bit from what it should be (L1 = 0.05, 0.25). For mLM, a dirty patch has been applied with this commit in mLM fork and resolved issue mhm/mhm#167. However, mLM awaits a better solution from develop at mo_spatial_agg_disaggregation.
