Bug fix for bypass_routing_option = 'direct_to_outlet' method

[olyson]

This fixes the balance errors evident in the mosart log file when the bypass_routing_option='direct_to_outlet' method is used.
Note that these balance errors are warnings and do not stop the model.
Code from @swensosc
PR requested by @ekluzek

Fixes #54
Fixes #56

Test case:
/glade/work/oleson/ctsm5.1.dev100/cime/scripts/ctsm51_ctsm51d100_1deg_GSWP3V1_directtooutlet_2000
Note that the test case uses ctsm5.1.dev100 and mosart1_0_45.
Verified that there were no balance errors in the mosart log file.
Testing: Standard mosart test list on cheyenne PASS with expected change in answers for
ERP_D.f10_f10_mg37.I1850Clm50Bgc.cheyenne_intel.mosart-qgrwlOpts

Also don't allow the threshold option to be set with
direct_to_outlet is choosen, as well as any option other
than "all" for "none".

Answers change when direct_to_outlet option is used

[ekluzek]

@olyson does this have everything needed in place? Naoki tried using this branch and was still seeing trouble with direct_to_outlet method for MOSART.

[olyson]

My understanding from Sean is that these two things need to be set in the mosart namelist:

bypass_routing_option = 'direct_to_outlet'
qgwl_runoff_option = 'negative'

[ekluzek]

Note, that Naoki ran into trouble when he ran with qgwl_runoff_option="threshold" and direct_to_outlet, but it works fine when run with negative. @swensosc is there enough of a reason to get the "threshold" option to work with direct_to_outlet? If we leave it as a problem we should document that it's a problem.

[swensosc]

The 'negative' option bypasses the routing model, and sends all negative runoff either directly to the coupler, or to the river mouth (which then goes to the coupler). The 'threshold' option does the additional step of first checking the amount of water in the routing model locally. If there is available water (above a specified threshold, hence the name), that water is used to offset some of the negative runoff. This acts to reduce the amount of negative runoff that is passed to the coupler. That is effectively what is happening in the 'direct_to_outlet' method anyway, so it seems like it would be unnecessary for the 'direct_to_outlet' option.

[ekluzek]

@swensosc should we then remove the "threshold" option for use with direct_to_outlet? Especially, since there are problems when you use it, we might as well disallow its use at least for direct_to_outlet. I'm assuming it's still useful for direct_in_place.

[swensosc]

I thought the 'threshold' option was only implemented for the 'direct_in_place' option (?)

…

On Fri, Oct 7, 2022 at 2:47 PM Erik Kluzek ***@***.***> wrote: @swensosc <https://github.com/swensosc> should we then remove the "threshold" option for use with direct_to_outlet? Especially, since there are problems when you use it, we might as well disallow its use at least for direct_to_outlet. I'm assuming it's still useful for direct_in_place. — Reply to this email directly, view it on GitHub <#57 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGRN57CTAXZ32SLCCM6KTZDWCCD6NANCNFSM57QARA4Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ekluzek]

Perfect that's what I needed to know. I'll disable setting it for anything but direct_i_place.

[ekluzek]

Note this changes answers for the test case: ERP_D.f10_f10_mg37.I1850Clm50Bgc.cheyenne_intel.mosart-qgrwlOpts

 RMS rofImp_Forr_rofi                 3.8131E-06            NORMALIZED  3.2797E+01
 RMS rofImp_Forr_rofl                 8.2276E-06            NORMALIZED  3.6195E+00

My guess is that everything else will be identical

[ekluzek]

The ERS_Ld5.f10_f10_mg37.I2000Clm50BgcCru.cheyenne_intel.mosart-iceOff test is exact and I expect all other tests will be as well.