---
# System prepended metadata

title: '[Greenline] Metric fields factory'
tags: [cycle 24 - 08/24, cycle 23 - 07/24]

---

# [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

