docs[cartesian]: Update ADRs with recent development#2512
docs[cartesian]: Update ADRs with recent development#2512romanc wants to merge 5 commits intoGridTools:mainfrom
Conversation
We have been lagging behind on updating the ADRs. This PR updates a bunch of ADRs to reflect recent development in `gt4py.cartesian`.
romanc
force-pushed
the
romanc/adr-update
branch
from
f93ce73 to
250d6c4
Compare
| Power users of GT4Py have now a way to stream memory directly from (and back to) Fortran without a copy. | ||
|
|
||
| To help with the growing number of DaCe-based backends, we introduce an automatic match for DaCe-based backends between layout and schedule. This makes the default scheduling always cache-optimal by construction and supersedes a previous rubber band fix introduced with the `dace:cpu_kfirst` backend. | ||
|
|
There was a problem hiding this comment.
do we need to talk about the consequence of having another backend and the lack of extra overhead for maintainig this? And can we say that with the new way of describing backends this also does not add significant cognitive load to have to keep more in mind?
There was a problem hiding this comment.
Valid points, I've added a paragraph. Let me know what you think.
There was a problem hiding this comment.
just in general, GT has a OpenMP requirement: https://github.com/GridTools/gridtools/blob/c5a85af55fd4df8629b8f64c88673261ebcb7624/docs/_sources/introduction/introduction.rst.txt?plain=1#L61
This is not tackled with a slightly more general name GT4PY_CARTESIAN_ENABLE_OPENMP compared to the use that is just to target DaCe backends.
I think all the choices made are very valid, but it still strives us further away from being able to use the GT-backends with coverage. we might need to think about how to handle this drift
There was a problem hiding this comment.
I re-wrote the dace/openmp ADR as general compiler detection ADR given the PRs that merged in the last week. In doing so, I've picked up the GridTools / OpenMP defaults dilemma, elaborated our choices and how to undo them (e.g. what we do in the daily CI with PR #2530). Let me know what you think.
Co-authored-by: Tobias Wicky-Pfund <tobias.wicky@meteoswiss.ch>
## Description In the context of extending compiler support, we introduced CXX compiler detection in PR #2520 with the goal to add compiler dependent flags. Doing so, we decided to turn off OpenMP by default on `apple-clang` because `apple-clang` doesn't ship with OpenMP out of the box. This trips daily CI on the macos runner because the GridTools-based backends expect OpenMP to be available. This PR restores OpenMP on macos runners on the daily CI by setting the environment variable `GT4PY_CARTESIAN_ENABLE_OPENMP=True` to override the default. Tested by running daily CI on this PR, see [here](https://github.com/GridTools/gt4py/actions/runs/23043269746/job/66926225822?pr=2530). ## Requirements - [x] All fixes and/or new features come with corresponding tests. Covered by daily CI - [ ] Important design decisions have been documented in the appropriate ADR inside the [docs/development/ADRs/](docs/development/ADRs/README.md) folder. An ADR for compiler detection and default flags (for OpenMP) will be added with #2512.
2 participants
Description
We have been lagging behind on updating the ADRs. This PR updates a bunch of ADRs to reflect recent development in
gt4py.cartesian.Requirements
N/A