is water_memory remembering correctly? #186
Comments
|
Thanks for noting this Ryan. I suspect you're right. If this remembering
the last 10 days of water content is annoying from a software perspective,
we can always revert to using a deeper soil layer which would in principle
do this integration automatically. CLM uses the 3rd layer, for example. Or,
in the longer term, so can perhaps use one of the metrics from the
hydrodynamics code...
…On 20 February 2017 at 19:04, Ryan Knox ***@***.***> wrote:
Summary of Issue:
water memory remembers the water content of the top soil layer over the
last 10 days. It is remembering the instantaneous water content at 0Z,
which is not a great thing and needs to be fixed. The big problem I see is
the order of operations in how it saves the water content to the array.
First it assigns index 1 from the boundary condition array.
Then it loops through indices 10 down to 2, assigning the values at those
indices from what was in indices 9 to 1.
The problem is that when it is assigning the value to index 2, it is using
the value from one which was over-written. I guess its not a huge deal, it
is just weighting the first index double.
See phenolog() in EDPhysiologyMod.F90,
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#186>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AMWsQ5xaCwwmoxldunRVx_LXW5cYRloFks5rekYygaJpZM4MGy1F>
.
--
------------------------------------------------------------------------
Dr Rosie A. Fisher
Staff Scientist
Terrestrial Sciences Section
Climate and Global Dynamics
National Center for Atmospheric Research
1850 Table Mesa Drive
Boulder, Colorado, 80305
USA.
+1 303-497-1706
http://www.cgd.ucar.edu/staff/rfisher/
|
|
I'm ok with keeping memory aspect of it if you are. I like the idea of using a lower layer as a surrogate for memory/smoothing etc, makes sense. I am a little wary of it only because if we are using different driver models or different layering schemes, the meaning of the third layer will get lost. |
|
It's a bit non-ideal. I tried using BTRAN instead of the third layer soil
moisture a while back and it made very little difference, for example. What
to use for the phenology trigger is a rather large can of worms. We tried
to make CLM5 behave better than CLM4.5, but the dynamics are very sensitive
to the plant hydraulics, redistribution rates, and the threshold, so trying
to keep it in a state where it has sensible behaviour is difficult.
Probably we shouldn't worry about it too much at the moment, and keep the
existing solution in lieu of any solidly better version.
…On 22 February 2017 at 11:21, Ryan Knox ***@***.***> wrote:
I'm ok with keeping memory aspect of it if you are. I like the idea of
using a lower layer as a surrogate for memory/smoothing etc, makes sense. I
am a little wary of it only because if we are using different driver models
or different layering schemes, the meaning of the third layer will get lost.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#186 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AMWsQ7p65gnkXws8pTquJm_ctBbS0ZApks5rfHy5gaJpZM4MGy1F>
.
--
------------------------------------------------------------------------
Dr Rosie A. Fisher
Staff Scientist
Terrestrial Sciences Section
Climate and Global Dynamics
National Center for Atmospheric Research
1850 Table Mesa Drive
Boulder, Colorado, 80305
USA.
+1 303-497-1706 <(303)%20497-1706>
http://www.cgd.ucar.edu/staff/rfisher/
|
|
sounds good to me, thanks Rosie |
bandre-ucar
added a commit
that referenced
this issue
Mar 6, 2017
Merge branch 'rgknox-endrun-maxcohort-weights' In this change-set roughly two objectives are tackled. 1) a wrapper was created to call the CIME shutdown/end-run utitlities. The wrapper is essentially the same wrapper that CLM uses, but we need our own to break dependence. 2) We have various globals in FATES that are dictated by the HLM, and vice versa. I tried to wrangle these variables into FatesInterfaceMod, and give them some functions to set those variables and protect them. Moreover, the new global fates_maxElementsPerSite and fates_maxElementsPerPatch, are calculate based on the maximum requirements for array allocation for FATES restarts. Previously, this was a hard-coded and misleading value. While FATES asks the HLM to allocate a "cohort" array for restart variables, it is really a multi-purpose array, and may be larger than the needs we have to store cohorts. Fixes: #178 and #177 and #144 and #186 Addresses: #141 User interface changes?: No Code review: Testing: rgknox: Test suite: edTest, clm_short_45 Test baseline: 8b2ca7e (PR #176) Test namelist changes: None Test answer changes: b4b with baseline Test summary: all PASS andre Test suite: ed - yellowstone gnu, intel, pgi hobart nag Test baseline: cdb9db7 Test namelist changes: none Test answer: bit for bit Test summary: all tests pass Test suite: clm_short - yellowstone gnu, intel, pgi Test baseline: clm4_5_12_r195 Test namelist changes: none Test answer: bit for bit Test summary: all tests pass
|
Lets keep this issue open for the time being. While #180 did correct the indexing bug, this thread will help us to remember that we should continue to consider alternative ways of tracking available soil water memory. I'm also wondering if maybe we should have a dedicated module in FATES that is in-charge of tracking and averaging input-like variables, one that accepts instantaneous HLM boundary conditions and decides how to average appropriately? |
|
I guess that such a module would be appropriate for use with the fire code,
to make the daily drivers, and for the daily decomposition drivers for the
litter pools. Both currently depend on inputs that are averaged in the HLM,
as far as I know...
…On 6 March 2017 at 17:31, Ryan Knox ***@***.***> wrote:
Lets keep this issue open for the time being. While #180
<#180> did correct the indexing bug,
this thread will help us to remember that we should continue to consider
alternative ways of tracking available soil water memory.
I'm also wondering if maybe we should have a dedicated module in FATES
that is in-charge of tracking and averaging input-like variables, one that
accepts instantaneous HLM boundary conditions and decides how to average
appropriately?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#186 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AMWsQ8Mqn8MxPSDZKJH5akK7cxlmawQ3ks5rjKV0gaJpZM4MGy1F>
.
--
------------------------------------------------------------------------
Dr Rosie A. Fisher
Staff Scientist
Terrestrial Sciences Section
Climate and Global Dynamics
National Center for Atmospheric Research
1850 Table Mesa Drive
Boulder, Colorado, 80305
USA.
+1 303-497-1706
http://www.cgd.ucar.edu/staff/rfisher/
|
|
going through old code, this can be closed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary of Issue:
water memory remembers the water content of the top soil layer over the last 10 days. It is remembering the instantaneous water content at 0Z, which is not a great thing and needs to be fixed. The big problem I see is the order of operations in how it saves the water content to the array.
First it assigns index 1 from the boundary condition array.
Then it loops through indices 10 down to 2, assigning the values at those indices from what was in indices 9 to 1.
The problem is that when it is assigning the value to index 2, it is using the value from one which was over-written. I guess its not a huge deal, it is just weighting the first index double.
See phenolog() in EDPhysiologyMod.F90,
The text was updated successfully, but these errors were encountered: