Skip to content

Use precompiled binaries - #145

Open
uandrae wants to merge 9 commits into
ACCORD-NWP:developfrom
uandrae:feature/ready_made_binaries
Open

Use precompiled binaries#145
uandrae wants to merge 9 commits into
ACCORD-NWP:developfrom
uandrae:feature/ready_made_binaries

Conversation

@uandrae

@uandrae uandrae commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

Describe your changes

Implements the usage of precompiled binaires for CY50t2.

< Please also include relevant motivation and context. >

< List any dependencies that are required for this change. >

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

Checklist before requesting a review

Testing

  • I have tested this on ATOS using the atos_bologna.toml configuration in the latest version of Tactus-test-runner
  • I have tested this on LUMI using the lumi.toml configuration in the latest version of Tactus-test-runner

For further information see the development guide

Code quality

  • My change follows the best practices for this project.
  • My local environment is correctly initialised as described in the README file.
  • My branch is up-to-date with the target branch - if not update your fork with the changes from the target branch (use pull with --rebase option if possible).
  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have updated the documentation and docstrings to reflect the changes
  • I have added tests that prove my fix is effective or that my feature works
  • I have ensured that the code is still installable with poetry after the changes and runs
  • I have requested one or more reviewer(s) and an assignee (assignee is responsible for merging). At least one reviewer has accepted to review.

Checklist for reviewers

Each PR comes with its own improvements and flaws. The reviewer should check the following:

  • the code readable
  • the code well tested (checked coverage report)
  • the code documented
  • the code easy to maintain

Author checklist after completed review

  • I have added a line to the CHANGELOG describing this change (in section
    reflecting type of change, for example "bug fixes", add section where
    missing)

Checklist for assignees

  • PR is up to date with the base branch
  • the tests passing
  • author has added an entry to the changelog (and designated the change as added, changed or fixed)
  • the PR has been approved by all the reviewers, that accepted to review.
  • Once the PR ready to be merged, squash commits and merge the PR.

Tag possible reviewers

You can @-tag people to review this PR in addition to formal review requests.

@uandrae

uandrae commented Jul 16, 2026

Copy link
Copy Markdown
Contributor Author

Picking up on the path discussion in #132, what's your suggestion @pardallio?

@pardallio

Copy link
Copy Markdown
Contributor

For cy50, compilation is done for a specific architecture that can be uniquely identified by a set of arch directories present in the bundle folder of IAL. these have a format like ecmwf/hpc2020/intel/2021.4.0/hpcx-openmpi/2.9.0. the ecmwf/hpc2020 part may be redundant as its the host machine.

so a given installation could be uniquely identified on atos by intel/2021.4.0/hpcx-openmpi/2.9.0/[SP|R32] and could be placed in /ec/project/accord/IAL/@CYCLE@/intel/2021.4.0/hpcx-openmpi/2.9.0/[SP|R32].

For each arch there is also an associated env.sh file which sets the environment used in the installtion (in particular the modules loaded). I think it would be beneficial to have tactus use the same environment for running its tasks, but I am not sure how to do it since tactus has a specific way to load modules and the env.sh file is not exported to the install dir by default

@uandrae

uandrae commented Jul 16, 2026

Copy link
Copy Markdown
Contributor Author

OK, and how do we decide to pick up e.g. IAL/bundle/extra-arch/ecmwf/hpc2020/intel/2023.2.0/hpcx-openmpi/2.9.0/env.sh?

@pardallio

Copy link
Copy Markdown
Contributor

OK, and how do we decide to pick up e.g. IAL/bundle/extra-arch/ecmwf/hpc2020/intel/2023.2.0/hpcx-openmpi/2.9.0/env.sh?

when creating the bundle it is possible to specify the directory where the architectures can be fetched from

something like ecbundle create --bundle /path/to/bundle.yml --arch-dir /path/to/extra-arch
then when building, it is possible to specify the architecture with ecmwf/hpc2020/intel/2023.2.0/hpcx-openmpi/2.9.0/ and it will compile with that env.sh.

Ideally, this env.sh would end up in the install folder, and tactus could run source /path/to/install/env.sh , but at the moment env.sh is not installed

@uandrae

uandrae commented Jul 17, 2026

Copy link
Copy Markdown
Contributor Author

Thanks, but the end result is not known at configuration time and this is a bit challenging to handle. I'll try to do something that makes it easy to swap between pre and inline compiled binaries and we'll see how far we get. Another thing to consider if we should allow the test-runner to run on precompiled binaries as well, as an option or default. Any opinions @dhaumont? Should be possible to achieve with some tweaking in test_runner.py.

@uandrae

uandrae commented Jul 17, 2026

Copy link
Copy Markdown
Contributor Author

OK, and how do we decide to pick up e.g. IAL/bundle/extra-arch/ecmwf/hpc2020/intel/2023.2.0/hpcx-openmpi/2.9.0/env.sh?

when creating the bundle it is possible to specify the directory where the architectures can be fetched from

something like ecbundle create --bundle /path/to/bundle.yml --arch-dir /path/to/extra-arch then when building, it is possible to specify the architecture with ecmwf/hpc2020/intel/2023.2.0/hpcx-openmpi/2.9.0/ and it will compile with that env.sh.

Ideally, this env.sh would end up in the install folder, and tactus could run source /path/to/install/env.sh , but at the moment env.sh is not installed

How (where) do we configure the compilation to pick gnu instead of intel for e.g. the hpc2020 case?

$ tree ~/git/IAL/bundle/arch/ecmwf/hpc2020 -L 1
/home/a000864/git/IAL/bundle/arch/ecmwf/hpc2020
├── default -> intel/2021.4.0/hpcx-openmpi/2.9.0
├── gnu
└── intel

@pardallio

Copy link
Copy Markdown
Contributor

From tactus you can specify the arch directory in the config file in the [compile] section using the arch field.

Setting the arch-dir when doing ecbundle create is not yet supported from tactus since there is no ecbundle release with this feature yet. It is still only on the main branch.

when compiling manually you doing by passing --arch ecmwf/hpc2020/gnu to the ecbundle build command

@uandrae uandrae added this to the v1.3.0 milestone Jul 21, 2026
@uandrae

uandrae commented Jul 22, 2026

Copy link
Copy Markdown
Contributor Author

With the changes in compilation.py I'm trying to extract a useful path but the compilation fails. What I'm I doing wrong @pardallio, @dhaumont?

The run is under /scratch/snh/tactus/IAL_develop_compile2 with logs under /home/snh/tactus_ecflow/jobout/IAL_develop_compile2/

@pardallio

Copy link
Copy Markdown
Contributor

This is an old issue with fckit that we've never been able to solve. When doing two installations at the same time, one of the fckit venvs fails to install sometimes. We see this issue a lot in the github actions.

@pardallio

pardallio commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

I believe it's because it tries to build on the source folder of the bunlde (which is the same for SP and DP).

if you inspect /scratch/snh/tactus/IAL_develop_compile2/bundle/source/fckit/src/fckit/fckit_yaml_reader/ you'll find a build folder.

@dhaumont, i'll create an issue on fckit github ecmwf/fckit#101

@pardallio

Copy link
Copy Markdown
Contributor

I have created a PR to fix it (ecmwf/fckit#102) but it will likely take a long time to go in to fckit.

if self.precision == "R32":
self.prec_arg = "--without-double-precision"

def get_install_subpath(self):

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Could you add a unit test for get_install_subpath ?

@dhaumont

dhaumont commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

I have created a PR to fix it (ecmwf/fckit#102) but it will likely take a long time to go in to fckit.

Thank you for fixing this, it's bugging us since the beginning of CMake use.
I hope it will be merged fast into fckit. the changes are quite small to review and integrate and I'm pretty sure our colleagues at ECMWF will be happy to have a bug fix already implemented

@dhaumont dhaumont left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Added a few comments and questions. Please also don't forget to update the changelog

arch = default_link.resolve()
else:
arch = arch_dir
top = arch_dir.parts[-1]

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This code is complicated to understand.
Can you comment it ?

builddir = f"{compile_dir}/build/{self.precision}"
local_bindir = f"@CASEDIR@/install/{self.precision}"
install_subpath = self.get_install_subpath()
bindir = f"{compile_dir}/install/{self.precision}/{install_subpath}"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

How are the binary compiled and deployed ?

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.

3 participants