# [Greenline] Metric fields factory

<!-- Add the tag for the current cycle number in the top bar -->

- Shaped by:
- Appetite (FTEs, weeks):
- Developers: <!-- Filled in at the betting table unless someone is specifically required here -->

## Problem
<!-- The raw idea, a use case, or something we’ve seen that motivates us to work on this -->
Over the last cycles the computation of ICON's metric fields was ported to `icon4py`. We now want to use them in the model.

## Appetite
<!-- Explain how much time we want to spend and how that constrains the solution -->
One developer, full cycle. If metrics fields are done the same work can be extended to the interpolation coefficients.

## Solution
<!-- The core elements we came up with, presented in a form that’s easy for people to immediately understand -->
The metric fields are static fields possibly used in several model components. We want to provide these fields through a factory that is responsible for allocating memory and and computing the fields on demand.

### Properties
- The factory should be the only way to request the fields.
- Fields are allocated and computed upon request and cached.
- The fields are requested via a string name, which is a name taken from CF conventions or built in a similar way.
- Since the fields depend on each other, requesting a field will possibly trigger the computation of its dependencies
- The Factory can be queried for metadata like `units`, `dimensions`, ...
- factory might also return a list of available fields.

The factory should be build up statically, but data needed for field computation like the GRID size, topology and geometry fields can only be passed once a concrete simulation is setup.

### steps
Integrate the metric fields in the factory:

1. find useful name, (inspired by [CF conventions](https://cfconventions.org/Data/cf-standard-names/current/build/cf-standard-name-table.html), [CF name guidelines](http://cfconventions.org/Data/cf-standard-names/docs/guidelines.html) and build up field metadata. The relevant information (meaning, units, dimension) is normally available from comments in ICON where they declare the fields and/or in icon4py docstrings)
2. create a `FieldProvider` for the field computation with the relevant `func`, dependencies, compute domain.
3. register the provider in the factory.

Test the factory by running it with the test field

### draft solution

Very ad hoc prototype : https://github.com/C2SM/icon4py/tree/prototype_fields_factory:

## 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] Naming of fields
- [x] dictionary with metadata
- [ ] build up the metadata dictionary for the metrics fields
- [ ]
- [ ] FieldProvider:
- [x] Dummy Provider for fields computed elsewhere (geometry, interpolation...)
- [x] Protocol and implementation for GT4Py Programs, Numpy functions
- [ ] Open: Need infrastructure for run time lookup of:
- [ ] configuration parameters
- [ ] geometry
- [ ] vertical index offset computation
- [x] Factory
- [x] Register provider (definition time)
- [x] validation of dependency tree (definition time)
- [x] retrieve and compute fields (model run time)
- [ ] Setup factory for metrics fields and test field construction
- [ ] Task 4