search

ufs-community / ufs-mrweather-app

UFS Medium-Range Weather Application
Other
23 stars 23 forks source link

Update build_global-workflow.sh following global-workflow changes #233

Closed jkbk2004 closed 2 years ago

jkbk2004 commented 2 years ago
  1. Global-workflow allows the build option of UFS_app: S2SWA (default), ATM, ATMA, S2S, and S2SW
  2. build_global-workflow.sh was updated according to the change: updated README.md and usage function in the script
ulmononian commented 2 years ago

built successfully using S2SW and ATM by invoking the "-a $APP" argument. however, as mentioned, when building the default (without an $APP argument), S2SW is built, not S2SWA. per global-workflow PR https://github.com/NOAA-EMC/global-workflow/pull/794, the default if no argument is passed when running "build_all.sh" is S2SWA...

ulmononian commented 2 years ago

coupled tests (built with default app (supposedly S2SWA)and S2SW) fail in gfswaveinit task of workflow. error is:

Lmod has detected the following error: Cannot load module "met/9.1". At least one of these module(s) must be loaded: intel/2020

While processing the following module(s): Module fullname Module Filename

met/9.1            /apps/contrib/modulefiles/met/9.1
module_base.orion  /work/noaa/epic-ps/cbook/MRW_branch_tests/jk_build_update/S2SWA/ufs-mrweather-app/global-workflow/modulefiles/module_base.orion.lua

the log file can be found here: /work/noaa/epic-ps/cbook/coupled/COMROT/2013100100_S2SWA_test/logs/gfswaveinit.log. screencap below.

Screen Shot 2022-05-23 at 11 42 45 AM
ulmononian commented 2 years ago

the same error results when doing an uncoupled (ATM) test: /work/noaa/epic-ps/cbook/uncoupled/COMROT/ATM_test/logs/2018100700/gfsfcst.log. anyone else have success?

Screen Shot 2022-05-23 at 11 55 25 AM
ulmononian commented 2 years ago

I encountered an issue with the load of met/9.1 on Orion in S2SW (coupled, forecast-only) and ATM (uncoupled, forecast only) tests using the develop branch of the global-workflow checked-out through Externals.cfg. The same error is produced in the gfsfcst task of the ATM case and gfswaveinit task of the S2SW case: Screen Shot 2022-05-23 at 11 42 45 AM Screen Shot 2022-05-23 at 11 55 25 AM

I was able to bypass the issue by removing line 55 from module_base.orion.lua (load(pathJoin("met", "9.1"))). When I check the modules loaded by load_fv3gfs_modules.sh when testing outside of runtime, met/9.1 seems to still load despite removing this line:

Screen Shot 2022-05-25 at 8 48 56 AM

The module_base.orion.lua file with the "fix" is within my fork of the global-workflow here: https://github.com/ulmononian/global-workflow/commit/9e245dcf8159fb2b520ccbfa95a151c14e6b980d. MRW-GW tests using this module file run successfully.

ulmononian commented 2 years ago

update to previous comments regarding met/9.1: module_base.orion.lua includes a section w/ a path to walter's modified hpc-stack module files (used as a temporary fix related to a necessary python env./python modules). permissions to this stack path needed to be changed (now adjusted by walter), so the modules load properly. should resolve this problem.

ulmononian commented 2 years ago

S2SW and ATM 24-hour forecast tests pass. locations: /work/noaa/epic-ps/cbook/mrw_work/branch_tests/EXPDIR.

notes: both tests set-up using S2SWA (default) build option of global-workflow. specific app to use for experiment must still be specified when invoking "setup_expt.py" in ush/rocoto. coupled w/ aerosols not tested.