 |
YAC 3.18.0
Yet Another Coupler
|
|
YAC 3.18.0
Yet Another Coupler
|
This page documents known issues, their solutions and frequently asked questions
Problem:
If you are trying to build YAC with the Python bindings (--enable-python-bindings) you may come across one of the following errors:
or
Explanation:
YAC's Python bindings depend on a few Python packages. You can find a complete list of required Python packages that need to be installed on your system in the YAC documentation on the Python bindings.
During configuration YAC checks these dependencies and will raise an error like the ones shown above if a dependency is missing.
Solution:
Install the missing packages. There are several ways to install Python packages, depending on your system.
On Ubuntu, you can install packages system-wide with apt (e.g., apt install python3-setuptools).
On HPC systems, system-wide installation is usually not possible because of limited access rights. DKRZ provides a detailed guide on using Python on Levante here, including an overview of package installation methods.
A portable approach that works on most systems is to use virtual environments. For details, refer to the documentation of Python's venv package.
Problem:
One of the most common ICON-coupling-related issues occurs when users encounter a failure during ICON initialization with an error message that looks as follows:
Explanation:
The cause is that depending on the runscript, the ICON atmosphere component has different names (e.g. atm, atmo, or atmos). If this does not match the component name specified in the coupling configuration file, the error above will be generated.
An alternative cause is that a field mentioned in a couple definition was not defined (via yac_def_field or equivalent) in one of the related components. Ensure that all fields referenced in the coupling configuration are properly defined in both the source and target components before the search phase.
Solution:
Make naming in components and configuration file consistent.
Add missing field definitions in components.
If the missing field definition is expected (e.g. setup is still in development process and not yet complete), this error can be made non-fatal by setting missing_definition_is_fatal to false in the YAML configuration file.
Hint:
To help identify the cause, you can configure YAC to write out its internal coupling configuration to a file using the global_config debug option. Inspecting the generated file (optionally including debug definitions) allows you to verify which components, grids, and fields were actually defined and compare them against the coupling configuration.
Problem:
The following error can appear if the installation of the Python bindings is broken or you tried to install the Python bindings in an unexpected way:
You will probably see this error when running YAC in a more complex setup. Generally, it should also be possible to trigger this error by trying to import YAC via
Solution: (YAC <= 3.17.0)
Please upgrade to an newer version than 3.17.0.
Workaround: (YAC <= 3.17.0)
If you cannot upgrade to a newer YAC version containing the bugfix the error message should disappear by exporting the PYTHONPATH. If you cloned YAC into the folder $HOME/yac run
Consider, adding this line to your runscript or .bashrc file.
Refer to Alternative Installation (–enable-python-bindings) for detailed information.
Problem:
During initialization, YAC computes interpolation weights across all processes by redistributing grids between them. This redistribution depends on the distribution of the original data and the number of processes. Changing either parameter can alter which process computes which weights.
In an MPMD setup, the following factors can cause math functions (e.g. atan) to produce slightly different results across different executables/programs:
These differences can lead to non-reproducible interpolation results.
Workaround:
When using the Intel compiler, adding -fp-model source to the CFLAGS passed to YAC can help avoid this issue.
Problem:
With YAC Version 3.10.0 (Oct 2025) a test case in OASIS3-MCT coupling bggd->nogt fails with the following error message:
Solution:
Upgrade to Version 3.13.1 (Jan 2026) or newer.
Problem:
When compiling toy models using pkg-config --libs yac and pkg-config --cflags yac, the executables link against NetCDF (which YAC uses). However, pkg-config does not provide rpath to the libraries, requiring users to explicitly set LD_LIBRARY_PATH to run the executables.
Example compilation:
Error meesage:
Proposed Workarounds:
1. Temporary solution:
Extend your compilation command with:
2. Best practice recommendation:
If your application depends on NetCDF directly, do not rely on YAC's pkg-config file to provide NetCDF flags. Reasons:
Using pkg-config --libs yac already provides -L and -l flags for NetCDF, which can conflict if the user also provides NetCDF library flags for a different installation. This can cause different symptoms depending on static vs. dynamic linking.
Long-term Solution Discussion:
Challenges and a potential implementation for adding RPATH support to yac.pc:
Challenges:
/usr/lib64) to prevent strange runtime symptoms-Wl,-Wl,,-rpath,,/path while GCC needs -Wl,-rpath,/path)Proposed implementation:
yac.pc: crpaths and fcrpathspkg-config --variable=crpaths yac for C compiler, pkg-config --variable=fcrpaths yac for Fortran compilerpkg-config --libs yac outputRecommended current usage:
pkg-config --cflags yac guaranteed to work for C compilerpkg-config --libs-only-L --libs-only-l yac if you don't want RPATH flags at allpkg-config --variable=fcflags yac for compilation and pkg-config --libs-only-L --libs-only-l yac combined with pkg-config --variable=fcrpaths yac for linking (once implemented)The error occurs during the ./configure step when testing the Fortran intrinsic is_contiguous(). Many Fortran compilers have faulty implementations of this intrinsic, which YAC uses to verify that arrays provided by the user to the Fortran interface can be passed to C. This is critical for YAC because it needs to pass data from Fortran to C (YAC is written in C).
Configure error message:
Known affected compilers:
General Workarounds:
If your Fortran compiler is faulty but you are certain your arrays are always contiguous in memory, you can skip the configure check:
is_contiguous check, be very careful when changing anything related to coupling. Since is_contiguous is effectively disabled, the compiler cannot verify memory layout correctness when passing data between Fortran and C.Alternatively, since Version 3.6.1 (Mar 2025), you can disable the Fortran interface entirely:
This is particularly suitable for projects like PISM that only use YAC's C interface.
NVIDIA-specific workaround for ICON builds:
For ICON builds with NVIDIA 23.3, the following flags can be used:
This approach:
is_contiguous to always return .TRUE.FC=no to its configureProblem:
Intel C Compiler Classic 2021.5.0 fails to compile area.c with -O2 -march=native on Levante (and potentially other systems). The compiler crashes with an internal error:
Affected Configuration:
-O2 -march=nativeSolution:
This is a compiler bug. Options:
-march=native flagProblem:
When Version 2.6.1 (Sep 2022) (patch 3) is built with NVHPC 23.5 (against YAXT 0.9.3.1), the test test_interp_method_nnn_parallel fails with multiple "wrong interpolation result" messages. The same YAC version works correctly with NVHPC 22.5.
Affected Configuration:
test_interp_method_nnn_parallelStatus:
A fix was implemented and is included in YAC Version 2.6.2 (Dec 2022) and newer. This issue was particularly important for ICON integration, as upgrading to NVHPC 23.5 was desired for new compiler features and bugfixes.
Problem:
When using Intel OneAPI compilers, test_instance_parallel1 fails with the following error message:
Affected Configuration:
test_instance_parallel1Solution:
The issue is caused by floating point optimisations performed by the compiler. Adding -fp-model=precise to the compiler flags passed to YAC avoids it.
1.11.0