Skip to content

docs[cartesian]: Update ADRs with recent development#2512

Open
romanc wants to merge 2 commits intoGridTools:mainfrom
romanc:romanc/adr-update
Open

docs[cartesian]: Update ADRs with recent development#2512
romanc wants to merge 2 commits intoGridTools:mainfrom
romanc:romanc/adr-update

Conversation

@romanc
Copy link
Contributor

@romanc romanc commented Mar 5, 2026

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

  • All fixes and/or new features come with corresponding tests.
    N/A
  • Important design decisions have been documented in the appropriate ADR inside the docs/development/ADRs/ folder.

romanc added 2 commits March 11, 2026 10:33
We have been lagging behind on updating the ADRs. This PR updates a
bunch of ADRs to reflect recent development in `gt4py.cartesian`.
@romanc romanc force-pushed the romanc/adr-update branch from f93ce73 to 250d6c4 Compare March 11, 2026 09:56

## Context

During performance optimization work, we discovered that there's currently no way to stream memory directly (i.e. without copy) from Fortran into a DaCe-based backend. For hybrid Fortran/GT4Py applications, this can be a bottleneck.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
During performance optimization work, we discovered that there's currently no way to stream memory directly (i.e. without copy) from Fortran into a DaCe-based backend. For hybrid Fortran/GT4Py applications, this can be a bottleneck.
During performance optimization work, we discovered that there's currently no way to stream memory directly (i.e. without copy) from Fortran into a DaCe-based backend. For hybrid Fortran/GT4Py applications where we have no control over the memory layout of the data, this can be a bottleneck.


## Decision

We decided to add a backend that allows directly streaming memory from Fortran into GT4Py stencils (and back) without any copies. To communicate the expected device and memory layout, we named the backend `dace:cpu_KJI`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
We decided to add a backend that allows directly streaming memory from Fortran into GT4Py stencils (and back) without any copies. To communicate the expected device and memory layout, we named the backend `dace:cpu_KJI`.
We decided to add a backend that allows directly streaming memory from Fortran into GT4Py stencils (and back) without any copies. To communicate the expected device and memory layout, we named the backend `dace:cpu_KJI`. We chose to keep `cpu` as part of the name because we do not see the potential use-case of using such a poorly-fitting layout to do computation on GPU ever.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants