# Field view features

###### tags: `functional cycle 10`

Appetite: 2-3 weeks

Developer: Till, Peter (for tuple return in C++ backend)

## Goal

Complete field view features from previous cycle. At the end of the cycle all features should work reliably including the C++ backend.

## Features

### Math builtins

Already implemented and tested in https://github.com/GridTools/gt4py/pull/803. In preperation for review.

### Scan

Implemented and tested with the embedded backend in https://github.com/GridTools/gt4py/pull/837.

Blocked by:
- [PR 854: - Allow returning multiple fields from a field operator](https://github.com/GridTools/gt4py/pull/854) (design and implementation incomplete)
- [PR 853: - Improve UnpackedAssignPass pass](https://github.com/GridTools/gt4py/pull/853) (review missing)

C++ backend integration blocked by
- [PR: 824 - Scan Canonicalization: Support for Scans in C++ Backend](https://github.com/GridTools/gt4py/pull/824)
- [PR: 835 - Compiled backends integration](https://github.com/GridTools/gt4py/pull/835)

### Field operator with Tuple return

Allow calling a `field_operator` that return a tuple of fields from `program`, i.e. the following should work:

@field_operator
def multicopy(
    inp1: Field[[IDim], float64],
    inp2: Field[[IDim], float64]
) -> tuple[Field[[IDim], float64], Field[[IDim], float64]]:
    return inp1, inp2

@program
def multicopy_program(
    inp1: Field[[IDim], float64],
    inp2: Field[[IDim], float64],
    out1: Field[[IDim], float64],
    out2: Field[[IDim], float64],
):
    multicopy(inp1, inp2, out=(out1, out2), offset_provider={})

Work on the prerequisite, [calling field operators with multiple field return values from field operators](https://github.com/GridTools/gt4py/pull/854), has started, but needs more work. With small extensions to the PAST, support in the embedded backend is rather straighforward. For the C++ backend, support is missing completly and should be added. If this is not possible in time automatically splitting into multiple field operator calls with a single return field is a viable workaround.

### Generalized Neighbor Reduction (optional)

Implement a general neighbor reduction in field view. Then implementation `neighbor_sum` and `max_over` as library functions.

*This task could be tackled (with some help) from a person with intermediate knowledge of the frontend.*

### Shift/slice of sparse fields (blocked)

Sparse fields can only be used in reductions so far. Implement access into a sparse field on specific neighbors, i.e. slicing in the sparse dimension. Requires a design decision, see https://github.com/GridTools/gt4py/issues/823.

*The appetite for this feature greatly depends on the design choice taken.*

## Non-Goals

Resolving bugs in the C++ backend integration is not part of this project and help from Rico & Peter is appreciated.

## TODO

- [Functional: extend iterator type inference to support math builtins](https://github.com/GridTools/gt4py/issues/862)
- [Functional: extend where to accept two scalars](https://github.com/GridTools/gt4py/issues/859)
- Check we have a good error message when field operator returns a sparse field
- Tuple argument to field operator (How about tuple of sparse fields as argument. Conclusion: should work)
- Check that output field type matches deduced return type

    out = np_as_located_field(IDim)(np.zeros((num_edges,)))
    @field_operator
    def foo() -> Field[[Edge], float64]:
        return broadcast(1., (Edge,))

    foo(out=out, offset_provider={})

- Add dtype to LocatedField protocol
- Add location to GTCallable
- Test calling scan operator from field operator