Closed GeorgeGayno-NOAA closed 2 years ago
@KateFriedman-NOAA Does the GFS v16 workflow use the global_chgres
program? If not, I will turn off its compilation.
To coldstart global cycles, the gdas_init
utility from the head of 'develop' should be used.
Can we make this a release as well as a tag?
@KateFriedman-NOAA Does the GFS v16 workflow use the
global_chgres
program? If not, I will turn off its compilation.
No, I just double checked ops logs and while there are references to global_chgres in some downstream wave jobs I don't actually see global_chgres invoked anywhere. I believe you are safe to turn off its compilation in the move to WCOSS2 for GFSv16.
To coldstart global cycles, the
gdas_init
utility from the head of 'develop' should be used.
Roger that!
@GeorgeGayno-NOAA Have you ported chgres_cube to wcoss2? Since chgres_cube needs wgrib2_api, and only wgrib2/2.0.8_mpi has this lib. Kyle in NCO said " libwgrib2_api is in libwgrib.a", however, I tried to remove the libwgrib2_api, but failed.
@GeorgeGayno-NOAA Have you ported chgres_cube to wcoss2? Since chgres_cube needs wgrib2_api, and only wgrib2/2.0.8_mpi has this lib. Kyle in NCO said " libwgrib2_api is in libwgrib.a", however, I tried to remove the libwgrib2_api, but failed.
If you need chgres_cube on WCOSS2, you can use my feature/wcoss2
branch (b0e1a14). See #559 for details. Not all the consistency/regression tests are running yet because we can't host all the required fixed data on WCOSS2. But the tests that are running are passing.
@XianwuXue-NOAA You opened this issue - #552 - to port your GEFS v12 tag. Do you need the chgres_cube from that tag working on WCOSS2? I can help with the port if you are running into problems.
Thanks @GeorgeGayno-NOAA I check the wrong branch, and I will check your feature/wcoss2 branch.
@KateFriedman-NOAA I removed the hard-wired version numbers from the build modules at 3adbfa9. This should satisfy NCO.
Excellent, thanks @GeorgeGayno-NOAA! I updated my clone on Cactus and tested build.ver (source via machine-setup.sh) with build_ufs_utils.sh, it worked:
Kate.Friedman@clogin03:/lfs/h2/emc/global/noscrub/Kate.Friedman/git/feature-ops-wcoss2/sorc> sh build_ufs_utils.sh
+ source ./machine-setup.sh
++ pwd
+ cwd=/lfs/h2/emc/global/noscrub/Kate.Friedman/git/feature-ops-wcoss2/sorc
+ '[' wcoss2 = wcoss_dell_p3 ']'
+ '[' wcoss2 = wcoss_cray ']'
+ cd ufs_utils.fd/sorc
+ ./build_all_ufs_utils.sh
.... Building cycle ....
.... Building emcsfc ....
.... Build system finished ....
+ exit
Note, I changed the cray-mpich
module to cray-mpich/8.1.9
(you were using cray-mpich/8.1.7
). Your build_all_ufs_utils.sh script correctly ingested the override for that module from above. Please see these build logs on Cactus:
/lfs/h2/emc/global/noscrub/Kate.Friedman/git/feature-ops-wcoss2/sorc/ufs_utils.fd/sorc/logs/build_cycle.log
/lfs/h2/emc/global/noscrub/Kate.Friedman/git/feature-ops-wcoss2/sorc/ufs_utils.fd/sorc/logs/build_emcsfc.log
Excellent, thanks @GeorgeGayno-NOAA! I updated my clone on Cactus and tested build.ver (source via machine-setup.sh) with build_ufs_utils.sh, it worked:
Kate.Friedman@clogin03:/lfs/h2/emc/global/noscrub/Kate.Friedman/git/feature-ops-wcoss2/sorc> sh build_ufs_utils.sh + source ./machine-setup.sh ++ pwd + cwd=/lfs/h2/emc/global/noscrub/Kate.Friedman/git/feature-ops-wcoss2/sorc + '[' wcoss2 = wcoss_dell_p3 ']' + '[' wcoss2 = wcoss_cray ']' + cd ufs_utils.fd/sorc + ./build_all_ufs_utils.sh .... Building cycle .... .... Building emcsfc .... .... Build system finished .... + exit
Note, I changed the
cray-mpich
module tocray-mpich/8.1.9
(you were usingcray-mpich/8.1.7
). Your build_all_ufs_utils.sh script correctly ingested the override for that module from above. Please see these build logs on Cactus:/lfs/h2/emc/global/noscrub/Kate.Friedman/git/feature-ops-wcoss2/sorc/ufs_utils.fd/sorc/logs/build_cycle.log /lfs/h2/emc/global/noscrub/Kate.Friedman/git/feature-ops-wcoss2/sorc/ufs_utils.fd/sorc/logs/build_emcsfc.log
I can change the cray-mpich default to 8.1.9.
I can change the cray-mpich default to 8.1.9.
Yes, let's change cray-mpich to 8.1.9. I don't have anyone telling me which one is preferred but I am seeing 8.1.9 being used so let's go to that version until told otherwise. Thanks!
I can change the cray-mpich default to 8.1.9.
Yes, let's change cray-mpich to 8.1.9. I don't have anyone telling me which one is preferred but I am seeing 8.1.9 being used so let's go to that version until told otherwise. Thanks!
Done at 48b9234.
@lgannoaa As we discussed, I can remove all references to 'postmsg' from the branch. What about other utilities, such as 'startmsg' and 'prep_step'?
I will test sfc jobs. @KateFriedman-NOAA , we should coordinate for an effort to remove all jlogfile in the GFS package. There are a few jobs ecflow run that does not run by the rocoto such as gdas and gfs sfc prep.
@lgannoaa I'm going to send another reminder to the component managers about things like this (e.g. retire jlogfile). I'm planning to take care of those items in global-workflow (already started in separate clones).
@KateFriedman-NOAA and @lgannoaa - I removed all references to jlogfile at 91c930b.
@GeorgeGayno-NOAA , Thank you
@KateFriedman-NOAA and @lgannoaa - I removed all references to jlogfile at 91c930b.
Thanks @GeorgeGayno-NOAA ! I did a git pull in my clone's ufs_utils.fd folder and got the updates for your feature/gfsv16.0.0-wcoss2
branch.
@KateFriedman-NOAA I created a release for you - https://github.com/ufs-community/UFS_UTILS/tree/ops-gfsv16.2.0
Got it, thanks @GeorgeGayno-NOAA !
This tag is used by GFS v16 operations. Port it to WCOSS2.
The related global_workflow issue: https://github.com/NOAA-EMC/global-workflow/issues/399
The port of 'develop' will be documented here: #559.