-
Notifications
You must be signed in to change notification settings - Fork 312
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Snow density unrealistically large for very thin snowpacks #1280
Comments
looks like we're close to having a fix for the in CTSM5.1. What needs to happen to bring #1283 to main? |
Reading back through #1283 it looks like I had a number of concerns with how that was done, some of which were pretty fundamental – at least if we still want to support the ability to select between multiple snow cover fraction methods. So I think @swensosc was going to rethink the approach. I wonder if we should just drop support for the old snow cover fraction method: This isn't the first time that changes / fixes have been difficult because of these two very different snow cover fraction methods. If I remember correctly, the big issue is that the different snow cover fraction methods operate very differently in terms of the data flow of how they fit in with the rest of the model (e.g., the order in which different terms are calculated that then need to feed into other calculations: what depends on what). Maybe that's not an acceptable solution, but I just wanted to pose that question.... |
how old is the 'old' snow cover fraction. I'm OK to drop it, especially if it's a CLM4 era approach. |
It's the Niu & Yang 2007 as opposed to Swenson & Lawrence 2012. We use the Swenson & Lawrence 2012 approach for both CLM45 and CLM50 by default – so never use the old NiuYang2007 approach by default. But @swensosc and @dlawrenncar should weigh in on the importance of keeping the older approach. |
I think in principle we want to have the ability to use different snow
cover fractions. Perhaps the main cause of the occurrence of large
densities is the fact that snow is updated at multiple times within the
time step, and if snow cover fraction is not concurrently changed, then
they can be inconsistent briefly. But changing snow cover within the time
steps causes problems with accounting for energy conservation, and that is
why it is calculated once per time step. A robust solution would deal with
the snow operator splitting issue, but we don't currently have the
person-power to commit to that. Also, to some degree snow density is a
diagnostic output, so maybe if we calculated the snow density explicitly at
one point in the time step and output that value to history, it wouldn't be
sensitive to these issues.
…On Thu, Nov 4, 2021 at 4:29 PM Bill Sacks ***@***.***> wrote:
It's the Niu & Yang 2007 as opposed to Swenson & Lawrence 2012. We use the
Swenson & Lawrence 2012 approach for both CLM45 and CLM50 by default – so
never use the old NiuYang2007 approach by default. But @swensosc
<https://github.com/swensosc> and @dlawrenncar
<https://github.com/dlawrenncar> should weigh in on the importance of
keeping the older approach.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1280 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGRN57G7HZXGJB6TJ5KBBALUKMJL3ANCNFSM4XXBCRGA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
I just looked back at the code. The difference between the two parameterizations that I alluded to vaguely is: In SnowCoverFractionNiuYang2007Mod.F90, first we need to calculate |
@swensosc do you feel we should do anything about this, or just close it as a wontfix? |
I asked @swensosc about this and this is the response he gave me:
|
Brief summary of bug
Snow densities derived from ctsm history output of H2OSNO and SNOWDP can be unrealistically large (>1000kg/m3)
General bug information
Calculating snow density as rho=h2osno/snowdp from time step frequency history files shows very large values at times when the snowpack is very thin. This typically occurs when the snowpack is unresolved, i.e. snl is 0 but h2osno_no_layers > 0. The issue appears to happen because frac_sno (snow cover fraction) is held fixed throughout the timestep, while h2osno and snow_depth are updated due to phase change and frost deposition. I corrected the behavior by making changes to how snow_depth is calculated during phase change, and using an updated value of frac_sno in the calculation of snowdp.
CTSM version you are using:
Does this bug cause significantly incorrect results in the model's science? ?
Configurations affected:
The text was updated successfully, but these errors were encountered: