Simplifying the UFS Weather Model repository

[arunchawla-NOAA]

The UFS weather model is made up of a number of repositories that are connected together using sub modules. This concept is required because the UFS weather model is made by connecting several component systems together to build a coupled system. However, this approach has a down side as changes in a component requires creating PRs all the way to the top which just adds to the complexities of the system.

This discussion has been started to develop ways we can simplify the system. There are two things we would like to start with

1. FV3atm as a standalone repository: The UFS-weather-model connects to the FV3atm repo which includes some code for the atmosphere cap and then connects to the atmos cube dycore and CCPP related repositories. The need for this stand alone repository does not make sense as it cannot be run by itself. Furthermore this by itself is focussed on developing the atmospheric component for the UFS. It makes more sense to move FV3atm as a directory under the UFS weather model and have it point to the dycore and CCPP related repos that are stand alone. It will at the least make the UFS weather model flatter and reduce one additional layer of PRs
2. NEMS as a stand alone repository : NEMS when it started contained the main driver code, the different mediators and the build system. Most of these have been removed from the repository and sit elsewhere. There seems to be no reason to maintain NEMS as a stand alone repo. The only other systems that are using this are the coastal and space weather apps, but they are using fairly old forks that are not updated in this repo. It does not make sense to maintain this as a separate repository when the main purpose of this code base is to serve the UFS-weather-model. We should move this code base into the UFS-weather-model (still keep a frozen repo if other applications are still connected to this repo)

Please discuss the pros and cons of this approach and propose other items for simplification

[JessicaMeixner-NOAA]

Will there ever be a case where we have something like the S2S versus weather app? If so, wouldn't that make not having an atmospheric component difficult?

NEMS is used in the coastal applications which are currently not included in ufs-weather-model. What happens to those applications if NEMS becomes part of ufs-weather-model? Do there then become two "NEMS" one for the coastal applications and one for ufs-weather-model?

[arunchawla-NOAA]

we have multiple apps using the same code base. Would S2S be different ?

[JessicaMeixner-NOAA]

I guess I was just pointing out that possibility that if that situation came up in the future that we had a separate S2S instead of the same app as we do now, having an atm model that is not attached the the whole system might be preferred. However, if that will never happen again, it's a non-issue.

[DusanJovic-NOAA]

Can somebody point us at the coastal application(s) that are using the NEMS repository? Are they using 'NEMS mediator' or CMEPS? Keep in mind that so-called NEMS mediator is removed from the develop branch recently. Are coastal apps using other ufs components, like fv3, or mom6 or gocart? If they do then I think they should be integrated in UFS as any other ufs configuration we currently maintain, like stand-alone ATM, or coupled, or HAFS configuration etc.
The only thing that currently exists in NEMS repo is trivial main program that instantiates one top-level esmf gridded component (Earth gridded component) that uses CMEPS. As such I think each program should maintain its own driver (main program + top-level component).

What happens to those applications if NEMS becomes part of ufs-weather-model?

Nothing. NEMS repo will still exist, we are not deleting anything. Suggestion is to just move main program and top-level gridded component to UFS repo.

Do there then become two "NEMS" one for the coastal applications and one for ufs-weather-model?

I do not think there will be two "NEMS". I wouldn't call main program + top-level esmf gridded component NEMS. I would call NEMS a code that includes legacy "NEMS Mediator" which at this moment only exists in old commits in NEMS repository.

[JessicaMeixner-NOAA]

@awest-noaa can you point @DusanJovic-NOAA to the coastal applications? And answer his questions? Otherwise, I can answer what I know but I have a feeling it's not up to date information.

[arunchawla-NOAA]

The NEMS repository is another matter. Is there a reason to maintain a separate repo for just the driver code base? But that will probably mean copies of the driver for different code bases. As it stands now any updates that we make to NEMS we do not test with coastal app so we are treating it as being part of UFS-weather-model

[junwang-noaa]

Here are my two cents. As Arun mentioned the UFS consists of many subcomponents and it uses submodules to ensure version consistency. I think we may need to have some guidelines on what defines a subcomponent and if it should stay in a separate repository in general. Currently we don't have any requirement and components may come in as is (the component repo itself may have several sub repositories in it). It could make ufs-weather-model repository more complicate and hard to work with. Moving FV3/NEMS to UFS may alleviate the complicity of hierarchical commit process. On the other side, UFS has applications that do not use FV3 for atmosphere component, e.g. NG-GODAS, so moving it inside UFS seems to me a special case. A separate NEMS repository allows other model framework to use the NEMS driver, but since we haven't heard any framework using the recent NEMS repository, so I think if we move NEMS to ufs, maybe those applications will eventually come to UFS.

[DeniseWorthen]

I'm not sure I have an opinion on item (1), although anything that makes the commit process easier has my vote. As for NEMS, I agree that this no longer warrants a repo to maintain. As others have said, it no longer contains the mediator etc. I think the two remaining codes (not sure what the "rusage" stuff is) could be moved into either the top-level of the repo, or in a driver subdirectory. Yes, there are apps who are still pulling from the NEMS repo (and they can continue to do so). I think we need to do what is best for UWM.

[rsdunlapiv]

If the "NEMS" repo goes away, we need some broad communication then on what is the "NOAA Environmental Modeling System". The term is embedded in NOAA culture as a description of a unified modeling system and is used very frequently. E.g., "NEMS-based application." So if NEMS goes away as a repo, having been diffused into other places (e.g., CMEPS, rt.sh, ufs-weather-model, CMake build) then people will need to understand whether NEMS still exists concretely (i.e., has code), or whether it is an abstract concept that implies shared infrastructure, but has no real existence in code.

[arunchawla-NOAA]

The name NEMS is still in the names of the code base (main_NEMS etc.). Though I could contend that the name NEMS is waning more for the name UFS now. Couldn't the name NEMS have the same abstract concept like NUOPC cap ? We do not explicitly call the caps NUOPC caps in the name

[rsdunlapiv]

@arunchawla-NOAA I think moving towards the term UFS is good - and it would help to communicate that "NEMS" applications are all UFS applications, including coastal and space weather. However, I think clear and broad communication is needed across the board to ensure that the whole community understands the pivot in terminology. Why "NEMS" is no longer valid terminology and that "UFS" implies the same thing now that "NEMS" did a years back.

[awest-noaa]

Hi all, Apologies for my delayed response. Dusan, the Coastal Application currently lives here: https://github.com/noaa-ocs-modeling/CoastalApp I could not find the Github discussion thread Jessica mentioned, so please point me to your questions. Regarding the question of retiring NEMS, my impression is that the Coastal group would be fine with it in principle. I have two suggestions though: (1) Could we bring up and discuss this during one of our bi-weekly Friday meetings? We would need our partners NOS and OWP to chime in also, (2) Could we have a grace period for this transition? Our current main application (COASTAL Act) is nearing development completion, and will be live-tested next hurricane season. So we will need some time for retooling the app on our side. Andre

…

On Thu, Oct 21, 2021 at 12:51 PM Rocky Dunlap ***@***.***> wrote: @arunchawla-NOAA <https://github.com/arunchawla-NOAA> I think moving towards the term UFS is good - and it would help to communicate that "NEMS" applications are all UFS applications, including coastal and space weather. However, I think clear and broad communication is needed across the board to ensure that the whole community understands the pivot in terminology. Why "NEMS" is no longer valid terminology and that "UFS" implies the same thing now that "NEMS" did a years back. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#872 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5AYOQMU7G6ZDDM3ZGRPW3UIBAKHANCNFSM5GGYP7PA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- Andre J. van der Westhuysen, PhD Ocean Task Lead IMSG at NWS/NCEP/Environmental Modeling Center National Oceanic and Atmospheric Administration 5830 University Research Court College Park, Maryland 20740, USA T. +1 (301) 683-3755 F. +1 (301) 683-3703 The contents of this message are mine personally and do not necessarily reflect any position of NOAA.

[arunchawla-NOAA]

So coastal act is using a NEMS repo that has been forked from the NOAA-EMC NEMS repo.

But if we were to leave the NOAA-EMC NEMS repo alone and just copy the main driver codes into the UFS WM main repo we would not break any other modeling system. The NEMS repo will remain, it just will not be used by UFS WM anymore.

[awest-noaa]

Dusan, To answer your questions from earlier this week: There is only one coastal application (currently called CoastalApp). It does not use any mediator (NEMS or otherwise). It contains the gridded components WW3 (unstructured mode), ADCIRC, D-Flow, and NWM/WRF-Hydro. So no fv3, mom6 or gocart. We have plans to move the CoastalApp repo to the UFS umbrella, but that still needs to be proposed to, and approved by the UFS Steering Committee. We are planning to submit this proposal in November. Andre

…

On Fri, Oct 22, 2021 at 5:06 PM arun chawla ***@***.***> wrote: So coastal act is using a NEMS repo that has been forked from the NOAA-EMC NEMS repo. But if we were to leave the NOAA-EMC NEMS repo alone and just copy the main driver codes into the UFS WM main repo we would not break any other modeling system. The NEMS repo will remain, it just will not be used by UFS WM anymore. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#872 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5AYOTCC5GSEEMN4HT3CM3UIHG3ZANCNFSM5GGYP7PA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- Andre J. van der Westhuysen, PhD Ocean Task Lead IMSG at NWS/NCEP/Environmental Modeling Center National Oceanic and Atmospheric Administration 5830 University Research Court College Park, Maryland 20740, USA T. +1 (301) 683-3755 F. +1 (301) 683-3703 The contents of this message are mine personally and do not necessarily reflect any position of NOAA.