-
Notifications
You must be signed in to change notification settings - Fork 108
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
Update Earth radius in regional_esg_grid.f90 #538
Update Earth radius in regional_esg_grid.f90 #538
Conversation
@BenjaminBlake-NOAA @JacobCarley-NOAA Please review this PR. |
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.
The changes look good to me, approving now. Thanks Dusan
Thanks for taking care of this. Looks good to me as well. |
Have you run the "grid_gen" regression tests? |
No, I didn't. How do I run the reg tests? |
Under ./reg_tests/grid_gen there are driver scripts for each machine. And make sure you set the 'fix' directories. I ran them on Hera. The 'grid' files have these differences from the baseline:
and the 'oro' file differences:
Are these differences reasonable? |
I have no idea. I don't even know what all those fields are. dx/dy differences (assuming these are in meters) look relatively small. |
The area differences are 0.006% and the dx/dy differences are 0.003% |
I will need to update the baseline for that test on all machines. |
@JeffBeck-NOAA @gsketefian, If this number is changed, the same parameter in 'grid_tools.fd/global_equiv_resol.fd/global_equiv_resol.f90' should be changed (currently, radius_Earth=6371000.0). What do you think of this? |
And it is the same value in |
It's sloppy to have constants in multiple places, and an invitation to mistakes. How to we reduce all constants to one place? |
@DusanJovic-NOAA @edwardhartnett the radius is set in FMS and I believe that's where the dycore gets the value. Not sure if it's cumbersome to do that here (e.g. if this code has an FMS dependency already or not). Here's where it is located:
|
That's where fv3 dycore gets the value. Physics (ccpp) gets the value from: This program (regional_esg_grid.f90) does not depend on FMS, and I think it shouldn't. |
That sounds good to me, at least to start with. Even better if global_equiv_resol.f90 as well as other codes get this and other constants from a single source, as @edwardhartnett suggested. |
@gsketefian @chan-hoo @GeorgeGayno-NOAA, @edwardhartnett, Let's get this value changed in all necessary locations in UFS_UTILS and then work on getting the single-source location handled separately, as that will take more work. @DusanJovic-NOAA, do you mind changing the radius of the earth here: grid_tools.fd/global_equiv_resol.fd/global_equiv_resol.f90 and here: fre-nctools.fd/shared_lib/constant.h to match the new value in the regional_esg_grid code, and push it to this PR? Thanks! |
Does it also need to be changed in the orography source code? I found this line in orog.fd/mtnlm7_oclsm.f: |
|
@DusanJovic-NOAA Yeah I think we want it to be the same everywhere. @JeffBeck-NOAA @gsketefian do you agree? |
@BenjaminBlake-NOAA @DusanJovic-NOAA @JeffBeck-NOAA Yes, same everywhere. Eventually, there should be a single module that all these codes USE that contains the definition of this and other constants, at least for all codes in UFS_UTILS, but I guess that can be in another PR since it requires some more thought and reorganization. One idea is to create a new repo that defines these constants, and all other repos/codes (including UFS_UTILS and ufs-weather-model) clone it and use those definitions, but maybe it's wishful thinking that everyone will agree to that... |
@gsketefian Completely agree about having this radius defined in one place, and another PR makes sense. |
@DusanJovic-NOAA, @BenjaminBlake-NOAA, thanks for finding those remaining locations. @gsketefian, I definitely agree that these constants should be consolidated in one location, whether that be a module file or a separate repo. I'll create an issue along these lines. @DusanJovic-NOAA, can you push a commit to fix those last two locations? Thanks! We'll see how the regression tests look afterward. @BenjaminBlake-NOAA, how are your tests going with the new radius value? |
@JeffBeck-NOAA My initial tests have been unsuccessful, but I only changed the radius in the regional_esg_grid code. I have now made the change in all the other source codes too and am going to try re-running. Hopefully that will fix it! |
@BenjaminBlake-NOAA, thanks! We'll use the results from your tests and the regression test results from @DusanJovic-NOAA's PR to finalize things. |
@JeffBeck-NOAA I'm still having issues getting a successful run with the radius changes. Here are the 7 places in UFS_UTILS that I changed the value to 6371200 m, but maybe I'm missing something? grid_tools.fd/filter_topo.fd/filter_topo.F90 |
After working with @BenjaminBlake-NOAA, I was able to run the SRW App successfully on two different cases with the updates to the earth radius. @BenjaminBlake-NOAA ran another case that was successful. Therefore @DusanJovic-NOAA, can you plase update the other locations for the radius and we'll work on getting this PR reviewed/merged? Thanks! Here are the locations that I see: ./sorc/chgres_cube.fd/model_grid.F90: real(esmf_kind_r8), parameter :: R = 6371200.0 |
Earth radius updated to 6371200 in: sorc/chgres_cube.fd/model_grid.F90 sorc/grid_tools.fd/filter_topo.fd/filter_topo.F90 sorc/orog_mask_tools.fd/orog.fd/mtnlm7_oclsm.f sorc/orog_mask_tools.fd/orog_gsl.fd/module_gsl_oro_data_lg_scale.f90 sorc/orog_mask_tools.fd/orog_gsl.fd/module_gsl_oro_data_sm_scale.f90
@DusanJovic-NOAA, thanks for adding the remaining radius changes. Can you pull the latest develop branch into your branch too? Thanks. |
Thank you @DusanJovic-NOAA! I'm approving this PR as it passes the automated tests and results in successful end-to-end tests with the SRW App. As this is a "bug" fix, no new unit tests are required. |
Any comments on this PR? It's unclear to me how to anticipate exact differences in the grid or orography file regression tests when we're fundamentally changing how those files are created. However, very minor differences to each variable seem reasonable, which is what @GeorgeGayno-NOAA found. |
I have one general comment. Why does the radius difference only cause problems with regional runs? Or has this been a problem with global runs and we just never realized it? |
@GeorgeGayno-NOAA We never would have noticed this in the regional runs if we hadn't been running two (very) different computational domains and then assessing the differences in the forecast output (domain size was the only difference). Even then it took us a while to track this thing down. I'm not sure that there has been any testing/runs that would have revealed this issue in the global. Also, and this is important too, the ESG grid won't work with the global anyway as it's a regional-only capability. |
The baseline data for the grid_gen consistency tests will need to be regenerated. Has that been done? And I see a chgres_cube routine was updated. Will any chgres_cube baseline data need to be regenerated? |
@GeorgeGayno-NOAA, yes, we'll need to recreate the baselines for the grid and chgres_cube tests. I can do that on Hera. I'll point you to the location when it's finished. |
@GeorgeGayno-NOAA, they're here on Hera: /scratch2/BMC/det/beck/FV3-LAM/WORK_DIR. Thanks! EDIT: Well, all tests passed, which is really odd. Can you take a look? My reg_tests directory is here on Hera: /scratch2/BMC/det/beck/FV3-LAM/UFS_UTILS/reg_tests Thanks! |
I also updated them on Hera. That is likely why the tests passed for you. |
Baseline data for chgres_cube and grid_gen consistency tests was updated on Hera, Jet, Orion, WCOSS-Cray and WCOSS-Dell. |
@GeorgeGayno-NOAA, well, that explains it! |
This patch updates Earth radius in regional_esg_grid program to be consistent with the value used in the ufs-weather-model.