fix[cartesian]: Fix higher dimensional field access in runtime-intervals#2553
Open
twicki wants to merge 7 commits intoGridTools:mainfrom
Open
fix[cartesian]: Fix higher dimensional field access in runtime-intervals#2553twicki wants to merge 7 commits intoGridTools:mainfrom
twicki wants to merge 7 commits intoGridTools:mainfrom
Conversation
romanc
reviewed
Mar 26, 2026
Contributor
romanc
left a comment
romanc
left a comment
There was a problem hiding this comment.
Looks good in general. I just have a couple of questions inline for my understanding.
tests/cartesian_tests/unit_tests/frontend_tests/test_gtscript_frontend.py
Show resolved
Hide resolved
tests/cartesian_tests/unit_tests/frontend_tests/test_gtscript_frontend.py
Show resolved
Hide resolved
| else: | ||
| higher_dim_offset = [self.visit(node.slice)] | ||
| literal_index = [ | ||
| nodes.ScalarLiteral(value=i, data_type=nodes.DataType.INT32) |
Contributor
There was a problem hiding this comment.
Should we make this dependent on the literal precision?
twicki
added a commit
that referenced
this pull request
Mar 27, 2026
## Series on interval-parsing (3/3) This PR is one in a series to simplify interval parsing in the front-end. This entire series was triggered, because runtime-intervals and higher dimensional fields do not interact as intended right now. So here the summary of the slate of work Current State: - The parser between horizontal and vertical intervals is shared - This leads to a lot of differentiation having to happen in the calls since what is and is not allowed is very different - There is a plethora of different syntaxes allowed for vertical intervals - With runtime-intervals now being part of the equation, differentiation became even harder. - Accessing higher-dimensional fields with `[]`-operators did trigger exceptions To tackle these problems, the following PR's are up: [2510](#2510): split the parser for the horizontal and the vertical and specialize them as appropriate [2553](#2553): fix how runtime-intervals interact with higher dimensional fields current: remove all redundant syntax to go back to a more specific language ## Description The legal syntax for regions was very bloated and allowed for multiple ways to express a single output. This PR trims this down to a more minimalistic approach. Previously allowed: - `I[0:2]` - `I[0] : I[2]` - `I[0] : I[0] + 2` - `0:2` There is no clean way to completely avoiding the axis-access syntax, as it is required to generate somewhat clean out-of-domain computations to skip by going `I[0]- LARGENUMBER`. this is why axis-access is still allowed additionally to plain offset syntax. but only to access the start and end of the domain. So this PR minimizes the syntax down to - `I[0] : I[0] + 2` - `0:2`
romanc
requested changes
Mar 30, 2026
Contributor
romanc
left a comment
romanc
left a comment
There was a problem hiding this comment.
I think we should enforce passing the literal_int_precision to the VerticalIntervalParser. Otherwise looks good to me.
| axis_name: str, | ||
| fields: dict[str, nodes.FieldDecl], | ||
| loc: Optional[nodes.Location] = None, | ||
| literal_precision: Optional[int] = None, |
Contributor
There was a problem hiding this comment.
I think the literal precision shouldn't be optional and I would put it as a member of VerticalIntervalParser instead of IntervalParser because the member is unused in the HorizontalIntervalParser. Adding it as a required argument also allows you to avoid having literal precision default value in the interval parser.
tests/cartesian_tests/unit_tests/frontend_tests/test_gtscript_frontend.py
Show resolved
Hide resolved
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.
Series on interval-parsing (2/3)
This PR is one in a series to simplify interval parsing in the front-end.
This entire series was triggered, because runtime-intervals and higher dimensional fields do not interact as intended right now. So here the summary of the slate of work
Current State:
[]-operators did trigger exceptionsTo tackle these problems, the following PR's are up:
2510: split the parser for the horizontal and the vertical and specialize them as appropriate
current: fix how runtime-intervals interact with higher dimensional fields
next: remove all redundant syntax to go back to a more minimalistic language
Description
Fix the behavior of runtime-intervals when accessing higher dimensional fields with an offset in the higher dimension.
This additional offset was not caught properly and was always set to 0. PR 2510 disabled all higher dimensional field accesses to prevent illegal code.
This PR re-introduces this feature and fixes how the access in handled to now be correct.