Add single precision option to the dycore (intermediate state)

[starkphi]

Adds the option to set wp/vpfloat to single via the env var ICON4PY_FLOAT_PRECISION (previous options were 'double' and 'mixed') to run in single precision.

This PR was created to later reduce merge complexity of #886.

Changes

• Replace native python float types by either wpfloat or vpfloat
  • Change type annotations where there were native Python floats were present (which are by default passed as gtx.float64 to gtx.field_operators and gtx.programs) and add casts around float literals
  • Swap wpfloat <-> vpfloat where an inconsistency with an operator was caught (to hopefully make fixing mixed precision easier in the future)
  • Replace DBL_EPS by WP_EPS and VP_EPS
• Setup pytests for single precision
  • Add pytest marker single_precision_ready (running a test with ICON4PY_FLOAT_PRECISION=single deselects all tests without) and mark integration tests for the standalone driver and most components (required much larger tolerances for some cases)
  • Remove pytest option --enable-mixed-precision (wpfloat or vpfloat are already set according to ICON4PY_FLOAT_PRECISION at import time of a pytest file)
  • Added PRECISION_VARIANTS as dimension to the ci pipeline matrix
• Keep calculations and results in gtx.float64 internally in geometry, metrics or interpolation factories independently of the selected precision. Mainly to keep the precision of the RBF and other geometry factors acceptable when running in ICON4PY_FLOAT_PRECISION
  • factory.store_allfloats_as_double forces float allocations in a FieldSource to double-precision
  • FieldSource.export_field casts to the dtype declared in the field metadata where the fields leave the factories

[muellch]

cscs-ci run default

[egparedes]

It looks good in general although I have a few comments.

[egparedes]

Question: is this marker needed only in a transition phase? Otherwise, why is actually needed?

[starkphi]

Yes, that would be the idea.
I thought that it might be good to be able to have all tests skipped that have not been prepared for single precision yet. So I suggest using this marker until all tests have suitable tolerances defined for single precision operation.

[starkphi]

cscs-ci run default

[msimberg]

Tentative approval with knowledge that there are a few things to clean up still. The overall changes look good to me now!

[msimberg]

Is this something you wanted to handle still in this PR (it sounds like a follow-up)?

[starkphi]

It's indeed a follow up. Just wanted to mark this. It's the only place where a factory appears inside a state.

[github-actions]

When developing, you can test your changes on CSCS CI before merge with the default pipeline: cscs-ci run default. This will run a default subset of tests.

You can pass options to override pipeline variables, for example:

• cscs-ci run default;BACKENDS=gtfn_cpu;LEVELS=unit
• cscs-ci run default;MODEL_SUBPACKAGES=common:driver;SESSIONS=model

Avoid running the pipeline for all tests when you are developing.

Available options are:

• SESSIONS: model, model_mpi, or tools (correspond to nox sessions)
• MODEL_SUBSETS: datatest, basic, or stencils (correspond to nox session selections)
• MODEL_SUBPACKAGES: subpackages for non-MPI tests (last component, e.g. diffusion, driver)
• MODEL_MPI_SUBPACKAGES: subpackages for MPI tests (as above)
• BACKENDS: backends
• GRIDS: grids for stencil tests (simple, icon_regional, or icon_global)
• LEVELS: testing level for non-stencil tests (unit or integration)

For each option, all can be used as a shorthand for all possible values of that variable, e.g. LEVELS=all.

Multiple values can be given to each option with : used as the separator (; separates options and , separates pipelines).

See scripts/python/generate_ci_pipeline.py and noxfile.py for available values for each option.

The all pipeline can be run with cscs-ci run all. This will run all icon4py tests in CSCS CI which can be expensive. This pipeline runs on a schedule on main, and can be run when extensive validation is needed (e.g. before releases).

Merging

Once your PR is approved and ready for merging, add it to the merge queue. The merge CSCS CI pipeline will run automatically on the merge-queue branch and must pass before the PR is merged. A dummy merge check will be triggered on the PR itself since it's required to add a PR to the merge queue.

Optional Tests

To run benchmarks you can use:

• cscs-ci run benchmark-bencher

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