Nan in Xinanjiang option

[lcunha0118]

According to the NWM parameters, satdk and satpsi can be zero (for example, over water). When that is the case, max_tension_water_m and tension_water_m are zero, and runoff which is a function of tension_water_m/max_tension_water_m becomes NaN. See following line:

cfe/src/cfe.c

Line 580 in d47547c

pervious_runoff_m = water_input_depth_m * (1.0 - pow((0.5 + parms->a_Xinanjiang_inflection_point_parameter),

Current behavior

Output nan for runoff on the Xinanjiang_partitioning_scheme function

Expected behavior

I am not sure what is the best route for the solution here since satdk and satpsi equal to zero might not be realistic but have been used in previous versions of the NWM. If satdk and satpsi equal to zero are trying to represent impervious area, or water surface, then a different function of rainfall runoff conversion should be used (instead of the Xinanjiang_partitioning_scheme). Maybe a constant runoff ratio (0.95). Another option is to convert satdk or satpsi to a very small number within the code when they are zero.

Steps to replicate behavior (include URLs)

1. The error was observed when satdk and satpsi are equal to zero in the configuration file.

Screenshots

[andywood]

@ Luciana, I know this was discussed yesterday and I had to leave before hearing the solution. I face this issue all the time when setting up inputs on a large domain where spatial aggregation or disaggregation of the modeling fabric can lead to mismatches between cells/catchments the model tries to run as 'land' but the attribute, parameter or forcing processing fails to generate valid values for -- usually around boundaries w/ water. My usual solution is to first standardize the modeling land/water[/urban] mask in the processing so that every modeled cell, even on a coastline or lakeshore, is forced to have valid or at least plausible values. Otherwise the model needs to check every input to insert a workable default value when the input is bad (which is an option as you suggest -- but can cover up input problems you may want to know about). One strategy in the param processing is adding a step to furr out the shoreline edges of the base fine-grid param sources so that they don't produce zeros or nans when aggregated to the model fabric; another is forcing cells that are part water / part land to take on the fractional mean land value (using python functions like nanmean() vs mean() for instance)). A last resort is fixing the input values manually (ie, borrowing the nearest valid cell value), which might be ok for a one-off application. --Andy

…

On Thu, May 19, 2022 at 5:35 PM lcunha0118 ***@***.***> wrote: According to the NWM parameters, satdk and satpsi can be zero (for example, over water). When that is the case, max_tension_water_m and tension_water_m are zero, and runoff which is a function of tension_water_m/max_tension_water_m becomes NaN. See following line: https://github.com/NOAA-OWP/cfe/blob/d47547cc73225ff5dfc8a49249f59c057ee54fe3/src/cfe.c#L580 Current behavior Output nan for runoff on the Xinanjiang_partitioning_scheme function Expected behavior I am not sure what is the best route for the solution here since satdk and satpsi equal to zero might not be realistic but have been used in previous versions of the NWM. If satdk and satpsi equal to zero are trying to represent impervious area, or water surface, then a different function of rainfall runoff conversion should be used (instead of the Xinanjiang_partitioning_scheme). Maybe a constant runoff ratio (0.95). Another option is to convert satdk or satpsi to a very small number within the code when they are zero. Steps to replicate behavior (include URLs) 1. The error was observed when satdk and satpsi are equal to zero in the configuration file. Screenshots — Reply to this email directly, view it on GitHub <#61>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABIKARNMZE63KQEUKBCCO4LVK3F3LANCNFSM5WNX4PDQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[SnowHydrology]

@andywood, that's a really good point you bring up. None of our implemented subsurface modules have logic implemented that would determine valid parameter values and/or whether they make sense for a given land cover type. In @lcunha0118's example, these are likely basins with water cells in the NWM. Noah-MP in the NWM would run these as lakes, meaning there is no issue caused by satdk = 0 or satpsi = 0. It is unlikely that a whole Nextgen basin is a lake (in most cases, at least), so we will need to identify a robust method moving forward.