chgres_cube, release/public-v2: Soil type issue at land ice vegetation points #246
Comments
… and vegetation type from input data. Addresses Issue ufs-community#246.
|
Do you know why the problem (soil type 0) only happens at land ice points? |
|
Hello. I don't understand how this is a problem with FV3. FV3 is a
dynamical core and has no conception of vegetation type, lakes, or land ice.
…On Mon, Jan 25, 2021 at 1:58 PM GeorgeGayno-NOAA ***@***.***> wrote:
Do you know why the problem (soil type 0) only happens at land ice points?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#246 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMUQRVFAXBTSNFO47V76NA3S3W5NRANCNFSM4WSDLVRQ>
.
|
It's honestly a complete mystery. I've tracked the total number of problem points on the target grid (by checking places where soil type is 0 over land points) and they are remedied by doing a soil type interpolation along with the other land ice to land ice interpolation calls, but then they reappear (the exact same number) after the land, non-land ice interpolation. I confirmed that there are no soil type of 0 at any land points on the input grid, so I'm honestly not sure where those points are originating from. |
Lucas, this is the UFS_UTILS GitHub, not FV3. Unless you're referring to the line where I mention inconsistencies in landmask, in which case I'm referring to the only landmask that we've been provided. I guess that wouldn't actually be FV3 then, it would just be the assumed landmask on the target grid. Edit: Lucas, my apologies. I don't know why I said Larry. |
|
I am referring to this line in the original message.
Due to inconsistencies in landmask between HRRR and FV3, and how HRRR
data handles vegetation and soil type at frozen lakes / land ice points,
some points exist in surface output data with soil type of 0 at land ice
points.
…On Mon, Jan 25, 2021 at 3:46 PM Larissa Reames ***@***.***> wrote:
Hello. I don't understand how this is a problem with FV3. FV3 is a
dynamical core and has no conception of vegetation type, lakes, or land ice.
… <#m_-4298420939195509969_>
Larry, this is the UFS_UTILS GitHub, not FV3.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#246 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMUQRVF2L6PBGERFPFPQMP3S3XKBDANCNFSM4WSDLVRQ>
.
|
Yeah, I realized that after I read your message again and my original post. My apologies. Please see the edit in my reply comment where I clarified that statement. |
|
Thanks :-) |
Do you want me to take a quick look at your branch? |
Sure, you're welcome to do that. More eyes on the problem can never hurt. The branch that I've applied the suggested fix to, but haven't attached to a PR, is feature/chgres_cube_landice_fix. |
|
How do you set "soiltyp_from_climo" (and the other 'from_climo' settings)? |
They're set in the namelist. And to run in to these problems, they should be set to false. This tells the code to interpolate these surface arrays to the target grid and use them instead of the data from the sfc_climo files. |
…0 when using GFS grib2 data Addresses Issue ufs-community#246
…0 when using GFS grib2 data Addresses Issue ufs-community#246
… vegeation type from the input grid on the target grid. Addresses Issue ufs-community#246.
* Correct erroneous "0" soil type at landice points when using soil and vegeation type from the input grid on the target grid. Addresses Issue #246. * Added a test for changes associated soil type fix. Addresses Issue #509 * Test for soilt_fix now compiles and passes. Updates made to ensure all fields and grids are destroyed. * Added short doc for create_static_fields and changed grid in surface_interp test to be regional to fix test crashes in debug mode. * Fix for two arrays that were not deallocated. * Remove one more array that wasn't deallocated and clean up code / add comments. * Added a FieldDestroy command for lai_target_grid * Modify lat/lon of target grid to see if this passes (minus memory leaks) on all platforms. * Update workflow files and make flags to try to get rid of all memory leak errors associated with esmf. * Temporarily removed cache exception for esmf to get it to rebuild with new flags * Reinstate cache functionality for esmf now that new compile with debug and address sanitizer flags is done * Remove cache for esmf again until default esmf build for the repository has the address sanitizer and debug flags turned on. * Fixed missing public declarations in surface * Added ASAN suppression file to suppress new crash due to ESMF. * Added ASAN file to repository. * Change ASAN suppression to a function name in continued attempts to suppress esmf memory errors * Add more possible function names to try to suppress esmf memory errors * More adjustments to ASAN file * More tries at adjusting ASAN suppressions * Upgrade to newer version of ESMF * Move field list in to fieldbundlecreate instead of fieldbundleadd. Reinstate esmf library cache. * Fix syntax error * Change library suppressions to actual library file names * Another change to ASAN suppressions * Remove compilation of surface_interp unit test for now as ESMF memory leaks are causing issues. * Remove ESMF sanitizer and debug flags causing memory leaks with a unit test from a previous PR. * Remove export of LSAN and ASAN suppression files in debug workflow * Revert ESMF version in debug workflow
|
Fix merged, regression tests updated and passing on all systems. Issue closed. |
Due to inconsistencies in landmask between HRRR and FV3, and how HRRR data handles vegetation and soil type at frozen lakes / land ice points, some points exist in surface output data with soil type of 0 at land ice points.
The fix for this, while not ideal, is a brute force method of forcing all grid points with land use type of land ice to have soil type 16 in the qc_check subroutine. I have been unsuccessful, despite many many efforts, to implement a fix by modifying the input data just after reading in, or by making changes in the interp subroutine. Will use this brute force fix for now, but will contact ESMF support before implementing a fix in the develop branch.
The text was updated successfully, but these errors were encountered: