Which knowledge do we need to transfer gt4py.next not much to transfer, because doesn't go very deep Peter wrote most of the code so far later: for optimizations we can learn from DaCe people gt4py.cartesian graph is in nice structure (GPU-nice) building the pipeline + some GT4Py specific optimizationsideally we would like to transfer Cartesian optimizations to next vertical: is not needed to transfer because we have scan and k-caches are explicit

How to work in this document: Only work in the most recent subsection (first ## after this intro). Discussions previously are considered archived, if you want to further discuss something, pull u a summary of the point and continue discussing there. Goal: Improve the dycore to be domain science friendly. (Not to be confused with the GT4Py feedback workshop.) Discussions from 2022-10-18 "Implementation from paper" Summary: HV mentioned "as close as possible to paper" as a possible goal for the refactoring. MB doesn't want to emphasize "implementing from paper" to manage expectations. WS states that the e.g. the ICON paper is far from the ICON implementation. HV: I would be interested in better high-level goals to set the direction in which we want to go. MB brought one which I summarize below as "Software Architecture". But I would be interested to hear other ideas (from scientist point of view) what we want to optimize for in a domain science readability refactoring. The best measure for me is still as close as possible to paper and that does not imply formulas before discretization etc, but as close as possible within the boundaries of current GT4Py. (Note: I am asking for what the high-level goal of this refactoring is, not what the goal of GT4Py or somethign else is.)

Agenda Brief status updates (I propose, no details, just status of where we are.) status of GT4Py unstructured frontends and backends status of MCH benchmarks How we (GT4Py) currently use Shape-Up

Discussion between Enrique and Hannes. Problems discussed: When is the symbol table available? Can we construct it in a transformation pass for the new tree? Related: When can we access SymbolDecl information in a SymbolRef? Current approach is simple: In construction of a node with SymbolTableTrait, we run a pass that collects all symbols and stores it in a field in the node.

Pass Manager for Eve GTBench for Python multinode GT4Py Interface with Fortran Small batch stuff (which could include Vulcan support) Hand-optimize unstructured examples (standalone benchmarks) Use the hand-optimized examples and use a structured implementation What's the mesh on the GT4Py side? Storages for unstructured How do we deal with fields on meshes in Python?

Problem FVM requires global reductions. A first step is an efficient C++ implementation for different architectures which works with our data structures/abstractions. Goal Implement a GridTools library for single node reduction of SIDs which handles max/min, product, sum and dot product. TODO define API requirements. Performance Performance of the implementation will be tracked by the GridTools perftest framework. At the end of the cycle, functionality with decent performance should be achieved. Optimizing for best performance is a nice to have.

b = 0 in forward computation b = 1 a = b[k+1] 2 stages in forward multistage a