Fix CI (0d field slice)

[edopao]

The latest commit on gt4py introduces a syntax feature: if you slice a field with full indexing, the result is still a field, a 0d field specifically. In order to use it as a scalar, the DSL program has to call .as_scalar(). Before this gt4py commit, the result of slicing would have been a scalar.

This PR adopts the new gt4py syntax feature. In order to do this, we bump the version of gt4py Spack package in stable CI job to 1.0.3.1.

[muellch]

I would just need some context, what is the error if this fix is not included?

[edopao]

The latest commit on gt4py introduces a syntax feature. The feature is that if you slice a field with full indexing, the result is still a field, a 0d field specifically. In order to use it as a scalar, the DSL program has to call .as_scalar(). Before this gt4py commit, the result would have been a scalar.

The question here is what do we mean by stable gt4py version, in the Spack CI job, and if we should provide backwards-compatibility checks like the one proposed in this PR. An alternative to the change proposed in this PR is to use the new syntax (which requires calling .as_scalar()) and bump the revision of stable gt4py.

[halungge]

The latest commit on gt4py introduces a syntax feature. The feature is that if you slice a field with full indexing, the result is still a field, a 0d field specifically. In order to use it as a scalar, the DSL program has to call .as_scalar(). Before this gt4py commit, the result would have been a scalar.

The question here is what do we mean by stable gt4py version, in the Spack CI job, and if we should provide backwards-compatibility checks like the one proposed in this PR. An alternative to the change proposed in this PR is to use the new syntax (which requires calling .as_scalar()) and bump the revision of stable gt4py.

I would opt for the latter, as long as nobody relies on stable.

[edopao]

The latest commit on gt4py introduces a syntax feature. The feature is that if you slice a field with full indexing, the result is still a field, a 0d field specifically. In order to use it as a scalar, the DSL program has to call .as_scalar(). Before this gt4py commit, the result would have been a scalar.
The question here is what do we mean by stable gt4py version, in the Spack CI job, and if we should provide backwards-compatibility checks like the one proposed in this PR. An alternative to the change proposed in this PR is to use the new syntax (which requires calling .as_scalar()) and bump the revision of stable gt4py.

I would opt for the latter, as long as nobody relies on stable.

That's OK. In this case, @havogt should we make a gt4py v1.0.4 release or should I make a custom icon4py tag?

[github-actions]

Mandatory Tests

Please make sure you run these tests via comment before you merge!

• cscs-ci run default
• launch jenkins spack

Optional Tests

To run benchmarks you can use:

• cscs-ci run benchmark

In case your change might affect downstream icon-exclaim, please consider running

• launch jenkins icon

For more detailed information please look at CI in the EXCLAIM universe.

[muellch]

Considering the circumstances, looks good to me.

I do not agree with a field of size 1 not decaying into a scalar, but that is another matter.

[edopao]

cscs-ci run default

[edopao]

launch jenkins spack