Rename CCPP suites to non-meaningful names #843
Conversation
- rename goldfinch.xml -> magpie.xml (equivalent SCM suite) - rename antbird.xml -> flamingo.xml (HAFS-A suite deserves a better name) - Add documentation lines to SCM and HAFS suites
indicate which were used for HAFS operational implementation
|
Just checking in on this PR based on our conversations with some developers last week: we had decided we would continue discussing unresolved concerns on this PR. As a reminder, there is a detailed presentation available describing the reasoning behind these changes, available here: CCPP Suite Renaming slides To hopefully spur on some continued discussion, I'll summarize what I believe is the main concern around this renaming proposal: that the loss of reference to the "application" (HAFS, GFS, RRFS, etc.) in filename leads to confusion about which suite is used for what purpose. Our counter to this concern is several-fold:
We understand that this is a potentially disruptive change, at least until people adopt and get used to the new system. If this is still a concern holding up the adoption of this PR, or if there are more remaining concerns aside from the above, we are eager to address them and reach a compromise if necessary. We just don't want this PR to languish with no discussion or progress in the meantime. |
|
Hi Mike, I understand what you're trying to achieve and agree that the SDF name should not include configurations in the title. While I personally think that bird names are a bit far fetched and unrelated to what we are doing in numerical weather prediction, I don't have any better suggestions. A readable text file that describes which application(s) the suites are currently used for would be desirable. Thanks for letting us chime in. |
|
I also agree there is no perfect solution to address the issues. As I mentioned in the meeting, it is desirable to set up a web page or github docs, which is accessible to all, to document the meaning of each suite, its history, and applications that use or used the suite. |
|
@yangfanglin This is still a work in progress, but I have added updates to the Users Guide in my weather model PR to include detailed information about all the suites. Is this the kind of documentation you were hoping for? Edit: corrected link for renamed section: https://ufs-weather-model-mkavulich.readthedocs.io/en/latest/InputsOutputs.html#the-suite-definition-file-sdf |
Mike, Section 4.2.5. on The Suite Definition File looks great |
|
@junwang-noaa @lisa-bengtsson and all: Since one needs 3 pieces of information to fully describe what physics was run :
removing actively misleading names from the SDF is an improvement in the situation, as I see it. I don't think that anyone is specifically attached to the bird names, but I think that any other topic chosen to organize the randomness of the names will likely have the same problem. Even using meteorological phenomena as names is still "random". I.e., there will be nothing about the suite that is related to "thunder" if we call the SDF that. If we want to abandon the human-referable requirement, there are many naming schemes that have been suggested that produce a hard-to-read alphanumeric name that is more representative of what is inside the file, but since the file is a human-readable XML and since there is and will continue to be documentation about what SDFs are used for what applications, it is easy enough for users to either read the contents or documentation to orient themselves regarding the SDFs, IMO. Any further thoughts on this? We need to decide to adopt this, something else, or maintain the status quo (which is still actively misleading and lacks proper documentation in most cases!). |
|
I recall during one of the telecom discussions, there is a specific concern about using the random suite file names (e.g., bird names), one will not easily know the connections between some related suites. Here is what a developer/user see in the FV3/ccpp/suites directory with the new naming convention: In contrast, here is the current suite files: From the readability wise, I think the original filenames at least provide some useful information (potential contents and relationship between some of the similar suites) by simply seeing the file names. However, it is not easy to get useful information by seeing the random naming convention. Even if just taking out the "suite_*_" prefix and converting to lowercase: still seems better in terms of readability and getting relationships between suites. If some further simplification is preferred, doing something like below can be considered: Or further simplifying into the following might can be considered if desired: Again, these are just my own opinion and some ideas/suggestions to be considered (may or may not be useful though) Also, agreed that the documentation like (https://ufs-weather-model-mkavulich.readthedocs.io/en/latest/InputsOutputs.html#the-suite-definition-file-sdf) definitely helps. Meanwhile, it might also be useful to add a README (or README.MD) file, describing all the suites inside this FV3/ccpp/suites directory. This will be beneficial for users/developers to easily find the description (no need to go to an external webpage/link). Meanwhile easier to make sure the descriptions in the README.MD being consistent with the suite files in the current dir (since they belong to the same repository). |
Description
This PR renames CCPP suites to non-meaningful names, per discussions among CCPP and weather model developers. In this initial round, we have arbitrarily settled on bird names, and they were semi-randomly assigned as suggested by various colleagues and ChatGPT. The only non-random naming was that the names for corresponding suites in the Single Column Model repository were made identical: see that PR for more information.
Attempts were made to avoid confusing or ambiguous names, but suggestions are welcome as these names are not set in stone. The whole point of this renaming is that the suite names should be insignificant, only serving to disambiguate different physics configurations. Scientific and technical information about the suites should be derived from the suite file contents and other documentation.
The old names are mapped to the new names via a JSON format file
alias.jsonfor convenience.Finally, a "DESCRIPTION" comment is added to all suites. I have tried to describe the provenance of each suite file to the best of my knowledge, but comments and corrections are welcome.
Issue(s) addressed
Testing
Have the ufs-weather-model regression test been run? On what platform?
Dependencies