Skip to content

CCPP Framework Meeting Minutes 2019 03 28

Jump to bottom
goldy edited this page Mar 9, 2020 · 1 revision

Prepare for meeting with NUOPC team (Cecilia, Gerhard, Raffaele), Fri 03/29/2019

  • Discuss initialization
    • reading namelist files - how are these namelist components are put together in FV3, is this something other models do, too? reading and broadcasting the information?
    • CCPP suites need to be able to read their own stuff without interaction with the host model
  • discuss approach to constants, get Raffaele to help us think about how this may look like
    • how to get there from the dictionary
    • auto-generate a module from Raffaele's library that we can import in the model and the physics?
    • either through Raffaele's program or through an add-on to capgen that auto-generates the metadata for Raffaele's library
    • related to this: auto-generate machine.F (without ifdefs inside), depending on the compile-time options - call it something else
      • what would be a good name? machine.F probably not, call it kinds.F?
      • already an issue open for this
    • can use this approach even without Raffaele's library - Steve will be trying this and we can adopt it for GFS+
  • from EMC visit: NUOPC field dictionary, are these standard names compatible with what we are using
  • calling single CCPP parameterizations through NUOPC cap would still have a suite cap on top of it (with just one parameterization inside)
  • Cecilia doesn't think it is viable to generate the NUOPC cap; do we understand what the issue is?
  • CGD now has a group of seasoned ESMF/NUOPC developers, let's consult with them to see how easy/difficult it would be
  • two aspects to it:
    • having a CCPP compliant model means it should be possible to run some physics through CCPP directly, and some through NUOPC-CCPP interfaces
    • alternatively, a non-CCPP compliant model should be able to call a NUOPC-CCPP component without modification (NUOPC principles)
  • arrange a point of contact for Steve to work with (Gerhard), also need a pointer to a model so that we can get started
  • NUOPC field dictionary <-> CCPP standard names?
    • in any case, we need a library of standard names for interoperability

CCPP requirements

  • requirement D16: can't have two variables with different names and same physical meaning?
    • for example, temperature at mid points and at interfaces? what is the best convention for standard names for these
    • document various sets of variables that are related but not exactly the same
    • add clarification that standard_name is ... "physical meaning"
  • move google doc requirements to ccpp-framework wiki? http://markitdown.medusis.com ?
  • additional requirement/suggestion/coding standard: pointers discouraged in schemes

Release plan CCPP in June 2019

  • part of GMTB's statement of work
  • originally planned with NEMSfv3gfs, but this is delayed
  • public will have ccpp-framework, ccpp-physics with SCM; plus an internal release for NOAA people with NEMSfv3gfs
  • need to cut from the master in the next 1-2 months
    • Won't be able to use new metadata standard, so what are the new features
    • Steve needs to have capgen running for NCAR model(s?) by mid April
    • after that, vertical flipper, infrastructure for handling conversions (unit changes, ...)
    • should the new capgen be in the release, even if not used? probably yes, because it is a good sign of our collaboration
    • need to discuss documentation

CCPP Framework wiki

Clone this wiki locally