NDR: which is correct for the `load_n` parameter - fertilizer application or modified export load?

[dcdenu4]

A user brought up a question on the forum about interpreting the n_load parameter. A discussion in a private Slack thread took place between @newtpatrol , @adrianvogl , and @schmittrjp. I'll attempt to capture the questions.

• Should we be providing an export coefficient, such that fertilizer application would need to be adjusted by the retention coefficient to get the load_n parameter?
• Some assume that the n_load parameter would be the amount of N directly applied to a pixel (sum of fertilizer, atmospheric deposition, etc.).

Action items:

• [x] Look over the NDR source code and provide a report of how the n_load parameter is used and what's happening on the load-originating pixel

[phargogh]

I wrote the same thing in slack, so I'll copy it here for reference:

Hey everyone, I’ll add this to the issue as well, but 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:

1. load_n[lucode] * cell_area_ha => load_n.tif
2. load_n.tif * runoff_proxy_index.tif => modified_load_n.tif
3. modified_load_n.tif * (1 - proportion_subsurface_n[lucode]) => surface_load.tif
4. surface_load_n.tif * ndr_n.tif => n_surface_export.tif ( ndr_n.tif is not in any way affected by load_n)
5. 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:

1. modified_load_n.tif * proportion_subsurface_n[lucode] => subsurface_load_n.tif
2. 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.

[dcdenu4]

From the working group in July 2023. Proposal:

Add a column to the biophysical table that lets you flag whether it’s application rate or measured runoff. Would need to update the UG to clarify that’s what we allow.

• This would be a required column, no default value. Error if column not present.
• Having a separate column would allow you to mix behaviors within the model run.
• If application rate given, then model will do the adjustment: applied_nutrient * (1 - retention_efficiency)

Google Doc for reference:

• https://docs.google.com/document/d/1zmjysV88hGwgLBCR-2ZTeCQHc5_RRuHKjW5sm6PYrbg/edit (Stanford Access required)

Software time estimation based on below items (not including UG needs): 1-3 days

• Model logic update
• Model Spec update
• Sample / test data update
• Testing update