feat/fix[cartesian]: Do not merge: working PR for NASA crew#2595
Open
romanc wants to merge 32 commits into
Open
feat/fix[cartesian]: Do not merge: working PR for NASA crew#2595romanc wants to merge 32 commits into
romanc wants to merge 32 commits into
Conversation
`log10(x)` will always be in double precision, regardless of `GT4PY_LITERAL_FLOAT_PRECISION`. With this PR, we are deferring to `dace.math.log10`, which is a templated version that respects the floating point precision.
romanc
force-pushed
the
romanc/fix-log10-precision
branch
from
May 11, 2026 08:03
00a7a94 to
901b57e
Compare
romanc
marked this pull request as ready for review
May 11, 2026 08:04
romanc
marked this pull request as draft
May 11, 2026 10:41
Contributor
Author
|
wait - there's more. In particular, I stumbled across |
romanc
force-pushed
the
romanc/fix-log10-precision
branch
from
May 11, 2026 13:17
170a1a7 to
91de511
Compare
romanc
force-pushed
the
romanc/fix-log10-precision
branch
from
May 11, 2026 13:30
91de511 to
1abd6c7
Compare
romanc
changed the title
romanc
marked this pull request as ready for review
May 11, 2026 17:56
7 tasks
This comment was marked as outdated.
This comment was marked as outdated.
this allows us (the cartesian team) to continue using our test branch of dace while we keep pushing for the presentation in june.
Contributor
Author
|
Note: I've restored the cartesian/next separation of DaCe versions. This allows us to keep our current working branch of DaCe in this working branch of GT4Py. |
romanc
changed the title
1 task
twicki
pushed a commit
that referenced
this pull request
Jun 10, 2026
## Description Small cleanup to remove an unused function argument in `get_dace_shape()` of `oir_to_treeir.py`. Pulled out from #2595. ## Requirements - [x] All fixes and/or new features come with corresponding tests. Covered by existing tests.
3 tasks
The conditionals for regions were generated in the form of
`{axis_bound} + {offset}`. This would lead to conditionals like
```cpp
if (((__i >= (0 + -1)) && (__i < (0 + 0)))) { ... }
```
in generated code. While we could expect compilers to handle this, it's
also ugly to work with in the intermediate representations.
This PR suggests - as a first, easy step - to detect `0` and not write
them.
This was referenced Jul 2, 2026
romanc
added a commit
that referenced
this pull request
Jul 8, 2026
## Description The pipeline of representations (truncated) for the cartesian dace backend is as follows: ```none ... > oir -> treeir (gt4py) -> schedule tree (dace) -> SDFG (dace) ``` In this PR, we change the names of map/loop in the schedule tree representation. The map/loop names in that representation are just names (that can more or less be anything). We had a rather general description and replace it with a more descriptive one, which includes the name of the stencil where the horizontal/vertical loop (sections) come from. This allows easier debugging and profiling. Nothing (except names) changes in the generated code. Thus no tests have been added. This PR contains an unrelated commit removing unused imports from dace backend tests. This PR is part of cleaning up our "working branch", i.e. #2595, which accumulated a couple of changes over the last month. ## 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/](docs/development/ADRs/README.md) folder. N/A
romanc
added a commit
that referenced
this pull request
Jul 8, 2026
…#2682) ## Description In oir -> treeir, avoid inserting artificial `x + 0` or `0 + x` calculations when translating axis bounds. In the end, this makes for cleaner generated code, which is easier to read and doesn't rely on general compilers to remove the calculation as part of their optimization pipeline. This PR is part of cleaning up our "working branch", i.e. #2595, which accumulated a couple of changes over the last month. ## Requirements - [x] All fixes and/or new features come with corresponding tests. - [ ] Important design decisions have been documented in the appropriate ADR inside the [docs/development/ADRs/](docs/development/ADRs/README.md) folder. N/A
romanc
added a commit
that referenced
this pull request
Jul 8, 2026
## Description This fix comes from running GFDL_1M in KJI-layout where - in NDSL - there's no extra point allocated in the vertical (to be able to directly copy the Fortran data). This commit freezes origin and `domain` (not `shape`) in the K-axis of the stencil. `shape` and `domain` agree most of the time, but can differ if - for example - the stencil is configured on `K_INTERFACE_DIM` and the field of size `K_DIM`. Depending on the combination, this can lead to out of bound reads where we were previously saved by the extra point allocated in the back (but in KJI since we don't have this point, we crash). I am not touching the horizontal axes in this commit. We probably should, but we haven't seen any crashes (probably due to the fact that we can't currently run dynamics in KJI (i.e. without the extra point)). I'd argue we should tackle this in a follow-up when we also look at the "potential out of bounds" memlet warnings that we get from dace (mainly when running dynamics). This PR is part of cleaning up our "working branch", i.e. #2595, which accumulated a couple of changes over the last month. ## 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/](docs/development/ADRs/README.md) folder. N/A
This update the cartesian version of dace to the latest version and fixes the next version of dace to be the correct one (i.e. latest release instead of pulling from their index).
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Update This branch is clean except for the original math functions. DaCe math functions require spcl/dace#2418 to be merged first and then DaCe to be released such that it can be updated in GT4Py (to the newest alpha).
🧱 In short, this is blocked by spcl/dace#2418 and a subsequent DaCe release.
🐉⚠️
Temporary working branch of
gt4py.cartesianfor the NASA crew. To be properly integrated in July.Several math functions, e.g.
log10(x), do not respectGT4Py_LITERAL_FLOAT_PRECISIONin the dace backend.The issue is caused by a combination of dace's code generation and the C/C++ standard library history. In C,
log10(x)is defined to operate in double precision. The single-precision equivalent is calledlog10f(x), see here.In C++, there is
std::log10(x), which is a templated version that computes in either single- or double-precision depending on the argument. DaCe exposes access to those templated versions throughdace/math.h. Some function were missing and are being patched with spcl/dace#2364. Building on that PR in DaCe, this PR uses the newly exposed fuctions in the cartesian DaCe backends.Requirements
N/A