-
Notifications
You must be signed in to change notification settings - Fork 105
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
Feature/snow layer creation threshold #520
Feature/snow layer creation threshold #520
Conversation
Just curious, is the layer creation threshold hardwired? I haven't looked
at the SUMMA code in a while. Since this changes the performance of the
model, the version update would have the potential to require recalibration
for existing implementations. If the threshold becomes a user parameter,
some users could keep it the same or jump to a new default.
…On Tue, Mar 7, 2023 at 11:38 AM Wouter Knoben ***@***.***> wrote:
Make sure all the relevant boxes are checked (and only check the box if
you actually completed the step):
- Closes #xxx (identify the issue associated with this PR)
- Code passes standard test cases (results are either bit-for-bit
identical, or differences are explained in the PR comment)
- New tests added (describe which tests were performed to test the
changes)
- Science test figures (add figures to PR comment and describe the
tests)
- Checked that the new code conforms to the SUMMA coding conventions
<https://github.com/NCAR/summa/blob/master/docs/howto/summa_coding_conventions.md>
- Describe the change in the release notes (use either
./summa/docs/whats-new.md or ./summa/docs/minor-changes.md depending
on what changed)
Test cases
Synthetic test cases complete bit-for-bit identical.
WRR test cases do not, because changes to the snow layering scheme
translate into changes in simulated snow (and related) variables. See
example below. Using the new layering scheme (bottom plot, dashed lines in
both plots) can lead to lower, identical and higher snow depths than the
original scheme gives us. Differences are in the order of centimeters over
a multi-year simulation (second figure).
WIP: add an explanation about why the snow sims are slightly different.
[image: summa_snowLayer_PR]
<https://user-images.githubusercontent.com/45757529/223516145-7d998308-4bf1-468a-a6a4-c74f7a5e27c1.png>
[image: summa_snowLayer_PR_depthDiff]
<https://user-images.githubusercontent.com/45757529/223518198-c56f26eb-7b39-4c7c-88e8-c9bcdffedf7b.png>
------------------------------
You can view, comment on, or merge this pull request online at:
#520
Commit Summary
- a1464f6
<a1464f6>
Changed 1st snow layer creation logic to avoid excessive layer
creation/merging
- c8d3650
<c8d3650>
cleaned up indentation
- 76f293f
<76f293f>
add snow layer change to whats new
File Changes
(2 files <https://github.com/CH-Earth/summa/pull/520/files>)
- *M* build/source/engine/layerDivide.f90
<https://github.com/CH-Earth/summa/pull/520/files#diff-4670a1527c41c5420b741a61af33dbb64336a266f931031d9773028859b1f06c>
(119)
- *M* docs/whats-new.md
<https://github.com/CH-Earth/summa/pull/520/files#diff-9428ccc149911a1fdbacb719bfe6f6e4d0c4fbe84f4ce18d14cdb5cd82b9df45>
(1)
Patch Links:
- https://github.com/CH-Earth/summa/pull/520.patch
- https://github.com/CH-Earth/summa/pull/520.diff
—
Reply to this email directly, view it on GitHub
<#520>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABIKARM5SWRNSB672ZV6XCDW256BTANCNFSM6AAAAAAVS2WLAQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
It's a combination of hard-wired logic and user-defined parameters in Logic lines - summa/build/source/engine/layerDivide.f90 Lines 172 to 188 in a34af36
[...] summa/build/source/engine/layerDivide.f90 Lines 260 to 284 in a34af36
**Logic lines - ** summa/build/source/engine/layerMerge.f90 Lines 136 to 137 in a34af36
[...] summa/build/source/engine/layerMerge.f90 Lines 158 to 173 in a34af36
User-specified parameters:
I'm not a 100% sure but I expect it may be difficult (if not impossible) to mimic the current behavior using the new code and custom parameter values. What are your thoughts on this? Is requiring recalibration a reason to not make this change? |
Ah, I misunderstood - if it's a logic change rather than a
threshold setting change then there could well be a good reason to make
it. I didn't see the reason for the change earlier (a bug in the old
layering scheme? more stability?).
…On Wed, Mar 8, 2023 at 10:09 AM Wouter Knoben ***@***.***> wrote:
It's a combination of hard-wired logic and user-defined parameters in
localParamInfo.txt.
*Logic lines* - layerDivide():
https://github.com/CH-Earth/summa/blob/a34af362b9a9b6c09e72d1e822d58e95ccfa2713/build/source/engine/layerDivide.f90#L172-L188
[...]
https://github.com/CH-Earth/summa/blob/a34af362b9a9b6c09e72d1e822d58e95ccfa2713/build/source/engine/layerDivide.f90#L260-L284
**Logic lines - ** layerMerge():
https://github.com/CH-Earth/summa/blob/a34af362b9a9b6c09e72d1e822d58e95ccfa2713/build/source/engine/layerMerge.f90#L136-L137
[...]
https://github.com/CH-Earth/summa/blob/a34af362b9a9b6c09e72d1e822d58e95ccfa2713/build/source/engine/layerMerge.f90#L158-L173
*User-specified parameters:*
zmin | 0.0100 | 0.0050 | 0.1000
zmax | 0.0500 | 0.0100 | 0.5000
! ---
zminLayer1 | 0.0075 | 0.0075 | 0.0075
zminLayer2 | 0.0100 | 0.0100 | 0.0100
zminLayer3 | 0.0500 | 0.0500 | 0.0500
zminLayer4 | 0.1000 | 0.1000 | 0.1000
zminLayer5 | 0.2500 | 0.2500 | 0.2500
! ---
zmaxLayer1_lower | 0.0500 | 0.0500 | 0.0500
zmaxLayer2_lower | 0.2000 | 0.2000 | 0.2000
zmaxLayer3_lower | 0.5000 | 0.5000 | 0.5000
zmaxLayer4_lower | 1.0000 | 1.0000 | 1.0000
! ---
zmaxLayer1_upper | 0.0300 | 0.0300 | 0.0300
zmaxLayer2_upper | 0.1500 | 0.1500 | 0.1500
zmaxLayer3_upper | 0.3000 | 0.3000 | 0.3000
zmaxLayer4_upper | 0.7500 | 0.7500 | 0.7500
I'm not a 100% sure but I expect it may be difficult (if not impossible)
to mimic the current behavior using the new code and custom parameter
values. What are your thoughts on this? Is requiring recalibration a reason
to not make this change?
—
Reply to this email directly, view it on GitHub
<#520 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABIKARJZOQ23BALX2LQFVQ3W3C4ODANCNFSM6AAAAAAVS2WLAQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
This change should lead to more intuitive logic, but you're right that the PR doesn't mention this yet. I'm still working on it. What we currently have is the following:
If we then look at the case where there are snow layers, the logic is:
So essentially with the current logic, the conditions that lead to creating the first layer would lead to subdividing that layer on the next time step if nothing changes. In other words, the same conditions lead to a different number of snow layers depending on if there are 0 or 1 snow layers when the check is made. This change should lead to more consistent logic in how many snow layers you get for a given snow depth. |
Great change, that will certainly be cleaner :)
…On Wed, Mar 8, 2023 at 10:51 AM Wouter Knoben ***@***.***> wrote:
This change should lead to more intuitive logic, but you're right that the
PR doesn't mention this yet. I'm still working on it.
What we currently have is the following:
- If there are no snow layers (nSnow == 0),
- And "snow-without-a-layer" (stored in scalarSnowDepth) is larger
than the maximum depth we want the first layer to have (
zmaxLayer1_lower),
- Make a new layer.
If we then look at the case where there are snow layers, the logic is:
- If there is exactly one snow layer,
- Set the threshold for sub-dividing this layer to zmaxLayer1_lower
- Then, if mLayerDepth for that 1 layer is > zmaxLayer1_lower,
- Subdivide the layer.
So essentially with the current logic, the conditions that lead to
creating the first layer would lead to subdividing that layer on the next
time step if nothing changes. In other words, the same conditions lead to a
different number of snow layers depending on if there are 0 or 1 snow
layers when the check is made.
This change should lead to more consistent logic in how many snow layers
you get for a given snow depth.
—
Reply to this email directly, view it on GitHub
<#520 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABIKARJBILUWUGH7BLY6T2DW3DBLRANCNFSM6AAAAAAVS2WLAQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Make sure all the relevant boxes are checked (and only check the box if you actually completed the step):
./summa/docs/whats-new.md
or./summa/docs/minor-changes.md
depending on what changed)Test cases
Synthetic test cases complete bit-for-bit identical.
WRR test cases do not, because changes to the snow layering scheme translate into changes in simulated snow (and related) variables. See example below. Using the new layering scheme (bottom plot, dashed lines in both plots) can lead to lower, identical and higher snow depths than the original scheme gives us. Differences are in the order of centimeters over a multi-year simulation (second figure).
WIP: add an explanation about why the snow sims are slightly different.