ncar/ufs-weather-model

UFS Weather Model

ufs-weather-model

This is the UFS weather model source code

Where to find information

Start at the wiki which has quick start instructions.

User's reference guide is hosted on read the docs.

What files are what

The top level directory structure groups source code and input files as follow:

File/directory	Purpose
LICENSE.md	A copy of the GNU Lesser General Public License, Version 3.
README.md	This file with basic pointers to more information.
NEMS/	Contains NOAA Environmental Modeling System source code and nems compset run scripts.
CMEPS-interface/	Contains CMEPS mediator
FV3/	Contains FV3 atmosphere model component including FV3 dynamical core, dynamics to physics driver, physics and IO.
DATM/	Contains Data Atmosphere model component
WW3/	Contains community wave modeling framework WW3.
MOM6-interface/	Contains MOM6 ocean model component
CICE-interface/	Contains CICE sea-ice model component including CICE6 and Icepack
stochastic_physics/	Contains the stochastic physics source code.
cmake/	Contains compile option files on various platforms.
modulefiles/	Contains module files on various platforms.
tests/	Regression and unit testing framework scripts.
build.sh	Script to build the model executable. (also used by tests/)

E.g. use of build.sh to build the coupled model with FV3_GFS_v15p2 as the CCPP suite.

$> CMAKE_FLAGS="-DAPP=S2S" CCPP_SUITES="FV3_GFS_v15p2" ./build.sh

The build system is regularly tested with Tier-1 and Tier-2 platforms. Configurations for other platforms that are available with UFS should be used with the understanding that they are not regularly tested and users will have to adapt those to make it work.

Disclaimer

The United States Department of Commerce (DOC) GitHub project code is provided on an "as is" basis and the user assumes responsibility for its use. DOC has relinquished control of the information and no longer has responsibility to protect the integrity, confidentiality, or availability of the information. Any claims against the Department of Commerce stemming from the use of its GitHub project will be governed by all applicable Federal law. Any reference to specific commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply their endorsement, recommendation or favoring by the Department of Commerce. The Department of Commerce seal and logo, or the seal and logo of a DOC bureau, shall not be used in any manner to imply endorsement of any commercial product or activity by DOC or the United States Government.

ufs-weather-model's Issues

No regression test for newly added Ferrier-Aligo MP

When #1, the regression test configuration files were added to the repo, but no entry was made in any of the rt*.conf files. It was agreed that the test should go in rt_ccpp_dtc.conf, for example like this:

# Compile with CCPP - dynamic mode
COMPILE | CCPP=Y REPRO=Y | standard | hera.intel | |
# Run tests, input data currently only available on Theia
RUN | fv3_ccpp_regional_c768_FA_update_moist | standard | |

fv3_ccpp_gfdlmp threading issue for dynamic CCPP build

The fv3_ccpp_gfdlmp regression test setup hangs on macOS for the dynamic CCPP build after the initialization if more than one thread is used. The fv3_gfdlmp (i.e. the non-CCPP test) works fine, and so does the static CCPP build. This problem does not occur for the fv3_ccpp_control test.

Revert submodule for WW3 to use authoritative repository

Change back from NCAR gmtb-ww3 to NOAA-EMC WW3.

dt/develop: new regression test fv3_ccpp_gsd_sar_v1 failing

This test was added in PR #45, but failed because of a missing file parm/ccpp_gsd_sar_v1.nml.IN.

This does not effect any of the other tests.

Regression tests using csawmg crashing with GNU compilers

All regression tests involving csawmg (with or without SHOC) are crashing with the GNU compilers. This used to be the case on Theia and Cheyenne with versions 6.x and macOS with versions 6.x/7.x. Needs to be retested on Cheyenne and macOS with newer versions of the compiler.

SDF basic documentation

(Transferred from https://github.com/NCAR/NEMSfv3gfs/issues/97)

Now that SDFs reside in host model repositories and given their propensity to multiply during testing, I think that it would be a good idea to provide some kind of high level documentation on what the suites represent more than just relying on the name of the file. Are comments allowable in the SDFs? Failing that (or in addition), could there be one text file in the /ccpp/suites directory that lists the suites in the repo and what they are and how they differ? Right now, for folks outside of GMTB, I imagine that it is pretty difficult to get a feel for what the suites are and how they differ -- basically they have to read through the SDFs line by line and compare.

From @climbfuji:
Comments are allowed:

Sounds like a very good idea for the UFS release.