Need some changes to avoid negative h2osoi_ice in UpdateState_TopLayerFluxes #1979
Comments
In UpdateState_TopLayerFluxes, there is a somewhat arbitrary epsilon used to determine if h2osoi_ice and h2osoi_liq are close enough to zero that they should be truncated to zero. If the state remains negative after this truncation, we deem this to be a problem. It seems that this tolerance is occasionally exceeded, leading runs to abort. Since this tolerance is somewhat arbitrary, we will loosen it by an order of magnitude. Resolves ESCOMP#1979 Note that, although the issue was only reported for h2osoi_ice, I am changing the tolerance for both liq and ice so they remain consistent.
|
From discussion with @olyson and @swensosc - We're going to loosen the tolerance further to 1e-10 in the hopes that we'll avoid this problem moving forward. If this problem crops up again, see code in CTSM/src/biogeophys/SoilFluxesMod.F90 Lines 307 to 359 in 4e126c7 |
|
@olyson and @swensosc - I woke up this morning wondering if I could find a relatively easy solution that would get more to the heart of the problem, and spent a bit of time looking into this - though didn't want to spend too long on it (analyzing, developing & testing), so where I currently stand is about where we were yesterday – that, for now, we should just loosen the tolerance. However, I'm inclined to loosen it even more than we suggested - to 1e-9 rather than 1e-10. Are you comfortable with that? I figure that a reduction in state by a factor of 1 billion is effectively reducing the state to 0, so we might as well set it to exactly 0. That said, I'll document here the thoughts I had this morning in case we want to come back to this - or in case either of you think this is worth pursuing further here. I started with the assumption that the problem is arising due to big differences in the original h2osoi_liq vs h2osoi_ice. (Before pursuing this further, it would probably be worth testing that assumption by printing the original h2osoi_liq as well as h2osoi_ice in the problem point.) If so, a solution could be to check if the intent is to bring the total state to 0, and if so, adjust each individual flux to accomplish that. Specifically, it looks like a solution could be: when we see that I think that this solution would be relatively easy to implement, but then I noticed another possible reason why we might need a looser tolerance for urban: because the application of evaporation_limit that I think matters here is So that realization led me to feel like maybe we just want to go ahead and loosen the tolerance like we discussed yesterday, since I can see multiple possible reasons for the old tolerance to be exceeded and I'm still not sure it's worth the time to dig into this further. But I wanted to run this by you to make sure you're still happy with this plan. |
|
I printed out h2osoi_liq for the problematic point as part of the error message: 563: c, lev_top(c) = 96 0 So, h2osoi_liq_top_orig is about four orders of magnitude larger than h2osoi_ice_top_orig. |
|
I am still okay with the plan to loosen the tolerances. Thanks for your
explanation.
…On Wed, Apr 5, 2023 at 5:23 PM Bill Sacks ***@***.***> wrote:
@olyson <https://github.com/olyson> and @swensosc
<https://github.com/swensosc> - I woke up this morning wondering if I
could find a relatively easy solution that would get more to the heart of
the problem, and spent a bit of time looking into this - though didn't want
to spend too long on it (analyzing, developing & testing), so where I
currently stand is about where we were yesterday – that, for now, we should
just loosen the tolerance. *However, I'm inclined to loosen it even more
than we suggested - to 1e-9 rather than 1e-10. Are you comfortable with
that?* I figure that a reduction in state by a factor of 1 billion is
effectively reducing the state to 0, so we might as well set it to exactly
0.
That said, I'll document here the thoughts I had this morning in case we
want to come back to this - or in case either of you think this is worth
pursuing further here.
I started with the assumption that the problem is arising due to big
differences in the original h2osoi_liq vs h2osoi_ice. (Before pursuing this
further, it would probably be worth testing that assumption by printing the
original h2osoi_liq as well as h2osoi_ice in the problem point.) If so, a
solution could be to check if the intent is to bring the total state to 0,
and if so, adjust each individual flux to accomplish that. Specifically, it
looks like a solution could be: when we see that qflx_ev_snow (or
qflx_evap_soi for urban) exceed evaporation_limit, set a logical flag on
this patch; if this is set, then have a different code path that sets both
liqevap and solidevap to take away the entire liquid or solid state
(respectively).
I think that this solution would be relatively easy to implement, but then
I noticed another possible reason why we might need a looser tolerance for
urban: because the application of evaporation_limit that I think matters
here is qflx_evap_soi(p) = qflx_evap_soi(p) -
frac_sno_eff(c)*(evaporation_demand - evaporation_limit) rather than just qflx_ev_snow(p)
= evaporation_limit.
So that realization led me to feel like maybe we just want to go ahead and
loosen the tolerance like we discussed yesterday, since I can see multiple
possible reasons for the old tolerance to be exceeded and I'm still not
sure it's worth the time to dig into this further. But I wanted to run this
by you to make sure you're still happy with this plan.
—
Reply to this email directly, view it on GitHub
<#1979 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGRN57BK43LLL7KZF5PMTN3W7X5HZANCNFSM6AAAAAAWQRD3CM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
As I discussed with @olyson yesterday: based on the numbers he provided, I am going to go with the solution I mentioned in my earlier comment:
because I think this will be a more robust fix that will help prevent this issue from coming up again in the future. |
billsacks
changed the title
Occasionally, h2osoi_ice was going significantly negative in UpdateState_TopLayerFluxes - see ESCOMP#1979. As noted in that issue, this seems to be due to h2osoi_ice having a very different magnitude from h2osoi_liq, leading to greater-than-roundoff-level differences from zero final state in a relative sense (i.e., relative to the magnitude of h2osoi_ice) - I think because of the appearance of the sum (h2osoi_ice + h2osoi_liq) in the equations that limit fluxes. To try to deal with this, I have reworked the handling of the evaporation constraint to directly limit both the liqevap and solidevap, so that both of them should result in the equivalent liq or ice states going to 0 within roundoff. To do that, I needed to move the partitioning of the total flux into liquid and solid to earlier in the subroutine and then recalculate those partitioning fluxes in conditions where we're applying an evaporation constraint. Note that the deleted lines in this commit have just been moved as-is to earlier in this subroutine.
Occasionally, h2osoi_ice was going significantly negative in UpdateState_TopLayerFluxes - see ESCOMP#1979. As noted in that issue, this seems to be due to h2osoi_ice having a very different magnitude from h2osoi_liq, leading to greater-than-roundoff-level differences from zero final state in a relative sense (i.e., relative to the magnitude of h2osoi_ice) - I think because of the appearance of the sum (h2osoi_ice + h2osoi_liq) in the equations that limit fluxes. To try to deal with this, I have reworked the handling of the evaporation constraint to directly limit both the liqevap and solidevap, so that both of them should result in the equivalent liq or ice states going to 0 within roundoff. To do that, I needed to move the partitioning of the total flux into liquid and solid to earlier in the subroutine and then recalculate those partitioning fluxes in conditions where we're applying an evaporation constraint. Note that the deleted lines in this commit have just been moved as-is to earlier in this subroutine.
Rework handling of evaporation constraint in SoilFluxes Occasionally, h2osoi_ice was going significantly negative in UpdateState_TopLayerFluxes - see ESCOMP#1979. As noted in that issue, this seems to be due to h2osoi_ice having a very different magnitude from h2osoi_liq, leading to greater-than-roundoff-level differences from zero final state in a relative sense (i.e., relative to the magnitude of h2osoi_ice) - I think because of the appearance of the sum (h2osoi_ice + h2osoi_liq) in the equations that limit fluxes. To try to deal with this, I have reworked the handling of the evaporation constraint to directly limit both the liqevap and solidevap, so that both of them should result in the equivalent liq or ice states going to 0 within roundoff. To do that, I needed to move the partitioning of the total flux into liquid and solid to earlier in the subroutine and then recalculate those partitioning fluxes in conditions where we're applying an evaporation constraint. Note that I applied a max of 0 to the new fluxes because many initial conditions files have roundoff-level negative H2OSOI_LIQ, so without this limit, we were getting roundoff-level negative fluxes. Resolves ESCOMP#1979
Rework handling of evaporation constraint in SoilFluxes Occasionally, h2osoi_ice was going significantly negative in UpdateState_TopLayerFluxes - see ESCOMP#1979. As noted in that issue, this seems to be due to h2osoi_ice having a very different magnitude from h2osoi_liq, leading to greater-than-roundoff-level differences from zero final state in a relative sense (i.e., relative to the magnitude of h2osoi_ice) - I think because of the appearance of the sum (h2osoi_ice + h2osoi_liq) in the equations that limit fluxes. To try to deal with this, I have reworked the handling of the evaporation constraint to directly limit both the liqevap and solidevap, so that both of them should result in the equivalent liq or ice states going to 0 within roundoff. To do that, I needed to move the partitioning of the total flux into liquid and solid to earlier in the subroutine and then recalculate those partitioning fluxes in conditions where we're applying an evaporation constraint. Note that I applied a max of 0 to the new fluxes because many initial conditions files have roundoff-level negative H2OSOI_LIQ, so without this limit, we were getting roundoff-level negative fluxes. Resolves ESCOMP#1979
Rework handling of evaporation constraint in SoilFluxes Occasionally, h2osoi_ice was going significantly negative in UpdateState_TopLayerFluxes - see ESCOMP#1979. As noted in that issue, this seems to be due to h2osoi_ice having a very different magnitude from h2osoi_liq, leading to greater-than-roundoff-level differences from zero final state in a relative sense (i.e., relative to the magnitude of h2osoi_ice) - I think because of the appearance of the sum (h2osoi_ice + h2osoi_liq) in the equations that limit fluxes. To try to deal with this, I have reworked the handling of the evaporation constraint to directly limit both the liqevap and solidevap, so that both of them should result in the equivalent liq or ice states going to 0 within roundoff. To do that, I needed to move the partitioning of the total flux into liquid and solid to earlier in the subroutine and then recalculate those partitioning fluxes in conditions where we're applying an evaporation constraint. Note that I applied a max of 0 to the new fluxes because many initial conditions files have roundoff-level negative H2OSOI_LIQ, so without this limit, we were getting roundoff-level negative fluxes. Resolves ESCOMP#1979
Rework handling of evaporation constraint in SoilFluxes Occasionally, h2osoi_ice was going significantly negative in UpdateState_TopLayerFluxes - see ESCOMP#1979. As noted in that issue, this seems to be due to h2osoi_ice having a very different magnitude from h2osoi_liq, leading to greater-than-roundoff-level differences from zero final state in a relative sense (i.e., relative to the magnitude of h2osoi_ice) - I think because of the appearance of the sum (h2osoi_ice + h2osoi_liq) in the equations that limit fluxes. To try to deal with this, I have reworked the handling of the evaporation constraint to directly limit both the liqevap and solidevap, so that both of them should result in the equivalent liq or ice states going to 0 within roundoff. To do that, I needed to move the partitioning of the total flux into liquid and solid to earlier in the subroutine and then recalculate those partitioning fluxes in conditions where we're applying an evaporation constraint. Note that I applied a max of 0 to the new fluxes because many initial conditions files have roundoff-level negative H2OSOI_LIQ, so without this limit, we were getting roundoff-level negative fluxes. Resolves ESCOMP#1979
Brief summary of bug
In UpdateState_TopLayerFluxes, there is a somewhat arbitrary epsilon used to determine if h2osoi_ice and h2osoi_liq are close enough to zero that they should be truncated to zero. If the state remains negative after this truncation, we deem this to be a problem. It seems that this tolerance is occasionally exceeded, leading runs to abort. Since this tolerance is somewhat arbitrary, we will loosen it by an order of magnitude.
General bug information
CTSM version you are using: Recent versions
Does this bug cause significantly incorrect results in the model's science? No
Configurations affected: Unknown
Details of bug
For details, see comments in #1253 starting with #1253 (comment)
See also #988
The text was updated successfully, but these errors were encountered: