-
Notifications
You must be signed in to change notification settings - Fork 110
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 incr noah #568
Feature/snow incr noah #568
Conversation
to the sfc restarts. Includes screening to apply updates over land only and adjusting SWE to match the snow depth analysis. Also: * made arguments to read_data optional so could use same routine to read JEDI increment field * changed confusing variable names for SNO (-> SWE) and SWE -> (SND)
I don't seem to be able to add reviewers. @barlage and @jiaruidong2017 should be included. |
@ClaraDraper-NOAA Do you have a canned case to test this option? |
@GeorgeGayno-NOAA apologies - I knew there was something I'd forgotten to include, but couldn't figure out what it was. The test case is on hera (see readme for instructions) |
I see the first regression test is failing:
|
Let me have a look, and fix it. |
Great. I was able to get it to run. This should be made into a consistency/regression test? |
I see you added a new variable - LND_SNO_FILE - to the fort.37 namelist. Don't forget to update ./ush/global_cycle.sh accordingly: https://github.com/ClaraDraper-NOAA/UFS_UTILS/blob/feature/snow_incr_Noah/ush/global_cycle.sh#L388 |
There is an issue open to convert |
I think this should be a regression test. Or I could create a single RT with both the soil and snow updates? (this doesn't currently make sense scientifically, but would exercise both bits of code in a single test). |
Will do. |
Let's try separate tests - |
Although not specific to this PR, I see several doxygen warnings for ./lsm_routines.fd/noah.fd/sflx_snippet.f90. I am able to fix them by removing these comment lines:
|
OK. I suspect that the way I've created the mask in calculate_landinc_mask will need to be revised. |
@GeorgeGayno-NOAA I fixed the bug (that took a bit of searching!), and updated the global_cycle_driver scripts with the new namelist variable. The global_cycle regression tests now pass. I'm creating an rg test on hera now. I have an orion account now, so I can do that one too. |
/scratch2/BMC/gsienkf/Clara.Draper/tmp/reg-tests/global-cycle/global_cycle
@GeorgeGayno-NOAA I've done the regression_tests for orion and hera. The files you'll need are on here here: /scratch2/BMC/gsienkf/Clara.Draper/tmp/reg-tests/global-cycle/global_cycle I just ran the tests on orion using the baseline for the new test from hera, and they passed. Note the test makes no science sense, but it should be enough to exercise the code. I used increment files generated during winter (so that the increment would be non-zero) and applied them to the pre-existing background files in boreal summer. If you want something more scientifically sound, we can replace the background for that test with ones for the same day as the increments. I think everything else is ready to go? |
I was able to run your tests on Hera. If you prefer to use winter background files, I have no problem with keeping multiple directories of input data. We already do that for other regression tests. |
@ClaraDraper-NOAA I will check in some minor script updates to your branch. |
@ClaraDraper-NOAA I just merged the latest updates from develop to your branch. I see the consistency test driver scripts need to be updated for Orion, Jet, and WCOSS. I can do WCOSS. |
Thanks @GeorgeGayno-NOAA. I'll do orion and jet later today. |
I have Jet done. Will check in next. Orion is down today. |
@ClaraDraper-NOAA Other than a few minor prolog updates, I have no further comments. I did not look closely at the science behind your updates. I will let @barlage and @jiaruidong2017 check that. |
Thanks @GeorgeGayno-NOAA. I just pushed the changes to the prologue. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's good to me for this PR by adding the snow increments with a proposed basic method. It may require some detailed considerations after the snow increments are available in the future analysis.
Thanks @jiaruidong2017 @ClaraDraper-NOAA I will merge the latest updates from 'develop' to your branch. Then merge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few minor comments.
! to the changes made. Need to store bacground, apply the increments, then make | ||
! secondart adjustments. When updating more than one state, be careful about the | ||
! orfer if increments and secondary adjustments. | ||
LANDINC_MASK_FG = LANDINC_MASK | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume what is happening here is that soil updates are not done where there is snow. Is that stated anywhere? If not, it would be good to have in a comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@barlage I moved the comments below from near the do loop, to the comment block at the top of the add_increment_soil functions.
!! Does not make a temperature update if snow differ
!! between fg and anal (allow correction of snow to
!! address temperature error first), or if snow is present
!! (will eventually updating of snow temperature in this case)
The code also counts, and prints out the number of locations under each case.
STC_BCK = STCFCS | ||
SMC_BCK = SMCFCS ! not used yet. | ||
SLC_BCK = SLCFCS ! not used yet. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason to not generalize this for all three soil states now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not necessary, just wondering if it saves any work in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doing the soil moisture will require knowledge of the soil properties (for re-gridding increments), so I'll need to add them to the increment file output by the GSI. There's a bit of work to do there, so I'm not planning to do it yet (and may even be able to old off until we're using JEDI).
write(*,'(a,i8)') ' (not updated) soil grid cells, no soil nearby on gsi grid = ',nnosoilnear | ||
write(*,'(a,i8)') ' (not updated) soil grid cells, change in presence of snow = ', nsnowchange | ||
write(*,'(a,i8)') ' (not updated yet) snow grid cells = ', nsnowupd | ||
write(*,'(a,i8)') ' grid cells, without soil of snow = ', nother | ||
write(*,'(a,i8)') ' grid cells, without soil of snow = ', nother |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"of" to "or"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should be "or". fixed.
!> Calculate soil mask for land on model grid. | ||
!! Output is 1 - soil, 2 - snow-covered, 0 - land ice or not land. | ||
!! @param[in] lensfc Total numberof points for the cubed-sphere tile. | ||
!> Add soil snow depth increment to model snow depth state, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove "soil"? Also, "genative", "globall" and "screend" below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
do i=1,lensfc | ||
if (swe(i) .GT. 0.001) then | ||
mask(i) = 2 | ||
if (smc(i) .LT. 1.0) then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this to screen water points? what happens for fractional grid? I don't know myself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A soil moisture of 1.0 indicates permanent land ice. I think @ClaraDraper-NOAA does not want to apply the updates at those points.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@barlage I'm not sure what happens for the fractional grid either. I flagged to @GeorgeGayno-NOAA that I didn't think my code would work for fractional grid cells, and I think he's planning to this update this when all of UFS_UTILS is updated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have an issue open to convert this program to process fractional grids - #549.
real :: dens_mean | ||
|
||
! density = swe/snd | ||
density = swe/snd |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any chance of a divide by zero here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think they called the "calc_density" subroutine where the snow present.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't use any of these values is there's no snow, but "no snow" is based on SWE, so it could be possible if we somehow wound up with 0.0 snow depth, and non-zero SWE. I replaced that code with a loop, checking on the SND value, just to make sure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will hold off merging until @ClaraDraper-NOAA addresses the latest comments.
@barlage @GeorgeGayno-NOAA Just pushed responses to Mike's comments. I'll keep an eye on the automatic checks ( there's a small code change to the snow density calculation, but it passed the snow increment reg_test)
I will hold off merging until @ClaraDraper-NOAA addresses the latest comments. |
@ClaraDraper-NOAA Your latest updates to not change the regression tests. I will merge tomorrow morning. |
This addresses issue #561
Addition of routines to add snow depth increments from JEDI output increment file to the sfc restarts. Includes screening to apply updates over land only and adjusting SWE to match the snow depth analysis. Format follows previous approach for soil temperature increments.
Associated changes:
read JEDI increment field
Note: no action is taken if grid cell is a land-ice point. The current snow DA limits snow depth and SWE to be above a minimum value over land-ice, which is also done at every Noah call, so I skipped it.
Also: this won't work with a fractional grid cells, but I don't know enough about how that's handled in the model to address it. I suggest we address this next.