It may be useful to provide users without access to machines supported by the global-workflow with a simple method to run tests with UFS-WM components (ATM, S2S, S2SW, etc.) within the MRW.
This is motivated by a recent question on the UFS forum (https://forums.ufscommunity.org/threads/using-ufs-mrw-release-newer-version-fv3), wherein a user wanted to utilize an updated FV3 within MRW v1.1. However, as MRW v1.1 uses CIME, there is a high-likelihood that issues would arise due to conflicts from FV3 updates and the CIME infrastructure.
Adding a script-based forecast cycling capability to the UFS MRW repo and applications based on the current UFS-WM rt.sh framework in the coordination with EPIC CM tasks is suggested. This capability will enable users to run simple tests without reference to the global-workflow, and can serve to temporarily ameliorate conflicts between release versions of the MRW and updated UFS-WM components, at least until MRW v2.0 is released.
It may be useful to provide users without access to machines supported by the global-workflow with a simple method to run tests with UFS-WM components (ATM, S2S, S2SW, etc.) within the MRW.
This is motivated by a recent question on the UFS forum (https://forums.ufscommunity.org/threads/using-ufs-mrw-release-newer-version-fv3), wherein a user wanted to utilize an updated FV3 within MRW v1.1. However, as MRW v1.1 uses CIME, there is a high-likelihood that issues would arise due to conflicts from FV3 updates and the CIME infrastructure.
Adding a script-based forecast cycling capability to the UFS MRW repo and applications based on the current UFS-WM rt.sh framework in the coordination with EPIC CM tasks is suggested. This capability will enable users to run simple tests without reference to the global-workflow, and can serve to temporarily ameliorate conflicts between release versions of the MRW and updated UFS-WM components, at least until MRW v2.0 is released.