-
Notifications
You must be signed in to change notification settings - Fork 64
CCPP Framework Meeting Minutes 2021 12 09
goldy edited this page Dec 9, 2021
·
4 revisions
- Not discussed, no progress to report
- Convenience units, etc (all triggered by https://github.com/ufs-community/ufs-weather-model/pull/907 and associated PRs)
- Best option would be to pass around the actual quantities and not functions of it
- But if the function is used in many places, then this slows things down
- Need to understand how widespread this situation is (is it just
log(Pa)
or are there more such cases, e.g. in chemistry) - We need to be able to support modified variables such as
xyz_multiplied_by_timestep_abc
, but this is not interoperable - Are these non-portable qualifiers in the dictionary?
- Add information to section "Best practices" in the CCPP technical documentation to try to avoid using these non-portable variables and units, but don't make it a rule
- Current exampled in ccpp-physics:
log(Pa)
andPa**kappa
(Dom to check if we could pass the actual quantities instead
- Best option would be to pass around the actual quantities and not functions of it
- Is specific humidity the mass mixing ratio of vapor with respect to moist air or with respect to total mass (rule 5)?
- Correct would be w.r.t. total mass, but UFS / ccpp-physics are using it incorrectly as w.r.t. moist air
- AMS glossary says specific humidity is w.r.t. total mass, but there are other definitions in the literature
- Outlow use of specific humidity,m and always use
mixing_ratio_of_vapor_wrt_xyz
? - Dom to discuss this with Moorthi and Fanglin (Moorthi on AL until the end of the year)
- Update from last CCPP Physics Code Management committee meeting: Matt's suggestion acceptable to all
- Keep requirements doc as historical evidence
- Add watermark on each page? Laurie knows how to do this, Ligia will do it
- Then use CCPP tech doc for current capabilities/requirements + github issues for future development
- Keep requirements doc as historical evidence
- Reschedule meeting to accommodate new schedules
- Steve will look at the NCAR calendars and coordinate with Ligia and Grant (share calendars maybe?)
- Hot candidate is Tuesday 4pm from December 16 on.
- Who will prepare and run the framework meetings in Dom's absence?
- Dom will participate until Feb 27, 2022, but stop preparing and leading the meeting by the end of 2021
- Steve will take over in the interim, Dom will take notes
- Handling constituent information originating from a physics scheme
- Not sure what the question is, postponed
- Specifying a data source for an input variable (see #413)
- Keep it simple for now: Use only filename input (with custom standard name) and assume that scheme knows what to read from the file.
- Matt asks about what tools will always be available to read NetCDF files?
- Look into NetCDF support initiatives (ESPC?)
- Grant finds: according to https://github.com/NOAA-EMC/NCEPLIBS-external, UFS requires the following NetCDF libraries: netcdf-c-4.7.4, netcdf-fortran-4.5.3
- Will need more complex interface for data which the host model needs to read, possibly regrid, and provide to schemes.
- CCPP visioning workshop
- Everyone agrees that this workshop is a good idea, see previous notes for details
- Mike and Ligia are spearheading a proposal due mid-Dec. Mike will share working doc
- New hires:
- NOAA-GSL is proceeding with new hire for a senior Federal position. New hire will be partly on CCPP framework development but also partly in other areas such as coupling
- Mike is putting together a PD for a new hire in DTC. Will get feedback from CCPP Framework committee members and try to get a posting up this month.