Skip to content

CCPP Framework Meeting Minutes 2020 11 17

Jump to bottom
Dom Heinzeller edited this page Nov 17, 2020 · 14 revisions

Agenda

  • capgen.py progress
  • Transition to capgen.py
  • NOAA / NCAR-ACOM model development
  • Other business

capgen.py progress

  • Steve is making progress, working on build issues (compile all suites if none specified; can use wildcards etc.)
  • Need to talk about how to implement the unit conversion in capgen.py
  • October 6 meetings notes list all issues that need to be addressed - add label to issues to identify

Transition to capgen.py

  • Updated DTC timeline and resource chart (https://docs.google.com/spreadsheets/d/1XbSF1ejYcPMrVtZtk1OSiMX-vI5srLkwEUhyAirGr8k/edit?usp=sharing)
  • Things that need to happen for transitioning UFS to capgen.py (https://docs.google.com/document/d/1M3mCO3ESR9OJqLyUbQf-ahJtmfmGKilZlWaBTxsfMRk/edit?usp=sharing)
  • Follow up on discussion of last week on removal of optional arguments (or not)
    • From two weeks ago: Do we need consent from developers to not support optional arguments? Do we tell developers to not use them right away? Do they need alternatives? Whom to contact? EMC, GSL, Robert & Dustin
    • Dom will do
  • timestep_init, timestep_finalize - issue with too long subroutine names in Fortran
    • Internally use tsinit and tsfinal for ccpp_prebuild.py
    • Happens frequently with SCM, but only created warnings not errors - different compiler (GNU vs Intel)? 39 | function FV3_GFS_2017_gfdlmp_regional_c768_fast_physics_timestep_init_cap() result(ierr) | 1 Error: Name at (1) is too long
    • We could set limits of 15 or 20 characters for the suite name, and similar for the group name
      • truncate using some logic, and then put the full name in a comment
      • recommend users to use shorter names for suites and groups to avoid having their cap names truncated
  • Consolidation of standard names (Ligia and Grant) - https://docs.google.com/spreadsheets/d/1kWDC7_2sagm-PTP_tXaGyI3O3sJFK8FY9FElQbb6V3o/edit#gid=613941307
    • No progress since last week
    • Grant working with Dave in the context of getting MPAS physics into CCPP

NOAA / NCAR-ACOM model development

  • Ligia attended a meeting with NOAA-GSL and NCAR-ACOM folks (Georg Grell, Mary Barth, Andrew Conley)
  • NCAR-ACOM is implementing their physics differently (Fortran API that creates argument lists at runtime), because they think that CCPP would be too complicated for this purpose (different metadata files for different argument lists for the chemistry routines)
  • A follow-up email summarizes action items, one of them to test a MICM-generated chemistry code (CCPP compliant) in the NOAA model
  • Steve: ACOM should be able to do what they need to do with CCPP (some work needs to be here, but there is no principal issue)
  • The "ACOM way" would require every model to implement the Fortran API in their model, something that the CCPP is avoiding
  • How much of this has been discussed with the SIMA and MUSICA working groups? Is there a communication issue?
  • Should we invite ACOM again to discuss the issues? Developing in different directions may also impact GSL chemistry work etc.
  • We (some of us at least) should look at the documented prototype of ACOM's approach to understand better what they are trying to do; see https://github.com/NCAR/DemoChemMapping

Other business

  • Progress on CCPP physics governance: Louisa Nance (DTC) has contacted several organizations to name representatives

CCPP Framework wiki

Clone this wiki locally