Hey @dhooper,
Thanks for taking the time and care to work through the NDR logic. It’ll take us a little bit to parse and get something satisfying back, but we will be taking a look. In the meantime, one of our software engineers logged the steps the code is taking as it pertains to load_n, back when this topic first was posted and I thought it might be helpful to share that in this thread.
…here’s what I’m seeing relating to the load_n parameter as it’s traced through the model. I’ll just list out the files that it affects below as a list of pixel-stack raster calculator operations:
load_n[lucode] * cell_area_ha => load_n.tif
load_n.tif * runoff_proxy_index.tif => modified_load_n.tif
modified_load_n.tif * (1 - proportion_subsurface_n[lucode]) => surface_load.tif
surface_load_n.tif * ndr_n.tif => n_surface_export.tif ( ndr_n.tif is not in any way affected by load_n)
n_surface_export.tif + n_subsurface_export.tif => n_total_export.tif
And since the subsurface calculations derive from modified_load_n.tif, which uses load_n, those are calculated as:
modified_load_n.tif * proportion_subsurface_n[lucode] => subsurface_load_n.tif
subsurface_load_n.tif * sub_ndr_n.tif => n_subsurface_export.tif
In short, I do not see any place in the code where load_n or its derivatives are used in a way that is different from what is defined in the user’s guide.
More soon!