-
Notifications
You must be signed in to change notification settings - Fork 49
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Functional: Domain support in cpp backend (#807)
* add support for Cartesian domain * hacky support for unstructured * introduce DimensionKind * fix Cartesian * hacky doctest fix * domain -> cartesian_domain | unstructured_domain * fix doctest * add domain check in embedded and deduce in implict fencil * ffront tests for domain deduction * remove resolved TODO * remove TODO * fixes after merge * document with adr * update tests and cleanup * fix test * Update src/functional/ffront/decorator.py Co-authored-by: Rico Haeuselmann <r.haeuselmann@gmx.ch> * implement review comments * remove commented code Co-authored-by: Rico Haeuselmann <r.haeuselmann@gmx.ch>
- Loading branch information
Showing
25 changed files
with
363 additions
and
78 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
65 changes: 65 additions & 0 deletions
65
docs/functional/architecture/0008-Mapping_Domain_to_Cpp-Backend.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,65 @@ | ||
--- | ||
tags: [] | ||
--- | ||
|
||
# [Mapping Dimensions to the C++-Backend] | ||
|
||
- **Status**: valid | ||
- **Authors**: Hannes Vogt (@havogt) | ||
- **Created**: 2022-06-29 | ||
- **Updated**: 2022-06-29 | ||
|
||
This document proposes a (temporary) solution for mapping domain dimensions to field dimensions. | ||
|
||
## Context | ||
|
||
The Python embedded execution for Iterator IR keeps track of the current location type of an iterator (allows safety checks) while the C++ backend does not. | ||
|
||
### Python side | ||
|
||
On the Python side, we label dimensions of fields with the location type, e.g. `Edge` or `Vertex`. The domain uses `named_ranges` that uses the same location types to express *where* to iterate, e.g. `named_range(Vertex, range(0, 100))` is an iteration over the `Vertex` dimension, no order in the domain is required. Additionally, the `Connectivity` (aka `NeighborTableOffsetProvider` in the current implementation) describes the mapping between location types. | ||
|
||
### C++ side | ||
|
||
On the C++ side, the `unstructured_domain` is described by two (size, offset)-pairs, the first is the horizontal/unstructured dimension, the second is the vertical/structured dimension. The fields need to be tagged by `dim::horizontal` (alias for `integral_constant<int, 0>`) and `dim::vertical` (alias for `integral_constant<int, 1>`). If a shift is with a `Connectivity`, it is applied to the dimension tagged as `dim::horizontal`, no checking is performed. | ||
The `cartesian_domain` takes a `hymap` from dimension tags to (size, offset)-pairs, Cartesian shifts assume that the offset tag and the dimension tag are the same. | ||
|
||
### Problems | ||
|
||
- How can we map from the unordered domain on the Python side to the ordered `unstructured_domain` on the C++ side? | ||
- How can we map from user-defined dimensions labels (`Edge`, `Foo`, etc) to `dim::horizontal` in the unstructured case? | ||
- For Cartesian we need a mapping of offset to dimensions. | ||
|
||
## Decision | ||
|
||
### Mapping the Domain Arguments | ||
|
||
We decide, for `unstructured_domain` order matters. | ||
|
||
### Mapping User-Defined Labels to `dim::horizontal` | ||
|
||
We introduce tags in the `Dimension` object on the Python-side, the bindings need to consume these tags for remapping. | ||
|
||
Example (this is implemented in the current PR, but could be done differently in the future) | ||
|
||
```python | ||
class Dimension: | ||
value: str | ||
kind: DimensionKind | ||
|
||
# the following field doesn't have correct default order, as without remapping we would interpret first dimension as dim::horizontal | ||
np_as_located_field(Dimension("K", DimensionKind.VERTICAL), Dimension("Vertex", DimensionKind.HORIZONTAL)) | ||
``` | ||
### Mapping of Cartesian Offsets to Dimensions | ||
|
||
When lowering from iterator IR to gtfn_ir, we replace Cartesian offset tags by Dimension tags. | ||
|
||
## Alternatives Considered | ||
|
||
### C++ backend could track locations | ||
|
||
This was implemented, but was discarded to simplify the C++ backend. | ||
|
||
### Embedded execution could implement the C++ execution strategy | ||
|
||
We would give up on several safety features if we don't track locations, therefore we didn't consider this direction. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.