# Finalize Numpy GTC backend ###### tags: `cycle 3` shaped by: Florian, Rico ## Appetite Full cycle (6 weeks) for 1-2 devs If done early we can jump onto one of the other GTC related projects. ## Problem The GTC toolchain is missing a python-only backend. * `gt4py` should always provide a pure python solution * `numpy` is well known and can be used to verbose the parallel model * A lot of work already done by Rico, completion is not far off What is missing: The current incomplete implementation was at the time blocked by the lack of extent calculation available in gtc, therefore the generated code is only correct in simple cases. This has been solved in the meantime and should allow correct handling of more complex cases without making the generated code hard to read. This is not to say that the implementation is trivial. The OIR has changed quite a bit since the current stale PR, so some work will have to go into tracking these changes. ## Solution In a first step, the existing tests should be made to pass after updating to GT4Py master. Most of this work will be in the lowering OIR -> NpIR. NpIR should only be extended if necessary but this might be unavoidable. Ideally the backend should be merged but still be excluded from the full code generation test suite after this. After that, any missing frontend features should be implemented. This usually spans OIR->NpIR, NpIR and code generators. After this, if not before the numpy backend must be merged into master to avoid the branch going stale before the next cycle. As a third priority the numpy backend should be made to work from an OIR that goes to as close to the same transformation pipeline as in the GTCPP backends (avoid surprises when moving from Numpy to GTCPP). If there is still time left, it can be invested into coordinating with other upcoming PRs to recognize conflicts early. A possible breakdown into steps for the first and second part would be: * Update to `master` OIR (after merging there are some test failures) * Fix broadcasting issues * Introduce horizontal regions (OIR ready) * Introduce vertical offset (OIR ready) * Introduce while loops (OIR ready) ## Potential Rabbit Holes * Trying to generate code that is (almost) as nice to read as (good) handwritten numpy code is a good thing to aim for but one should not obsess about it. ## No Gos This should remain a strict `numpy` implementation from OIR downstream and not address any upstream design issues.