Open edwardhartnett opened 3 years ago
@GeorgeGayno-NOAA how can we determine whether we can use the GFDL package, and remove this code from UFS_UTILS?
It looks like the GFDL repository has all the files we need. Let me see I can build it within UFS_UTILS.
We can build it for everyone in hpc-stack, so we don't need it in UFS_UTILS. The question is, can we use it as a replacement? That is, can we have hpc-stack install the GFDL package, and take it out of UFS_UTILS?
So I guess you need to drop it in, run the regression tests, and see if you get the correct answers. Also I would suggest you inspect the code and see if there's any changes between what we have been using, and their code.
Also are there other people who's approval we should get, before switching to the GFDL version?
We can build it for everyone in hpc-stack, so we don't need it in UFS_UTILS. The question is, can we use it as a replacement? That is, can we have hpc-stack install the GFDL package, and take it out of UFS_UTILS?
So I guess you need to drop it in, run the regression tests, and see if you get the correct answers. Also I would suggest you inspect the code and see if there's any changes between what we have been using, and their code.
Also are there other people who's approval we should get, before switching to the GFDL version?
UFS_UTILS itself only uses 'make_hgrid' and 'make_solo_mosaic'. It builds 'fregrid' but does not use it. It is a remapping program, so it may be used for postprocessing. We can query the global and regional groups. And our DTC colleagues.
After several attempts, I was able to get v2.18.0 to compile on Hera. I then tested make_hgrid
and make_solo_mosaic
to create a C96 global grid using these commands:
/make_hgrid --grid_type gnomonic_ed --nlon 192 --grid_name C96_grid
and
make_solo_mosaic --num_tiles 6 --dir /scratch2/NCEPDEV/stmp1/George.Gayno/test --mosaic C96_mosaic --tile_file C96_grid.tile1.nc,C96_grid.tile2.nc,C96_grid.tile3.nc,C96_grid.tile4.nc,C96_grid.tile5.nc,C96_grid.tile6.nc
I then reran the same commands using the executables from be60a85. Using the nccmp
command showed differences in the 'grid' files, but they were small. Here are the 'tile1' differences:
Variable Group Count Sum AbsSum Min Max Range Mean StdDev
x / 35 3.9968e-15 2.15383e-13 -5.68434e-14 5.68434e-14 1.13687e-13 1.14194e-16 1.42508e-14
y / 27 7.10543e-15 1.56319e-13 -1.42109e-14 1.42109e-14 2.84217e-14 2.63164e-16 6.60446e-15
dx / 120 -9.60426e-10 4.35393e-08 -4.64206e-09 4.65661e-09 9.29867e-09 -8.00355e-12 8.75719e-10
dy / 132 -9.60426e-10 4.82105e-08 -4.64206e-09 4.65661e-09 9.29867e-09 -7.27596e-12 8.44105e-10
area / 32371 4.09172 615.497 -0.0721021 0.0721021 0.144204 0.000126401 0.0226571
angle_dx / 215 -5.77316e-15 2.09224e-11 -8.17124e-13 8.41993e-13 1.65912e-12 -2.68519e-17 1.97899e-13
angle_dy / 74 -8.52651e-14 2.84217e-11 -3.59535e-12 3.60956e-12 7.2049e-12 -1.15223e-15 8.71649e-13
The 'mosaic' file had a difference in the gridlocation record:
Variable Group Count Sum AbsSum Min Max Range Mean StdDev
gridlocation / 26 1848 2046 -64 117 181 71.0769 48.6916
But that record simply records the test directory in which the files was created. So this is not a problem.
So can we use the GFDL FRE_NCtools package?
So can we use the GFDL FRE_NCtools package?
I don't see why not.
Do we need to get approval or buy-in from others?
Do we need to get approval or buy-in from others?
We can ask other EMC groups if you want. And the DTC.
Yes, please ask everyone you know who is a user.
I've been following along with this conversation so I'll put in my 2 cents: Ideally it would be great to use the GFDL versions of these tools developed there rather than keeping our own static/isolated copies, but I am concerned at our ability to get bug fixes and features into those repositories in a timely manner if they are needed. Can we get assurances that we'd be able to make changes if we need them?
@KateFriedman-NOAA and @BenjaminBlake-NOAA As workflow managers, do you have an opinion?
@GeorgeGayno-NOAA I don't see any issue with using it in the regional workflow, but I'd like to see if @JeffBeck-NOAA or @gsketefian have any comments or concerns.
Now that the UFS SRW App has moved to exclusively using the ESG grid, I believe the only fre-ncutils utility we still actively use in the regional_workflow repository is make_solo_mosaic. I wouldn't anticipate that code changing much in the future, but I do share @mkavulich's concerns. The "make_hgrid" utility is supported in what I'd call "legacy mode" in regional_workflow for now, but we may remove it completely in the future.
So can we use the GFDL FRE_NCtools package? @KateFriedman-NOAA and @BenjaminBlake-NOAA As workflow managers, do you have an opinion?
I'm fine with it, especially the idea of further unifying common tools and stopping duplicate efforts. As with Ben though I'd like to know what @yangfanglin and @junwang-noaa think?
@mkavulich I can't speak for these particular repos, but I have worked a lot with other GFDL repos and they have been extremely receptive to changes. I am confident that we can work with them on their repo. In the unlikely event that we need a change they cannot live with, we can fork at that time.
I also note that the GFDL package is clearly better documented and maintained, and includes testing - our copy does not. Since they are actively using this package, it's clear that they will be making bug fixes and improvements which would also be valuable to our users.
Jun and I started from a tarball in 2016 for the transition of FV3-based GFS from GFDL to EMC. Quick a few utilities/tools had been built within EMC and later by the community using this old version of FRE-NCtool.
It is a good idea to move to the latest GFDL version, but please first check and make sure these utilities/tools that have dependencies on FRE-NCtool are also updated and work correctly.
Fanglin
On Fri, Apr 23, 2021 at 10:02 AM Edward Hartnett @.***> wrote:
@mkavulich https://github.com/mkavulich I can't speak for these particular repos, but I have worked a lot with other GFDL repos and they have been extremely receptive to changes. I am confident that we can work with them on their repo. In the unlikely event that we need a change they cannot live with, we can fork at that time.
I also note that the GFDL package is clearly better documented and maintained, and include testing - our copy does not. Since they are actively using this package, it's clear that they will be making bug fixes and improvements which would also be valuable to our users.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NOAA-EMC/UFS_UTILS/issues/336#issuecomment-825680907, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKY5N2MECZUJRYRD4FBWTL3TKF4XPANCNFSM4YBHSGYQ .
-- Fanglin Yang, Ph.D. Chief, Model Physics Group Modeling and Data Assimilation Branch
NOAA/NWS/NCEP Environmental Modeling Center
https://www.emc.ncep.noaa.gov/gmb/wx24fy/fyang/ https://www.emc.ncep.noaa.gov/gmb/wx24fy/fyang/
Checking in here to see where this went, as I think we will have needs for GFSv17 to regrid cube sphere states/increments for aerosol/snow DA. It looks like fregrid
may be a good option. Are there plans to build that in spack-stack or should we 'promote' it to a GFS utility (meaning it is built when the GFS option is exercised) inside of UFS_UTILS?
In UFS_UTILS we have sorc/fre-nctools.fd which contains three tools:
GFDL programmers originated these tools, and these files are snapshots that were copied in support of UFS releases.
Now GFDL releases these tools (and others) as a stand-alone distribution: https://github.com/NOAA-GFDL/FRE-NCtools
We would like to
The benefits are: