Minutes for 2022 meetings
Attendees: Julio Bacmeister, Grant Firl, Chunxi Zhang, Laura Fowler, Ligia Bernardet, Fanglin Yang, Dustin Swales, Pedro Jimenez, Joe Olson, Lisa Bengtsson, Matthew Dawson, Jeremy Gibbs, Andy Hazelton, Lulin Xue, Mike Ek, Jimy Dudhia, Li Zhang | Alex Reinecke, Jeff Mcqueen,
New member: Julio Bacmeister. CAM development chair. Will CCPP-ize CAM physics in the next several months.
Active discussions in the last three meetings
DTC's thoughts on CCPP interstitial schemes: led by Grant. Slide available at: https://docs.google.com/presentation/d/1KPGUAs2IpRrg2KxzvdfutYi8jNXbCOiDKiMXBnv_2rc/edit#slide=id.g18de6175f0e_0_63
Grant: Explain what CCPP interstitial schemes are and the motivation of having this meeting to Julio and others. Preliminary suggestions include convert primary schemes to return tendencies only and Remove all hard-coded control logic and all hard-coded constituent array assumptions
Clarifications on "convert primary schemes to return tendencies only": 1. Not suggesting to change actual tendency application strategy! 2. Physics suites are given an input state and fill in an output state, but it is up to the host model to control how the REAL state is updated. So, we’re really only talking about how to update an internal physics state.
These allow interstitial schemes updating tendencies to be autogenerated by the CCPP Framework.
Clarifications on hard-coded logic/constituent:
Interstitial combination revisited: many examples exist in current codes.
Laura on MMM's perspective on this issue:
- the parameterization itself should be the star of the physics suite, not the interstitial source code to run the parameterization itself.
- it is certainly easier to design interstitial source code when you have more than. on host model to deal with at once (ex., MPAS+WRF instead of MPAS and WRF separately).
- the developer is King with some guidance.
Grant: It does not help for the developer to decide whether tendencies to be updated or not in the light of interoperability. Laura: Different hosts treat tendencies differently. Physics should be used within and outside of the CCPP world. Dustin: Have things done in the framework or by interstitial codes. Flexibility in physics or in host is a philosophical question. Laura:
Chat Notes:
Fanglin Yang - NOAA Federal2:04 PM
Welcome Julio, nice to meet you again in this platform
Julio Bacmeister2:06 PM
Thanks Fanglin
You2:06 PM
Welcome on board, Julio!
You2:07 PM
Grant's google slides for today's discussion
You2:12 PM
Interstitial inventory
Julio Bacmeister2:13 PM
Yes. Thanks.
Grant Firl - NOAA Affiliate2:43 PM
We're in violent agreement about the implementation of the interstitial code around Thompson. It is probably the worst "offender" of software layer bloat. Rather than being a CCPP design decision, this was the result of the underlying WRF-based mp_gt_driver being previously ported to GSM-based GFS, then FV3-based GFS, then finally to CCPP. We agree that it needs to be rewritten with mp_gt_driver as the "star", but I don't see how that gets around the need for interstitials ...
... unless the low-level mp_gt_driver is rewritten to use (i,k) rather than (i,k,j).
Jimy Dudhia2:48 PM
good point about microphysics update
Grant Firl - NOAA Affiliate2:56 PM
I would argue that allowing the physics developers to do what they want all the time leads to the long drivers in the first place when host modelers try to cobble everything together. This speaks precisely to one of the main goals of the CCPP
Attendees: Chunxi Zhang, Laura Fowler, Ligia Bernardet, Grant Firl, Dustin Swales, Pedro Jimenez, Fanglin Yang, Joe Olson, Lisa Bengtsson, Matthew Dawson, Jeremy Gibbs, Andy Hazelton, Lulin Xue, Li Zhang | Alex Reinecke, Jimy Dudhia, Jeff Mcqueen, Mike Ek
Active discussions in the last two meetings.
DTC's thoughts on CCPP interstitial schemes: led by Grant. Slide available at: https://docs.google.com/presentation/d/1KPGUAs2IpRrg2KxzvdfutYi8jNXbCOiDKiMXBnv_2rc/edit#slide=id.p1 (will be moved to new place soon)
Motivation: 1. Interoperability is not "deep". A category of structural/organizational dependence remains. 2. Too many interstitial schemes. 3. Host models provide little guidance for constructing suites from scratch.
Goals:
- Develop a strategy for improving the current set of IS (interstitial schemes).
- Develop guidance for future interstitials, both within the UFS and for other hosts (while maintaining flexibility).
- Use new interstitial guidance to better organize primary scheme code.
Inventory of current IS: https://docs.google.com/spreadsheets/d/1_Zw5B49QM_HHgMhstwz_8xFkG9ygxvAkxKmpm2ECP28/edit#gid=368751223
Examples of different categories:
- Technical dependence on host: GFS_debug.F90. This was a conscious decision and only example.
- Organizational/Philosophical host dependence: Many instances. Assumptions about surface tiling, time-split, tracers (order), etc. Using hard-coded integer controls, UFS-specific diagnostic tendency (sparse array solution), coupling insertion code.
- Future CCPP Framework functionality: Tendencies handling. Column mass adjustments. Debugging output. Constructing arrays of constituents to be operated on by physics and updating them. Conservation checking. Index and array transformation (including vertical flipping).
- Intrasuite timing assumption: Using assumptions about intrasuite timing and/or tendency application
Preliminary Suggestions
- Convert ALL primary schemes to return tendencies only
- Remove all hard-coded control logic and all hard-coded constituent array assumptions
- What to do about diagnostics?
Primary schemes matter too:
- Primary schemes have made different decisions about things like
- A cohesive interstitial strategy more-or-less requires that all primary schemes are “on the same footing”
CCPP Big Picture Thoughts:
- How do we strike a balance between developer flexibility and ensuring interoperability?
- Until now, CCPP has been “laissez-faire” with respect to organization. It seems like true interoperability across hosts requires a clearer division between primary/interstitial schemes and better guidelines for interstitial scheme structure (AKA suite construction)
- Do we even want interoperable interstitials? Should we expect each host to want to write their own?
- Do “pretty”/short SDFs matter more than giving users/developers a clearer picture of what is happening within a suite with “ugly”/long ones?
Discussions: Ligia: Welcome comments from the audience.
Joe: Should be cautious about making too many rules for the primary schemes. Some rules are already too hard to follow for physics developers. Not all the diagnostics the same. Some are just outputs used internally which should not be moved to the end.
Grant: acknowledge different kinds of diagnostics. How about moving to just update tendencies from physics (no updates on states). Ligia: CESM needs more flexibility on tendency handling.
Matt: Are we including chemistry in this concept. Tendencies in chemistry are too fast, impossible to follow the framework.
Laura: WRF physics returns states not tendencies. Should leave the decision to developers how to handle tendencies.
Lulin: blabla.
Li Zhang: agree with Matt's concerns. The chemistry coupling with CCPP only concerns aerosol direct effect for now. In the future, we may include the secondary effects that will impact microphysics, which tangles the situations.
Fanglin: Microphysics and gravity waves need to update states. It is hard for developers to follow the rule for all kinds of applications.
Ligia: need subcomponents to be separated.
Matt: Solving ODE for chemical reactions.
Grant: not preventing the states to be updated internally. Just need a tendency at the end after the calculations.
Matt: questions on should the chemical tracer tendencies be provided or an overall concentrations to be returned at the end.
Li: some concerns on mass conservations.
Fanglin: Ligia and Grant: in the SDF, which schemes are process-split and time-split so that the framework can handle the situations correctly to avoid complicated IS handling them differently.
Lisa: confirm the proposed idea is to allow the framework to handle these consistently. Matt: might misunderstand the point.
Ligia: Moving forward, continue the discussions. How many meetings do we want to focus on this topic?
Chat Notes:
Lisa Bengtsson - NOAA Federal2:02 PM haha!
Fanglin Yang - NOAA Federal2:40 PM evaporation and condensation happen within microphysics, the tendencies are only diagnostics.
Fanglin Yang - NOAA Federal2:54 PM https://docs.google.com/presentation/d/1xJVq1AHLdi7Q8tk7t2LSS_uwTQWldHCbpQHZOYoMTE8/edit#slide=id.p GFS physics update sequence
Dustin Swales2:54 PM I support to keep the conversation going
Pedro Jimenez Munoz2:54 PM me too.
Lisa Bengtsson - NOAA Federal2:54 PM Yes, me too
Grant Firl - NOAA Affiliate2:55 PM I definitely support continuing to talk about it, but I don't want this to constantly dominate the conversation/meeting.
Attendees: Chunxi Zhang, Laura Fowler, Ligia Bernardet, Grant Firl, Pedro Jimenez, Joe Olson, Jimy Dudhia, Jeff Mcqueen, Matthew Dawson, Andy Hazelton, Lulin Xue, Li Zhang, Mike Ek | Dustin Swales, Lisa Bengtsson, Alex Reinecke, Fanglin Yang,
Structure of interstitial schemes: Chunxi debriefs the team on the topic from the beginning. There are three levels of interstitial schemes: 1. scheme level, 2. suite level, and 3. small task. Most lines in the SDF are interstitial schemes. Want to have a cleaner look of the SDF so that clean up of the interstitial schemes.
Ligia comment: Simpler may not be better in many cases.
Question 1: Should we rename the suite level interstitial code? Rename the interstitial scheme by removing "GFS_". How to deal with names like "GFS_suite_interstitial_1 (2,3,4,5).
Comment from Laura: Are these suggestions applied to all other developers? Feel like this is a strong constraint for developers. The lack of flexibility seems to be difficult to follow. Interstitial codes should be associated with host model rather than with CCPP framework.
From Jimy: most of the existing codes are for GFS. It is reasonable to have GFS in the name. Chunxi: only a few interstitial codes are for the host model. Many are not.
From Grant: the goal is not to overly describe the rules for interstitial codes. Need some guidelines and suggestions for how to name the interstitial scheme names. Names can be more descriptive than current forms. The bottomline is to come up with a guideline to make these names more meaningful and descriptive.
From Ligia: Agree with Grant. The question should be "what is the naming convention for interstitial schemes?" Agree with Chunxi that the current naming structure is bad and need to change. The discussion should be on... Laura: interstitial layer is part of host models. They will be very different in different host models. It does matter for UFS to know the interstitial structure of MPAS.
Chunxi's responses: Agree with Ligia on removing "GFS". Are there any host models that call the physics differently? Laura: MPAS and WRF are very different than UFS. State variables are not updated the same way as UFS. The order and function of interstitial codes are different too. Chunxi: Use wrapper for state variable updates???
Ligia: Answer is yes to Chunxi's question. The design of CCPP is to have the flexibility to call physics in different ways.
Laura: What is the difference between wrapper and interstitial layer? Chunxi: use mp_thompson as an example to explain the difference. Suggest to combine the mp_thompson_pre and _post into mp_thompson scheme.
Ligia: Maybe one way moving forward is to prototype or use an example to develop our thought processes and potential solution. Solutions can be different for different use cases. Laura: mp_thompson may not be the best example due to dimension limitations. Hope to keep the _pre and _post interstitial schemes so that MPAS can use the structure with different functions.
Jimy: Should identify which interstitial codes are independent relative to hosts. Grant: Will get big pushback from developers on what variables to use.
Pedro: If the IC is specific to a host, then the name should include the host name. Laura: Don't sure why the host model name should be in the interstitial code name. Pedro: If one has no background on what are out there and only has a dycore, it is helpful to have the host name in the interstitial schemes.
Laura: Why should MPAS interstitial codes be part of the CCPP physics? It will become hard to manage when more host models are part of the CCPP ecosystem.
Ligia: Some host models do share interstitial schemes. Laura: Physics should be independent and archived in CCPP-physics. Not the interstitial codes. Grant: It is not appropriate to label interstitial codes with dycore or host models. They just describe how host deals with variables, not strictly part of the host model.
Pedro: Agree with Grant that there are more than one levels in the interstitial codes. Chunxi: Are we used just one data structure? Ligia: Not necessarily the case. Grant: That's why CCPP require variables at the intrinsic level. Chunxi: If IC has switches inside, then it has to be used by certain host model data structure.
Ligia: Like the form of today's meeting. Want to identify the problems, refine the questions.
Chat Notes:
Jimy Dudhia2:17 PM GFS_suite_interstitial_rad_reset.F90 has code like this use machine, only: kind_phys use GFS_typedefs, only: GFS_control_type use CCPP_typedefs, only: GFS_interstitial_type You2:22 PM https://github.com/NCAR/ccpp-physics/wiki/Minutes-for-2022-meetings Grant Firl - NOAA Affiliate2:24 PM Yes, different host models do many different orders with physics Grant Firl - NOAA Affiliate2:25 PM Many hosts also have different "species" of physics too, e.g. processed combined in different ways. *processes Jimy Dudhia2:35 PM mp_thompson_pre only does things with error flags Jimy Dudhia2:37 PM I think we have to identify which interstitials are host-dependent Many of the GFS ones seem to be Jimy Dudhia2:43 PM we are storing them all in the same directory in ccpp_physics chunxi zhang - NOAA Affiliate2:44 PM @Jimy, yes, and currently there are only a few different interstitials between SCM and FV3 Jimy Dudhia2:45 PM other models will multiply this number Andrew Hazelton - NOAA Affiliate2:50 PM I have to duck out a few minutes early - thanks! Ligia Bernardet - NOAA Federal2:55 PM As we get ready to wrap up, please type here if you have suggestion on the next steps for going forward with this topic Jimy Dudhia2:59 PM I will send an idea
Attendees: Chunxi Zhang, Dustin Swales, Ligia Bernardet, Lisa Bengtsson, Pedro Jimenez, Joe Olson, Jimy Dudhia, Andy Hazelton, Lulin Xue, Li Zhang, Alex Reinecke, Jim Doyle, Fanglin Yang,
A brief announcement about the ccpp-physics wiki We have a new page of the NCAR/ccpp-physics wiki (https://github.com/NCAR/ccpp-physics/wiki/Supporting-CCPP-for-various-host-models). Please read it and let us know if you have any comments or suggestions.
Backwards (in)Compatibility
- A DTC proposal NRL's host model meta data is no longer updated with the physics meta data update. Want to know when to update the host model side codes when physics updates are introduced. DTC proposes to use github functionality to automatically test the compatibility using ccpp_prebuild.py. This will be run at the background (on github server) and produce results.
Compatibility between host and ccpp-physics is Not strictly related to changes in ccpp-physics interfaces (physics .meta files) Not strictly related to changes in a given host’s interface (host .meta file) Related to the “glue” between ccpp-physics and the host: ccpp_prebuild If PRs to ccpp-physics cause ccpp_prebuild to break for a given host, that host needs to be alerted! Proposal: Use CI to run ccpp_prebuild for all participating models when PRs are submitted to the main branch, alert hosts of failures, and have them fix the problem in a timely manner Next step: DTC to meet with NRL code managers to discuss
NRL's recent issue is that a variable need to be saved in the restart file but is currently not in, which does not cause compile failure but will change the results.
Grant's comments: two types of problems. One is when new physics variables are added that breaks the compilation. The other is the I/O files need to be updated when changes are introduced. Chunxi's comment: Global version of USF pass the RAP suite restart test but not the regional version.
- Can versioning of schemes help?
A suggestion was made to consider semantic versioning of schemes Given a version number MAJOR.MINOR.PATCH, increment the MAJOR version when you make incompatible API changes MINOR version when you add functionality in a backwards compatible manner PATCH version when you make backwards compatible bug fixes That could alert hosts that care about a given scheme wrt of backward incompatibility. Would that be helpful? If so, we could add a line or file to each scheme detailing the version and increment it as development goes forward? But note that CCPP is used as suites (not as individual schemes), so versions of individual schemes may be of limited use
Pedro's comments: Change the CCPP-physics version with the version number.
Ligia's comment: CCPP did not apply the semantic versioning of schemes in the past.
Alex's comment: Can add extra digit to the version number within a major release.
Dustin's comment: CI test will help identify the broken point.
At this point the group does not see a need to introduce versioning. We could discuss further when Matt is present, since he was the one who brought up this topic.
Structure of interstitial schemes Three levels of interstitial codes: scheme level, suite level, and small tasks.
Should we rename the suite level interstitial code? Rename the suite level interstitial code. Most of interstitial code started with “GFS_”? For example: GFS_suite_interstitial_rad_reset => suite_int_rad_reset GFS_PBL_generic_pre => suite_int_PBL_pre GFS_suite_interstitial_1 (2, 3, 4, 5) => ?
Some interstitial code could be combined?
Some interstitial code can be cleaned up?
Ligia's question: If host models are different, should the interstitial files be more specific? Joe's comment: Should not use GFS or UFS as the suite name.
We decided to continue this discussion about interstitials next time.
Chat Notes: Ligia Bernardet - NOAA Federal2:01 PM https://docs.google.com/presentation/d/1M8sB_4TqwnJY46uPOMAkfCryILaOel2FO8LhjOOoYSI/edit#slide=id.p1
Grant Firl - NOAA Affiliate2:05 PM Ligia, everyone else can hear.
Andrew Hazelton - NOAA Affiliate2:05 PM I can hear OK
You2:05 PM Ligia cannot hear anyone
Kate Zhang - NOAA Affiliate2:05 PM I can hear
Grant Firl - NOAA Affiliate2:11 PM It checks out the top of the development branch of the host to try ccpp_prebuild.py with the updated physics code.
Lisa Bengtsson - NOAA Federal2:14 PM Does the RAP suite pass restart reproducibility test in UFS?
Grant Firl - NOAA Affiliate2:18 PM host metadata only
Jimy Dudhia2:32 PM developers may want to version their own schemes for other reasons, and would be free to do so
Grant Firl - NOAA Affiliate2:33 PM I agree Jimy. I still think that there is a use for schemes to have a version associated with them, I'm just not sure that it makes sense for the CCPP to assign that.
Dustin Swales2:34 PM My concern is with potential conflicts with schemes that already do their own versioning.
Fanglin Yang - NOAA Federal2:47 PM host_app ?
Jimy Dudhia2:47 PM UFS may be too general for dycores (in future)
Andrew Hazelton - NOAA Affiliate2:48 PM Have to leave a few minutes early - thanks Ligia and all!
Grant Firl - NOAA Affiliate2:49 PM Yes, Lulin. Good point. The naming convention of scheme_name.host.F90 does work for this (SCM and FV3 can use same SDF)
Dustin Swales2:34 PM My concern is with potential conflicts with schemes that already do their own versioning.
Fanglin Yang - NOAA Federal2:47 PM host_app ?
Jimy Dudhia2:47 PM UFS may be too general for dycores (in future)
Andrew Hazelton - NOAA Affiliate2:48 PM Have to leave a few minutes early - thanks Ligia and all!
Grant Firl - NOAA Affiliate2:49 PM Yes, Lulin. Good point. The naming convention of scheme_name.host.F90 does work for this (SCM and FV3 can use same SDF)
Jimy Dudhia2:50 PM They may have different index orders
Grant Firl - NOAA Affiliate2:51 PM I'm not sure that there is a general answer for all hosts/scheme types.
Jimy Dudhia2:52 PM GFS_PBL_generic_pre is very host specific by the way
Grant Firl - NOAA Affiliate2:53 PM Yes, it is preparing arrays for vertical diffusion by any PBL scheme that expects an array of constituents to diffuse
Dustin Swales2:53 PM If there is one thing that come of this, I hope it's the demise of GFS_suite_interstitial_1/2/3/4/5!
Lisa Bengtsson - NOAA Federal2:54 PM ^ yes
Joseph Olson - NOAA Federal2:54 PM ^^ agreed
Grant Firl - NOAA Affiliate2:55 PM There is A LOT of room for improvement in all interstitial organization.
Grant Firl - NOAA Affiliate2:56 PM Moorthi and Fanglin say that cnvc90 needs to stay due to legacy output requirements
Dustin Swales2:56 PM There is an old issue, opened 2-years ago by Dom, discussing this. https://github.com/NCAR/ccpp-physics/issues/495 I plan on addressing this on the next few months.
Grant Firl - NOAA Affiliate2:57 PM But, perhaps its functionality could be reorganized!
Lisa Bengtsson - NOAA Federal2:57 PM Thank you for this discussion!
Attendees: Chunxi Zhang, Dustin Swales, Laura Fowler, Jim Doyle, Ligia Bernardet, Lisa Bengtsson, Pedro Jimenez, Joe Olson, Matthew Dawson, Jimy Dudhia, Jeff McQueen, Andy Hazelton
Backwards (in)Compatibility
- In a previous meeting with DTC, the NRL team raised the issue that they need to know when CCPP changes make it backward incompatible, that is, requires changes in the NEPTUNE host model
- DTC will bring a proposal in a future meeting about dealing with that
- Matt recommended we look into Semantic versioning change: https://semver.org/
UFS fork
- The fork is up and running at https://github.com/ufs-community/ccpp-physics/.
- We decided to make a change to the UFS Fork Guidelines so that all development targeted for the UFS is directed to the UFS Fork (and not directly to the authoritative repo).
- Dustin will check if there is a way in GitHub to prevent CODEOWNERS being tapped on twice to review the same code (once in the UFS Fork, then again in the authoritative repo).
- After that, Ligia will contact points-of-contact (aka, CODEOWNERS) to request that they review PRs on the Fork.
- We decided to assign points-of-contact (aka, CODEOWNERS) to some interstitial schemes (e.g., thompson pre and post should have the same codeowners as the thompson scheme itself). Dustin will begin populating [table].(https://docs.google.com/spreadsheets/d/14y0Th_sSpCqlssEMNfSZ_Ni9wrpPqfpPY0kRG7jCZB8/edit#gid=0).
- We need to further advertise the fork
- Ligia will post a blurb in NCAR/ccpp-physics wiki.
- Lisa sent email to PSL developers to submit PRs to the UFS Fork.
- Lisa will advertise in UFS-R2O Physics team meeting.
- GSL still thinking about next steps about their code mgmt to submit physics to the UFS.
The group would like to (re)discuss the topic of standardization of scheme nomenclature and structure of interstitials in a future meeting.
Chat Notes: Matthew Dawson2:08 PM https://semver.org/ chunxi zhang - NOAA Affiliate2:31 PM https://docs.google.com/document/d/1UPt5x2Ef3FjWvFvn-RVYmaMdIje1RZilAHuteu61ed0/edit Lisa Bengtsson - NOAA Federal2:36 PM Can someone past the wiki slides in the chat? paste Jimy Dudhia2:40 PM It may be that someone from a different center affects your code and you want to know that Ligia Bernardet - NOAA Federal2:41 PM points of contact https://docs.google.com/spreadsheets/d/14y0Th_sSpCqlssEMNfSZ_Ni9wrpPqfpPY0kRG7jCZB8/edit#gid=0 https://docs.google.com/presentation/d/1monbqg4FLkNPNknWcmA2Z0Bye1kv9tI2G8ifRIUEyWc/edit#slide=id.g160509d43a4_0_12 Jimy Dudhia2:43 PM If someone forks the ccpp physics, do the codeowners go with it? Dustin Swales2:44 PM @Jimy. At the moment, yes Jimy Dudhia2:44 PM OK Jimy Dudhia2:51 PM pbl generic common seems to have specific GFS physics switches in it. Dustin Swales2:53 PM Not too generic Jimy Dudhia2:54 PM hence the GFS in the name for this case Jimy Dudhia2:58 PM yes, they fill tracers according to microphysics options (GFS switches) Jimy Dudhia3:00 PM the codeowners for some of the GFS interstitials need to be GFS people Ligia Bernardet - NOAA Federal3:00 PM https://github.com/ufs-community/ccpp-physics/wiki/Guidance-for-Managing-CCPP-Physics-UFS-Application-Fork
Attendees: Chunxi Zhang, Dustin Swales, Fanglin Yang, Grant Firl, Jim Doyle, Ligia Bernardet, Lisa Bengtsson, Joe Olson, Matthew Dawson, Jimy Dudhia, Jeff McQueen, Andy Hazelton
Discussion:
There will not be CCPP releases to coincide with each SRW/MRW release. No SCM standalone releases for each EPIC App release. Need to move to a "realtime" user documentation? (Not easy to maintain for the developers. Point users to Github issues/discussion for the latest info)
UFS fork now pointing to ufs-community/ccpp-physics. Can't transfer GitHub Issues between organizations (NCAR/ufs-community). Guidlines on UFS fork
"Codeowners" for RTs?
Actions: For Dustin: Create document on how to use remotes for developers in the new fork.
Chat: James Doyle2:27 PM That's a good point about the github information in the pull requests etc. Jimy Dudhia2:37 PM You could even add an issue with a link Lisa Bengtsson - NOAA Federal2:37 PM It looks like in .gitmodules we are still pointing to: url = https://github.com/NCAR/ccpp-framework oops that framework url = https://github.com/NCAR/ccpp-physics Grant Firl - NOAA Affiliate2:38 PM https://github.com/NOAA-EMC/fv3atm/blob/develop/.gitmodules Dustin:38 PM Guidance on working with "the fork": https://docs.google.com/document/d/1DgDrzyVfkC9sM5gM57vlI9KG133broIYQr8RkcDma3k/edit#heading=h.bsfn4r8tpzlq Grant Firl - NOAA Affiliate2:38 PM @Lisa, It looks to me like fv3atm develop is pointing to ufs-community/ufs/dev Lisa Bengtsson - NOAA Federal2:39 PM hm, I think I'm looking in the wrong place Dustin2:39 PM @Lisa https://github.com/NOAA-EMC/fv3atm/commit/dab7d71b2bf1ab2c8dc66353e617e8552efceec3 Lisa Bengtsson - NOAA Federal2:41 PM Maybe ufs-weather-model is not pointing to this updated NOAA-EMC/FV3? chunxi zhang - NOAA Affiliate2:41 PM @Lisa, If you cloned the ufs-weather-model just now, in FV3 directory, it still pointed to NCAR because the merge of the PR https://github.com/ufs-community/ufs-weather-model/pull/1429 is on the way. Lisa Bengtsson - NOAA Federal2:41 PM yes I see now
Attendees: Chunxi Zhang, Dustin Swales, Fanglin Yang, Grant Firl, Jim Doyle, Laura Fowler, Ligia Bernardet, Pedro Jimenez Munoz, Kate Zhang, Lulin Xue, Alex Reinecke
Discussion
Other discussion
CHAT: copy/paste from google meet chat box
***UPDATE: Attendees: Chunxi Zhang, Dustin Swales, Fanglin Yang, Grant Firl, Jim Doyle, Laura Fowler, Ligia Bernardet, Pedro Jimenez Munoz, Kate Zhang, Lulin Xue, Alex Reinecke
Ligia introduced Lulin to the team and Lulin introduced himself in a bit more detail.
Jim Doyle and Alex Reinecke (NRL): presentation about their experience using CCPP in NEPTUNE. ***PRESENTATION LINK
Some exchanges took place between Alex and Fanglin on challenges related to the deep atmosphere dynamics and physics.
Alex mentioned that NRL contributions to CCPP repo are not prioritized to merge back into the main repo. Ligia explained that CCPP team was understaffed during the period when Dom, Grant and Laurie changed jobs. The CCPP team is in better position now to take care of the new activities.
Jim talked about CCPP suites that have been tested in NEPTUNE. GFSv16 (Suite2) and GSDv1 (Suite 4?) results are shown. GFSv16 produced cold bias in low level relative to ERA5 reanalysis (maybe cloud radiation interactions, missing of low-level cloud etc.) NEPTUNE sensitivity to PBL and convection. MYNN improved the results relative to Saturation Adjustment TKE EDMF PBL. Precipitation is sensitive to convection parameterizations. No one scheme outperforms other uniformly. CCPP is very helpful for testing different physics in NEPTUNE. New MYNN improves 200 hPa cold bias relative to old MYNN but is similar at 500 and 850 hPa. This far field effect from the PBL change needs further investigation (discussion with Joe Olson is needed).
***other discussion
Fanglin asked about the large precipitation difference between NEPTUNE and GFS.
Chunxi questioned about the Tiedtke results that the Tiedtke version may have bugs.
Lulin asked if the similar small differences in the low level and large signal higher up exist when different physics were tested.
Lisa: If the test experiments carried out here considered the interactions among schemes? Careful design is needed.
Jim: The CCPP is powerful and convenient for physics test. More work should be done in terms of how to use it better.
CHAT: ***copy/paste from google meet chat box
Grant Firl - NOAA Affiliate2:29 PM There is a PR into ccpp-physics main as of today that has gone through UFS RTs. It should be merged within a week or so.
Ligia Bernardet - NOAA Federal2:42 PM The "GSD" suite is now called the RAP suite
Kate Zhang - NOAA Affiliate3:00 PM I have to leave for the other meeting.
Attendees: Chunxi Zhang, Dustin Swales, Fanglin Yang, Grant Firl, Jim Doyle, Jimy Dudhia, Laura Fowler, Ligia Bernardet, Pedro Jimenez Munoz Kate Zhang, Andrew Hazelton
Slides Discussion about UFS Fork of CCPP Physics (see document with guidelines)
Ligia walked through her slide deck.
2:15 - Back and forth about which fork (NCAR/ufs-community) development PR's should point to. Small adjustment to text in the document.
2:20 - Some discussion on the Roles and Responsibility. Forking could lead to prolific fork with many feature branches, code managers need to manage and "trim" branches.
2:30 - Ultimately we have no ability tell people what to do with their own forks. The UFS-community fork will be maintained by us, so we wan keep it in good order. Remove point #3 from document on development guidance.
2:40 - Documentation update in the fork?
2:45 - Considerations for other models. Jim Doyle mentioned that Neptune uses a copy of the ccpp code, as they are not contributing at the moment, but this will ultimately change.
Decision: Circulate the Fork Guidelines document with this group (include those not present in today's meeting) and the UFS Steering Committee further to collect comments.
Attendees: Mike Ek, Chunxi Zhang, Dustin Swales, Fanglin Yang, Grant Firl, Jim Doyle, Jeremy Gibbs, Jimy Dudhia, Joe Olson, Laura Fowler, Ligia Bernardet, Lisa Bengtsson, Louisa Nance, Matthew Dawson, Pedro Jimenez Munoz.
From Ligia's 14 June 2022 email to this group: Hello CCPP Physics group, Here is what we have planned:
- Announcement: No meeting on 6/29. If you are available/interested, please attend the talk about physics in single precision by Filip Vana (ECMWF) at 10 MT on that day.
- Brief update about the upcoming CCPP v6 public release.
- Update about the CCPP work that DTC will be conducting in the next period-of-performance (which starts on July 1).
- NCAR SIMA review of CCPP starts on 6/16. Is there anyone that can provide a brief update on the goals and process for this review?
- Main topic: Laura Fowler repeat the presentation she gave last week at the WRF/MPAS workshop about a shared repository of CCPP-compliant physics for the WRF/MPAS/CM1 models. While this content overlaps with what she already presented to us last April, it has additional details and it will be an opportunity for us to review and discuss the material. I am looking forward to our conversation! Ligia
Ligia's slide deck for today: CCPP-Physics_Code_Mgmt_20220615: https://docs.google.com/presentation/d/1nB7nX-J59jySRK4Wj6x9Wo0CVUxijm2uT1TBgosIgAI/edit#slide=id.g134e4502a25_0_21.
Laura Fowlder's presentation from the WRF/MPAS workshop at this link: https://www2.mmm.ucar.edu/wrf/users/workshops/WS2022/full_presentations/session1.fowler.pdf.
CHAT:
James Doyle
2:02 PM
I have another meeting at 2:30 MDT, and will have to drop after 30 mins.
Ligia Bernardet
l2:23 PM
@Jow, I was wrong. There is an error in the slide I showed, The RAP suite uses the MYNN sfc layer, as seen in the code (https://github.com/NOAA-EMC/fv3atm/blob/develop/ccpp/suites/suite_FV3_RAP.xml) and in the CCPP Scientific Doc (https://dtcenter.ucar.edu/GMTB/v6.0.0p/sci_doc/html/rap_suite_page.html). I will fix my slide.
Joseph Olson
2:24 PM
OK, no worries.
Jimy Dudhia
2:40 PM
I would say, yes we have the meta files, but mainly use them to document the arguments and hope to keep them compliant with other CCPP efforts.
Grant Firl
2:41 PM
Is there corresponding metadata for the MPAS host?
Jimy Dudhia
2:43 PM
I don't know what stage that effort is at, but I doubt it progressed far.
Ligia Bernardet
2:43 PM
@Jimy Tks
Grant Firl
2:43 PM
But, there has been an attempt to keep physics metadata consistent across schemes?
Jimy Dudhia
2:44 PM
Yes, we have used rules for meta files from some previous version of CCPP itself.
Grant Firl
2:44 PM
OK, thanks. That's helpful.
Ligia Bernardet
2:46 PM
Jimy, so there is a connection between the this effort and the (yet to be completed) CCPP Dictionary of Standard Names?
Jimy Dudhia
2:48 PM
Yes, not updated to latest dictionary but at least same format for meta files.
Ligia Bernardet
2:49 PM
Will a given parameterization (say, YSU PBL) be maintained both in the CCPP compliant shared physics repo and in the regular WRF, MPAS repos?
Will you support simulations that combine CCPP-physics and non-CCPP-physics?
Jimy Dudhia
2:50 PM
Ideally in one place, and each model accesses it from github using manage_externals.
Ligia Bernardet
3:00 PM
I think it would be helpful to continue this discussion in our next meeting, how we continue to collaborate.
Lisa Bengtsson
3:01 PM
I would be curious to learn more about the current differences between MPAS, WRF and CM1 (e.g dycore... ).
Jimy Dudhia
3:01 PM
CM1 is more WRF like, MPAS has no j index
Attendees: Mike Ek, Andrew Hazelton, Chunxi Zhang, Dustin Swales, Fanglin Yang, Grant Firl, Jimy Dudhia, Joe Olson, Laura Fowler, Ligia Bernardet, Lisa Bengtsson, Pedro Jimenez Munoz.
Fanglin presenting (one slide): https://docs.google.com/presentation/d/1PXtDWobuu_r1PZ0gEGBNoCXETr4Cvx36AuNg-3tNfkw/edit#slide=id.p Main points:
- single precision
- GPU
- support for deep atmosphere modeling
- 3D physics
- physics-dynamics coupling
Future: invite guests to provide add'l perspective outside of this CCPP working group.
CHAT:
Ligia Bernardet
Are these proposed discussions CCPP-specific? Is there a role for ICAMS in this discussion?
Ligia Bernardet
Some of these discussions pertain a lot to the CCPP Framework (e.g., 3D approach), so it goes beyond this group
Jimy Dudhia
ocean and wave model coupling
Lisa Bengtsson
Ligia; Filip Vana at ECMWF worked on re-coding the IFS to work with single precision, he could be a good person to ask to give an update on which processes to keep in double precision.
Ligia Bernardet
@Lisa Great, let's make that connection
Attendees: Mike Ek, Andrew Hazelton, Chunxi Zhang, Dustin Swales, Fanglin Yang, Grant Firl, Jeff McQueen, Jim Doyle, Jimy Dudhia, Joe Olson, Kate Zhang, Laura Fowler, Ligia Bernardet, Lisa Bengtsson, Matt Dawson.
Ligia's slides for today: https://docs.google.com/presentation/d/1sQr_FAyGNhJaFaMpXGVbovN4JQi_nNVMzD4vORnNdkg/edit#slide=id.p1 Review/overview of the purpose of this group of CCPP physics developers/POCs. For the most part, the group was in favor of the proposed code management approach. However, there was concern about the need to allocate resources to have true interoperability, that is, to have schemes/suites working with multiple host models.
CHAT: CCPP physics code management meeting notes: https://github.com/NCAR/ccpp-physics/wiki/Minutes-for-2022-meetings
Ligia's slides for today: https://docs.google.com/presentation/d/1sQr_FAyGNhJaFaMpXGVbovN4JQi_nNVMzD4vORnNdkg/edit#slide=id.p1
GSL CCPP job: https://www.usajobs.gov/job/650320400
Andrew Hazelton
There are regression tests for different components of UFS. Does a scheme have to pass all of them or just a general UFS RT?
Jimy Dudhia
Automated tests can be linked to PRs. We do this in WRF but that needs some setting up on a special computing resource.
Fanglin Yang
@Andrew for UFS, we'd like to have any additions to CCPP to pass all RTs relevant to all UFS applications targeted for operation
chunxi zhang
A scheme has to pass all of them as well as ORT tests: threading, decomposition, restart, debug.
Grant Firl
@Jimy UFS can also run RTs by putting tags in the PR.
Andrew Hazelton
Good to know - thanks!
Fanglin Yang
@Dustin, I cannot agree with you more
Jimy Dudhia
@Dustin I also agree. The developer only has to care about models that have their scheme in their RT suites
Fanglin Yang
Also, different host model may have different requirement to meet "operational" standards. We should not let one model's standard host hostage of other models
chunxi zhang
26 SDFs are used in RTs
Attendees: Mike Ek, Andrew Hazelton, Chunxi Zhang, Fanglin Yang, Grant Firl, Jim Doyle, Jimy Dudhia, Joe Olson, Kate Zhang, Laura Fowler, Ligia Bernardet, Lisa Bengtsson, Louisa Nance, Matt Dawson, Pedro Jimenez Munoz, Steve Goldhaber. Guest: Gretchen Mullendore (NCAR/MMM).
Presentation from Gretchen and Laura about NCAR/MMM and their models: WRF and MPAS, and NCAR's SIMA. CCPP to share physics between WRF and MPAS (and SIMA & CM1=Cloud Model 1). MMM works with the community on model (physics) code development, and addressing this work in an Exascale environment with many computational/infrastructure challenges. Gretchen's/Laura's slide deck: https://docs.google.com/presentation/d/1ZbIbFYIy8ewv92qB18asU3Jz6ZXvwVAyad0FO0fk2ls/edit#slide=id.p.
Lively discussion about the needs of e.g. MMM, NOAA, CGD in CCPP. The issue of capgen came up again (CGD working on this).
CHAT:
Mike Ek
2:01 PM]
https://github.com/NCAR/ccpp-physics/wiki/Minutes-for-2022-meetings
Jimy Dudhia
2:35 PM
I see now that YSU in CCPP is basically (i,k) the way we want it.
Steve Goldhaber
2:50 PM
The CCPP Framework needs to support model-dependent runtime parameters.
Attendees: Mike Ek, Andrew Hazelton, Chunxi Zhang, Fanglin Yang, Grant Firl, Jimy Dudhia, Joe Olson, Kate Zhang, Laura Fowler, Ligia Bernardet, Matt Dawson, Pedro Jimenez Munoz, Steve Goldhaber. Guest: Sue Chen (NRL).
CCPP Code management mtg time poll--Round2: https://docs.google.com/spreadsheets/d/1p1SUpLY-MvWX-Nk9pA8sSRn571cScPM4ofJed_cACWs/edit#gid=998114258
Slides: https://docs.google.com/presentation/d/15XyfmaFCUaYZ4bg93zWaexfwfN6SHKrdvYNzOmJoJYk/edit#slide=id.p1
Constants in CCPP rely on host models that they are in. Grant provided 2 slides of information for discussion.
Sue Chen's presentation on: "Toward Consistent Physical Constants sets For Interoperable Earth System Models". Sue's slides: [update link to slides]. Full model interoperability requires careful matching of physical constant sets embedded in each model component. Sue is from the Naval Research Lab in Monterey, CA. Ligia: "planted a seed" about the importance of properly dealing with constants.
"Generalized aerosol/chem interface", re: Hackathon on 29 April and 6 May, 1-3pm (see Ligia's slides above).
CHAT:
Ligia Bernardet
2:13 PM
Slides (other than Sue's) for today: https://docs.google.com/presentation/d/15XyfmaFCUaYZ4bg93zWaexfwfN6SHKrdvYNzOmJoJYk/edit#slide=id.p1
Mike Ek
2:19 PM
@Pedro @Kate: can you please fill in the poll? (link below if you joined after I pasted this in the chat)
Mike Ek
2:04 PM
CCPP Code management mtg time poll--Round2: https://docs.google.com/spreadsheets/d/1p1SUpLY-MvWX-Nk9pA8sSRn571cScPM4ofJed_cACWs/edit#gid=998114258
Mike Ek
2:20 PM
Please put general notes in the poll using the far right column, or add a comment for a given day/time (cell). thanks.
Pedro Jimenez Munoz
2:21 PM
yes, I will fill the pool later today
Andrew Hazelton
2:29 PM
Is there a feel for how big the errors introduced by these constant differences are?
Mike Ek
2:34 PM
Sue: yes, please share your slides with Ligia --and myself, as well. Thanks for your informative presentation!
Mike Ek
2:36 PM
@Pedro: thanks!
Fanglin Yang
2:43 PM
can g [gravity] be called as a function of latitude and height at run time as well ?
Sue Chen
2:47 PM
github location for CPC https://github.com/ESCOMP/PhysicalConstantsDictionary/blob/master/pcd.yaml
Mike Ek
2:56 PM
Thank you Sue!
Andrew Hazelton
2:57 PM
Yes thank you - interesting presentation!
Attendees: Mike Ek, Andrew Hazelton, Chunxi Zhang, Jimy Dudhia, Joe Olson, Laura Fowler, Ligia Bernardet, Lisa Bengtsson, Matt Dawson, Pedro Jimenez Munoz, Steve Goldhaber, Fanglin Yang.
Slides: https://docs.google.com/presentation/d/1OaiS9u9FoBJe0QWyqf5Z61fREb7mo6qisQSimhVCb0w/edit#slide=id.p1
Discussion of CCPP public release as part of SRW App in May 2022 and MRW App in June 2022 led by EPIC. CCPP standalone release in June 2022 led by DTC.
Review of CCPP suites.
Back to the naming convention for suites. Proposal: To minimize disruption, keep existing suite names as is. Implement convention name for new ones that are added. Move wiki page about naming convention to the UFS Weather Model or FV3ATM wiki (Fanglin also requested that we add some information about existing suites, such as date of creation); in ccpp-physics wiki, simply say those are our recommendations and link to the UFS page (and any other page is existing, e.g., for MPAS).
Comment by Jimy: With a fast cadence for UFS releases (per EPIC): how will this affect the suite naming? (CCPP must keep up somehow.)
Review of Physics Points of Contact (PoCs) and UFS Suite Definition Files (SDFs)/Regression Tests (RTs)
Comment by Lisa: Let us not forget those schemes/suites that are perhaps used for research and not destined for operations.
Comment/question by Ligia: move untested schemes not to a legacy directory, but perhaps an untested directory? Ligia to find out if putting untested schemes in a separate directory will complicate building the code (Steve said it should not be a problem). Ligia to find out the mechanics. We did not reach a final decision about what to do with the untested schemes.
Comment/question by Laura: are there SCM-specific RTs? Affects what physics can be included in the SCM.
Jimy requested that we revisit the discussion about standardizing scheme names in an upcoming meeting.
The group wants to be briefed in the SCM regression tests - agenda item for future meeting.
We ran out of time and did not get to the last agenda item (EMC/UFS fork) - agenda item for future meeting.
CHAT:
Ligia Bernardet - NOAA Federal
2:03 PM
Slides for today: https://docs.google.com/presentation/d/1OaiS9u9FoBJe0QWyqf5Z61fREb7mo6qisQSimhVCb0w/edit#slide=id.p1
Mike Ek
2:04 PM
Minutes for 2022 meetings: https://github.com/NCAR/ccpp-physics/wiki/Minutes-for-2022-meetings
Jimy Dudhia
2:05 PM
I am missing
Mike Ek
2:06 PM
@Jimy: You are missing?
Jimy Dudhia
2:06 PM
from the Member list
Mike Ek
2:06 PM
@Jimy: raise your hand and tell Ligia! (I'll call on you)
Andrew Hazelton
2:17 PM
I think you may have mentioned this previously, but there will be a HAFS suite if/when there is a HAFS public release, correct?
Jimy Dudhia
2:19 PM
HAFSv1 is planned to go operational in 2023 just before RRFSv1
Mike Ek
2:30 PM
@Laura: we'll get to your question/comment in a moment.
Jimy Dudhia
2:37 PM
@Mike specifically the suggestion was to return to our previous discussion on file names in the CCPP directory
Ligia Bernardet
l2:37 PM
CCPP Primary Schemes Points of Contact: https://docs.google.com/spreadsheets/d/14y0Th_sSpCqlssEMNfSZ_Ni9wrpPqfpPY0kRG7jCZB8/edit#gid=0
Jimy Dudhia
2:44 PM
Some could be tested in the SCM
Pedro Jimenez Munoz
2:51 PM
that is a good idea
Jimy Dudhia
2:53 PM
not in favor of moving either
Jimy Dudhia
2:54 PM
I agree with Laura
You have to define support too
Jimy Dudhia
2:56 PM
DTC can't support people trying to add these schemes to their host model suites
chunxi zhang
2:59 PM
In the future when we bring a scheme back into RTs, it is very likely that this scheme will be implemented into a new SDF. For this reason, it is ok to put all non-RT SDFs into the legacy directory.
Lisa Bengtsson
3:00 PM
Ligia, is the gravity wave drag suite in the SCM release planned to be different than P8? They are listed differently in your table.
thanks :-)
Attendees: Mike Ek, Chunxi Zhang, Grant Firl, Jeff McQueen Jimy Dudhia Kate Zhang, Laura Fowler, Ligia Bernardet, Matt Dawson, Fanglin Yang.
Slides: CCPP-Physics_Code_Mgmt_20220306: https://docs.google.com/presentation/d/1cb42YO9g0ELLVRjCOuSFThN6MPyCKgTma8kWESdTk5w/edit#slide=id.p1. Ligia presented/the group discussed the upcoming releases with CCPP, and showed the suites planned for upcoming releases. Also discussed was the naming of suites. There was good agreement wrt the naming convention, so we will propagate this proposal to the UFS and SCM code managers. One detail to iron out is that the proposed prefix post-op was considered in bad taste as it sounds like a medical term. There was concern that the terminology post in a suite name can lead to confusion because some interstitial schemes have post in their name. If anyone has a suggestion regarding a better name, please speak up! Just as a reminder, the information we are trying to communicate is that a suite is operational (such as GFS v16) but the codes of the schemes have marched ahead with new development (therefore GFSv16_post_op). One caveat of the proposed nomenclature is that it does not address how ensemble members should be names. Since we are not dealing with this situation for the upcoming release, we decided to leave this discussion for the future. No matter how good the names are, we still need good documentation to explain the details. Additionally, if users want to communicate which code they used (for a paper or presentation), they need to say both the suite name and the version of teh code used (i..e., release number or hash).
Evolving CCPP code management: Fanglin discussed the Emerging EMC needs relevant to CCPP (i.e. CCPP fork at EMC).
CHAT:
Laura Fowler
2:42 PM
Just "post" instead of "post-op"? (Re: naming convention)
Jimy Dudhia
2:44 PM
maybe past instead of post
Jimy Dudhia
2:58 PM
Each lab could have a fork
Attendees: Ligia Bernardet, Mike Ek, Laura Fowler, Chunxi Zhang, Jim Doyle, Lisa Bengtsson, Matt Dawson, Fanglin Yang, Jeremy Gibbs, Joe Olson, Jimy Dudhia.
GitHub: CCPP Physics Code Management: https://github.com/NCAR/ccpp-physics/wiki/CCPP-Physics-Code-Management.
Slides: CCPP-Physics_Code_Mgmt_20220223: https://docs.google.com/presentation/d/1jHRIimE7einhgMHx4TE-WNBth22ARB-WJ4X21p00914/edit#slide=id.p1.
Aerosol workshop review (slides) by Matt Dawson (included in Ligia's slides above).
Attendees: Mike Ek, Matt Dawson, Ligia Bernardet, Andy Hazelton, Louisa Nance, Lisa Bengtsson, Jimy Dudhia, Joe Olson, Kate Zhang, Fanglin Yang.
Slides: Slides PDF or Google Drive
Matt Dawson talked about the aerosol/chemistry interface workshop: purpose and anticipated outcomes. If you are interested in signing up for the aerosol/chemistry interface workshop, please fill this Google form: https://docs.google.com/forms/d/1KcuZxhOTukPfNoRQ1xIY6eWs35fDQODy0-eM1S2SsvE/edit?ts=61aa1b1e.
Questions for Matt:
Jimy: how will physics/aerosol/chemistry would interact?
Matt: e.g. radiation/clouds interaction.
Jimy: PBL interactions important.
Ligia: the workshop is less on the physics interactions, and more the interface (infrastructure) between aerosols/chemistry and the (CCPP) physics.
Ligia presented (see slides per above):
CCPP v6 release planned for no later than June 2022.
Review of previous CCPP releases, and details and upcoming timeline for the June 2022 CCPP release.
Can we: "Release jointly/simultaneously with UFS Medium-Range Weather and/or UFS Short-Range Weather Applications so that a single CCPP release can be used with SCM or UFS, simplifying doc and support"?
A few topics that were brought up by participants that are important to record. In case someone missed the meeting, here is a summary of the main issues and decisions.
A participant said we do not need to release the csawmg suite because nobody is developing those schemes in CCPP.
If RRFS is released, it should have MYNN sfc layer (that is what developers are currently using)
Three participants spoke in favor of only releasing well-established suites so we 1) do not give untested code to graduate students, and 2) do not have the burden to document schemes that we do not know if are going forward. They expressed concerns about releasing the GFS v17 prototype 8 suite.
A participant brought up the need to support a release for a few years so researchers can write their papers. This means that whenever the stack advances on a platform, changes may be needed in the release code to make it compatible. Possible, but considerable work. Good investment of resources?
A participant brought up the need to to run a code very similar to the operational model. In other words, they would like to run the GFS v16 schemes/suites and not the GFS v16 suite using top-of-main code. Another participant thought that top-of-main GFS v16 code is not so different from what was implemented operationally, so they did not have much concern about this.
Naming of suites requires more discussion. DTC needs to clearly communicate what is operational vs experimental. And needs to communicate if something is GFS_vXX suite but with more advanced code.
It was decided to communicate asynchronously via Slack over the next few days and revisit the topic in the next meeting.\
CHAT:
Ligia Bernardet - NOAA Federal2:08 PM
If you are interested in signing up for the aerosol/chemistry interface workshop, please fill this Google form: https://docs.google.com/forms/d/1KcuZxhOTukPfNoRQ1xIY6eWs35fDQODy0-eM1S2SsvE/edit?ts=61aa1b1e.
Andrew Hazelton - NOAA Affiliate2:29 PM
Will the GFSv17 suites be available in the public release at some point soon?
Lisa Bengtsson - NOAA Affiliate2:42 PM
I think we should be careful of calling a suite GFSv17_beta, to avoid confusion that it is GFSv17 until it becomes operational.
Lisa Bengtsson - NOAA Affiliate2:59 PM
It would be nice if we could continue the discussion next time.