# [DaCe] SDFG Convertible gt4py programs

###### tags: `cycle 20`

- Shaped by: Christos
- Appetite (FTEs, weeks):
- Developers: Christos & Edoardo

## Problem
<!-- The raw idea, a use case, or something we’ve seen that motivates us to work on this -->
In the previous cycle I have prototyped the Halo Exchange Library node in DaCe (either Python Callbacks to GHEX pyhton interface, or native GHEX calls inside a DaCe tasklet). Now, we will have to pass from the PoC phase to actual/merge-able changes in icon4py, gt4py, dace & GHEX.

Up to this point, I have fused all the sdfgs of the diffusion module manually. We should devise a framework that will automate this.

Current solution:

@dace.program
def fuse(...):
    sdfg_0(...)
    sdfg_1(...)
    _HALO_
    .
    .
    .

Suggested solution:

@dace.program
def fuse(...):
    stencil_0.with_backend(backend)(...)
    stencil_1.with_backend(backend)(...)
    _HALO_
    .
    .
    .

This means that the gt4py programs should implement the [`SDFGConvertible` protocol](https://github.com/spcl/dace/blob/master/dace/frontend/python/common.py#L61).

## Appetite
<!-- Explain how much time we want to spend and how that constrains the solution -->
A cycle should be ok (just for the implementation of the `SDFGConvertible` protocol).

Once the SDFGConvertible part is fully automated, we should move towards the proper integration of the HALO exchange lib node, and prepare the diffusion module for a full DaCe orchestration.

## Solution
<!-- The core elements we came up with, presented in a form that’s easy for people to immediately understand -->
The short-term objective is to automatically generate an SDFG at module level. This will be achieved by decorating the stencil call method, as suggested above, to generate the corresponding SDFG and call signature. An important criterion should be not to change the API a lot, i.e. how we call now the stencils should remain more-or-less the same inside a `dace.program` annotated region. For the HALO exchange, we will use the HALO library node prototyped in the previous cycle. Although this library node has a limited interface, specialized for the GHEX backend, it allows to run initial benchmarks on the dace backend on a complete module.

In parallel, we will look at the HALO library node and GHEX library to define a more generic interface that allows to express the HALO-exchange pattern in the SDFG. The GHEX code for configuration of the HALO pattern is currently located outside of the SDFG, so the HALO pattern is fixed for one SDFG. The long-term goal is to use dace to configure and optimize the HALO pattern and automatically generate the stencil code for the specific pattern.

## Rabbit holes
<!-- Details about the solution worth calling out to avoid problems -->

## No-gos
<!-- Anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fit the ## appetite or make the problem tractable -->

## Progress
<!-- Don't fill during shaping. This area is for collecting TODOs during building. As first task during building add a preliminary list of coarse-grained tasks for the project and refine them with finer-grained items when it makes sense as you work on them. -->

- [x] SDFGConvertible Protocol: implemented for both GT4Py programs & GHEX exchange objects
- [x] The suggested solution as drafted above works fine