Final Discussion about questions like:

• Are there inherent contradictions, and have we ideas towards a harmonization?
• What are the true open problems, and can we arrange all the related efforts under a leading concept?
• How can we organize a workflow of complementing contributions to the model, avoiding double work as well as undesired interference?

Discussion about questions like:

• Could the SCM still be a place for
  - compiling a coherent and consistent development and implementation plan for short to longerrange from all desired initiatives for model development?
  - coordinating the order and priorities of code-implementations, aiming to minimize overall work and mutual disturbances, as well as to optimize efficiency of individual engagement?
• Should the WG3ab leaders (or delegates) be included into the non-technical gate-keeping process under GitLab for ICON-nwp as regards a review of content?
• Should, perhaps, new physics WGs be established according thematically connected issues, which explicitly include developers outside of COSMO/NWP (such as climate people and ICON developers in general)?
• Should, in contrast, the physics WGs (a part of COSMO-SMC)
  - restrict to particular COSMO/NWP issues?
  - and provide an overview of other development at the most?
• Should, perhaps, a kind of “core model-development” group be established (dealing with the matters of our WGs 2,3ab) and should this be closer connected with the already existing ICON-developer group?
• Should SMC also organize general aid for special problems or burden related to model development in the sense of a proper division of work?

Towards developing a common understanding of model developers about the current needs and shortcomings regarding the process of finally getting a larger development on top of already operational code into the master-code, facing the

• large and further developing technical overhead of the ICON code, e.g., due to GPU-facilities
• high and still increasing update rate of the master code and the BuildBot test-infrastructure
• implementation of not tunable (particularly empirical) extensions apart from consistent parameterization strategies
• large formal code reorganization, running in parallel (organized and planned by ICON groups)
• growing list of coding standards (formulated and agreed by ICON groups)
• obligatory readiness of the code for various computer systems, methods of parameter variation or applications apart from NWP
• alternative non-operational parameterization schemes for the same purpose with all their overhead and special requirements

Discussion about wishes like:

• Alternative parameterizations → Single, consistent code with upgrade options
• Empirical extensions: Hard-coded with fix numbers → Adapting to new, more advanced parameterizations.
• Better arrangement with running code-development, when introducing extensive modifications of technical overhead (such as ACC-directives) into the related master-code
  - Adaptation of related review/gate-keeping
  - Taking-over of related modification in development branches by those actions as well, if desired
• Technical support: mandatory part of future action-planning
• Better division of work to associated experts within the community:
  - Support at using GitLab efficiently
  - Support, if debugging is necessary on external machines
  - Support at achieving readiness of new development for GPU
  - Adaptation of too sensible BB-tests, failing due to pure difference of rounding errors.
  - Providing tools helping to prescind from minor modifications (such as blanks and comments) for review with GitLab
  - Support of non-technical gate-keeping by factual experts of related matters