Code and script to create required fix files for coupled model needs to be incorporated into ufs-utils. #143
Comments
|
@DeniseWorthen The first step will be to add these codes to the ./sorc directory and build them. We build using CMake. Also I recommend we add some regression or unit tests for these codes. Are these codes run in OPS? If so, are there any 'ush' scripts that will need to be included? |
|
These codes are all associated with the generation of fixed or initial conditions for the ufs-s2s-model. The product of the weight generation routines (ie, the regridding weights) are also used in post, to regrid the tripole grid to rectilinear grids at different resolutions. There are only two fortran routines included, one for the cice5/6 gridgen and one for the MOM6 gridgen. I do not know CMake. The remaining contents are ncl scripts. I need to understand how general to make these routines. For example, since they're my tools, they point to my directories. They should, if being used to create curated files, point to some baseline area for both input and output. What would a regression test entail? Currently it is a manual process to choose the resolution, create the needed grid files etc. Am I supposed to make this launch as some sort of automatic regression test end-to-end? |
They need to be general so that anyone can use them easily. That is the purpose of UFS_UTILS. So pointing to personal directories is not allowed. Maybe we should set up a google meet to discuss a plan forward. |
|
That would be very useful. I've shared my calendar w/ you so lets find a time that works. Thanks. |
|
Is this issue still active? |
|
Yes, in the sense that the tools still live in my personal repos. I've been updating them all for more general use and have documented how someone would use them on the ufs-weather wiki page. But exactly how and in what form they should be added to ufs-utils has not really been resolved. |
|
OK, to clarify how it would happen:
Let us know when you have determined which tools you would like to promote to UFS_UTILS. |
|
At this point, there is a single Fortran code that is used. The remainder of the tools are either NCL scripts or shell scripts. The real stumbling block for me has been the automated aspect of it. Right now the tools require changes in multiple places to generate files for any individual resolution. The changes are for things like source and output directories or naming strings which indicate the resolution. There is also a cascade of "jobs" but the tools in general are not set up to loop over the various resolutions automatically when controlled by some top-level job script--the workflow aspect of it. |
|
As a first step, I have created a branch of the grid generation tool that uses a generated namelist and compiles and runs for the 1deg resolution. The branch is here: ufsutils. It isn't using CMake and I'm not sure how what else might be required for Doxygen. To run it, edit the OUTDIR_PATH in run_test.sh to a directory you have write permission for. It should generate the namelist (grid.nml), compile and run the code. The expected output are 3 files called The The additional configurations can be run by adding additional information in the run_test.sh (I've commented out the generation of the 1/4 deg grid). Let me know what the next steps might be. |
|
@DeniseWorthen What is this issue? Can we close it? Or rename it? |
|
@GeorgeGayno-NOAA This was the original issue I created that was meant to bring the required functionality to ufs-utils. As you can see, it is more than a year old. I can edit the title since at this point, what needs to be added is a single fortran code and associated script. |
DeniseWorthen
changed the title
|
@DeniseWorthen I would link to Jun's notes (https://docs.google.com/document/d/13ui4P_vE2ejVn1fsMnRdoHgjaUf8d5u_-_S4nOvcWOA/edit?usp=sharing) in the description section at the top: |
|
@GeorgeGayno-NOAA In order to successfully compile, ESMF 8.2.0 had to be used instead of ESMF 8.1.0: https://github.com/MinsukJi-NOAA/UFS_UTILS/blob/feature/cpld_gridgen2/modulefiles/build.hera.intel#L32. Do you think this will be an issue for other utilities? |
|
The newer esmf is required because of a simple fix Gerhard made to access |
Don't know. Our unit and consistency tests will tell us of any problems. |
|
@GeorgeGayno-NOAA grid_gen
|
I can create the new baselines. |
|
George, my doxygen build branch fails the debug build action, saying that: This module contains two SRs, each of which has an input file name |
@DeniseWorthen This situation occurs in many of our chgres_cube modules. So I don't know why you are having problems. I am unable to reproduce the problem on Hera or WCOSS-Dell, unfortunately. One thing I noticed - your doxygen statements for routine apply_topoedits are placed after the subroutine declaration statement. Move them before that statement and see if that helps. |
|
Thanks @GeorgeGayno-NOAA. I'll try that. I'll fix the same issue in other SRs too (first doxygen statements, then subroutine statement). Another question---do I really need to document each SR w/ me as the author? I followed the chgres example but in that case maybe you do have other authors? |
We want an author for each routine. If you don't know the author, use a point-of-contact as the author. If there are multiple authors, name all of them. |
|
Your fix for placing the doxygen block before the subroutine statement worked. I'm now able to build the docs and leave the WARN_AS_ERROR set YES. I'll bring the doxygenated code back to the main branch I'm working from and then start thinking about the unit test. |
Great. That was just a guess. |
|
OK thanks---I must be going blind. |
|
I placed the baseline and fix data on Jet under the role account directory - |
|
I see that Jet also requires |
|
Regression tests are working for all 3 platforms: Hera, Orion and Jet. @GeorgeGayno-NOAA I am guessing the Hera baselines were copied to Orion and Jet. Orion is Then copying |
Done! |
|
Suggestion: can you make the compilation of the repository optional? |
Done. |
|
https://github.com/MinsukJi-NOAA/UFS_UTILS/tree/feature/cpld_gridgen2 has been updated to the latest NOAA-EMC/UFS_UTILS/tree/develop. A PR can be made to NOAA-EMC/UFS_UTILS once @DeniseWorthen's unit test changes are merged in. |
|
I'll merge your changes, Thanks so much! |
|
@MinsukJi-NOAA I tried your branch (46ea554) on Orion. The script failed at the 'ulimit -s unlimited' step. For some reason, Orion does not let me set the ulimit from the interactive nodes. If I remove that line from rt.sh, everything worked. Did you need to use 'ulimited' on Orion? It may not be needed. For some regression tests, using ulimited is required. I got around this problem by setting the ulimit in the child scripts. For example: But I would understand if you don't want to add a ulimit command to your 'ush' script. |
|
@GeorgeGayno-NOAA Do you think this unlimited issues is specific to your account? I just ran the regression test successfully on Orion. |
I just tried running under our role account. It worked. So, there is something odd about my account. You don't need to make any changes. |
|
All regression tests are run off the cron each day on supported machines using this driver script - https://github.com/ufs-community/UFS_UTILS/blob/develop/reg_tests/rt.sh. Other regression tests create a small 'summary.log' file at the very of its processing. This driver script searches for the existence of this 'summary.log' file to determine when a test has completed. An example of this file from the global_cycle test: We can discuss more at today's meeting. |
@GeorgeGayno-NOAA Is summary.log generated only when all tests pass? In other words, if one of the tests fails, summary.log does not get generated? |
Always generate the summary log. List all tests whether they failed or passed. |
from a driver script. Fixes ufs-community#143.
Fixes ufs-community#143.
Updated Issue and Action Plan is documented here
Original issue description:
The following tools need to be integrated into ufs_utils:
CICE5_ICgen: initial condition generation for cice5/cice6
CICE5_gridgen: grid condition generation for cice5/cice6
WeightGen: weight generation for grid->grid transformations containing
a) gen_fixgrid and associated fortran code: a fortran routine to read the MOM6 supergrid and create a netcdf file which is
the basis for the remaining transformations
b) generate_iceocn_weights.ncl: esmf weight generation for tripole:tripole or tripole:rectilinear or other grid:grid transformations
c) generate_icemesh.ncl: generation of the ice_mesh for use by the CMEPS mediator
d) generate_frac_land_weights.sh: generation of the frac_land weights (the ocean mask on the fv3 grid) using ESMF_RegridWeightGen
e) make_frac_land.ncl: creation of the 6-tiled land_frac files
For more details, see Jun's notes: https://docs.google.com/document/d/13ui4P_vE2ejVn1fsMnRdoHgjaUf8d5u_-_S4nOvcWOA/edit?usp=sharing
This work requires the use of ESMF 8.2.0. That upgrade will be done under this issue:
The text was updated successfully, but these errors were encountered: