What is the best way to deal with multiple models using different components within the SRW App?

[MichaelLueken]

Currently, this isn't an issue for the ufs-srweather-app repository. However, once the Online-CMAQ, RRFS, and RRFS-WRF-Hydro systems are integrated into the ufs-srweather-app repository, there might be push back from NCO with respect to cloning more components than are needed for each system. Two possible ways to deal with this are:

1. A universal Externals.cfg file would exist that contains all components that are required for each system. Separate Externals.cfg files would then contain just new components that are required explicitly for a given system (i.e., Externals.cfg would contain ufs-weather-model and ufs-utils, while Externals_AQM.cfg would contain arl_nexus and aqm-utils, and Externals_RRFS.cfg would contain upp, gsi, and rrfs_utl). The different Externals*.cfg files would need to be loaded using:

./manage_externals/checkout_externals -e Externals.cfg
./manage_externals/checkout_externals -e Externals_AQM.cfg

2. A single Externals.cfg file that contains all components and create a standalone script (aqm_manage_externals) that would check out just the components required for a given system. This would be achieved through the use of:

./manage_externals/checkout_externals ufs_utils ufs-weather-model arl_nexus aqm-utils

within the aqm_manage_externals script.

Are there any preference with respect to which of these methods to use? Are there any other options that would work better than these? This is simply to open the floor for discussion in case this becomes an issue in the future (topic started through discussions in PR #549).

[RatkoVasic-NOAA]

Although having one cfg file looks nicer, I believe option one would be more practical.

[christinaholtNOAA]

@MatthewPyle-NOAA @aerorahul Could you provide any clarity here on what NCO will require?

I've been assuming that since git submodules give you everything no matter what you compile, getting everything from SRW would be the same, even though it's managed with manage_externals.

[MatthewPyle-NOAA]

@christinaholtNOAA I'd say a general rule would be to only clone aspects needed for the operational system. I agree with Ratko that option 1 seems better, at least for the AQM issue (have a default checkout and a bonus checkout for AQM). But honestly not too worried about this kind of detail for RRFS; we'll have an implementation branch in which to fine tune these details.

[christinaholtNOAA]

I think I maybe interpreted @RatkoVasic-NOAA's comment differently. I thought he was saying just having one Externals.cfg file was nicer...option 2.

[aerorahul]

Page 17 of the NCO EE2 standards document here states the following:

10. Remove all references to developer work areas and all development tools (benchmarking, etc.)
before submitting to IDSB.

There should be no development tools, scripts, or source code that does not result in an executable or function in the operational suite.

Exceptions are granted on a case-by-case basis, and should not be used to circumvent the requirement.

[christinaholtNOAA]

So, when we clone the model as an external, we get all of the subcomponents of that, but compile only a very few of those. I'm curious how this might be different at the App level.

[aerorahul]

The model is a complex beast. Ideally, one would only checkout the subcomponents that are needed for an application.
This can be accomplished with sparse checkout. We currently checkout all sub-components for any application.
The build does not need to change as only components required in an -DAPP are compiled.

The assembly of components in SRW App is likely a different case.
There is a tendency to checkout and build all components and utilities (that may not be used in an operational configuration).
This will certainly need to be "sanitized" before code-delivery for operations.

[christinaholtNOAA]

There is a mechanism in the SRW build that only builds the necessary components for a given system (RRFS, CMAQ, etc.). We are trying to get at whether it makes sense to clone all the code bases, though, whether they're used or not.

[arunchawla-NOAA]

I am a fan of keeping it simple. Why not different externals.cfg files for different configurations? I know you want to keep the model moving along with the different configurations but that can be a best practice to do this at the same time for all the configurations (we probably only have a handful). Why over complicate something that does not need to?

[MichaelLueken]

Hi @arunchawla-NOAA. The concern with different Externals.cfg files for the different configurations is that different hashes of the same components will be used. It has been decided, by the SRW App's code management team, that this is untenable. We will need a default Externals.cfg file which contains the branch and hash for the weather model, UPP, and UFS_UTILS repositories, then each application can have it's own Externals.cfg that contains components and hashes that are required explicitly for that application.

[arunchawla-NOAA]

What if you do not need to run offline UPP?

[MichaelLueken]

This was certainly an issue before the latest update to the SRW App, since AQMv7 wasn't using UPP due to issues with varying forecast length hours. To be honest, since the majority of the applications currently require UPP (AQM and RRFS), I'm not sure how to best address an application that doesn't need to run offline UPP.

Ultimately, I believe that @MatthewPyle-NOAA and @aerorahul have described what would happen within the release/implementation branches. In the release branches for the AQMv7 and RRFSv1.0.0, the Externals.cfg file will only contain necessary components for the specific application. Each application will likely require updated hashes to point to the release tags of the various components, which will be different from the hash on develop. The jjobs and ex-scripts would also be pruned (as well as various utilities that wouldn't be required in operations) so that only those required to run a given application would be available.