Using the UFS-MRW release with a newer version of FV3

Submitted by mwong on Wed, 06/01/2022 - 22:22
Forums
Medium-range Weather Application

Hi there,

Has anyone tried using a newer version of FV3 with the UFS-MRW app release? I'm using the V1.1 release version of the MRW App and would like to pull a newer version of FV3, one that is used in the SRW App develop branch. Would there be any potential compatibility issues?

I'm also still polishing my git skills... so if anyone has any pointers in terms of how best to pull a newer version of FV3 into my clone of the UFS-MRW release, I would also really appreciate them!

Thanks,

May

Permalink

Submitted by ligia.bernardet on Sun, 06/05/2022 - 19:04

Hi May, 

I am ver skeptical that this would work.

If you want a newer version of the UFS Weather Model to use with the UFS MRW App, I suggest you wait a few weeks because EPIC is due to release the UFS MRW App in June 2022.

 

Best,

Ligia

Permalink

Submitted by ligia.bernardet on Wed, 06/08/2022 - 14:59

Hi May, 

In a new turn of events, I learned yesterday that EPIC's release of the UFS MRW App will be delayed and will not happen this month as originally planned. A new date has not been set yet.

Your best bet may be to use the MRW App code directly from GitHub (which uses a new version of the UFS Weather Model, similar to what will be in the SRW App v2 release). However, one catch is that the global workflow will not run the same physics suites as the SRW App. Another catch is that amount of documentation and portability is limited.

Perhaps you can say a few words about your goals, what you are trying to do, so we can best help you. Also please say which platform you'd like to run the model in. Also, please say a few words about what project your work falls under. Let me get EPIC in the loop of this ticket to see how to best help you.

Thanks,

Ligia

 

 

 

 

Permalink

Submitted by cameron.book on Thu, 06/09/2022 - 15:41

Hi May,

Regarding the version of FV3 used in the SRW 'develop' branch that you mentioned, are you referring to FV3-ATM 'develop'? Since SRW 'develop' checks out this hash of the UFS-WM (https://github.com/ufs-community/ufs-weather-model/commit/96dffa1) via Externals.cfg, I believe the version of FV3 used is 'develop' (https://github.com/NOAA-EMC/fv3atm). You can view which FV3 branch is cloned as a submodule of the UFS-WM for that particular hash (the one checked-out in SRW develop) here: https://github.com/ufs-community/ufs-weather-model/blob/96dffa15a7f0a98c9120d36f31196c273c9232f2/.gitmodules. If you are looking to use another specific version of FV3, please let us know. As Ligia mentioned, the SRW also uses different physics suites than the MRW. Currently, the SRW supports the FV3_GFS_v16, FV3_RRFS_v1beta, FV3_WoFS, and FV3_HRRR physics suites, while the MRW 'develop' branch currently only supports the FV3_GFS_v17_p8 physics suite.

One option you might pursue is to use the 'master' branch of the MRW (git clone https://github.com/ufs-community/ufs-mrweather-app). This branch contains several large-scale updates to the MRW, most significantly being the switch from using the CIME workflow (as in MRW v1.1) to EMC's Global Workflow (https://github.com/NOAA-EMC/global-workflow). There is a Quick-Start guide (section 2 here: https://mrw-ug.readthedocs.io/en/textonly-quickstart/quickstart.html) that will guide you through the process to build, compile, and run an experiment using the global workflow paradigm. If you are seeking to run an atmosphere-only forecast, you will use 'ATM' for the "-app" argument in step 3 of section 2.2.

Note that there are two caveats to this approach: the first being that the global-workflow is currently only supported on Hera, Orion, and WCOSS. The second is that the 'develop' branch of the global workflow checks out hash "9350745855aebe0790813e0ed2ba5ad680e3f75c" of the UFS-WM, though this ultimately uses the 'develop' branch of FV3. You are welcome to replace the hash of the UFS-WM in https://github.com/NOAA-EMC/global-workflow/blob/develop/Externals.cfg (line 4) to the UFS-WM branch or hash of your choosing, though we have not tested the system using alternative UFS-WM hashes/branches. To do this, you can 'cd' into the global-workflow directory after section 2.1 step 2, and use vi/vim to edit the global workflow Externals.cfg file. However, my suggestion would be to try the MRW-global workflow system as it stands in MRW 'master' first.

If you are not working on Hera or Orion, please let me know and we can find an alternative solution.

I hope this is of some help. Please don't hesitate to reach out if you have further questions!

 

- Cameron

Permalink

Submitted by mwong on Fri, 06/10/2022 - 17:15

Hi Ligia and Cameron,

Thank you so much for all of this info. Regarding the current task of my project, I've made some code mods to ensure that various diagnostic budgets are closed in the model, but this was initially done in the SRW-App and right now I'm looking to port these code changes over to the MRW-App. In looking more closely at the FV3 version in the UFS-MRW v1.1 release, it looks like the dycore is behind that of what I see in the SRW-App, which makes it a little bit harder because I have been utilizing some of the existing subroutines in fetching the info I need (one way around it is probably to separate them into different subroutines...which may be cleaner anyway).

In response to Cameron's question, I'm working on Cheyenne. And thanks for all the pointers on the info provided by Externals.cfg. Not sure why this is different from what you described, but it looks like the SRW-App develop branch I cloned points to the "96dffa1" hash of the ufs-weather-model (and not the develop branch). Anyhow, technically if I can use the "ufs-v2.0.0" tag of the ufs-weather-model in the UFS-MRW App, that would be very helpful. Do you think this is something that I can change in Externals.cfg and try in the UFS-MRW V1.1 release?

Thanks,

May

Copyright © 2022. All rights reserved.