Error compiling Cython file with noexcept on Archer2 cluster

[tristan0299]

Hello CWIPI developers,

I’m trying to build CWIPI from source on the Archer2 cluster by following the standard steps:

_**git clone https://github.com/onera/cwipi.git

[submodule "external/paradigm"]
path = external/paradigm
url = https://github.com/onera/paradigm.git

git submodule sync external/paradigm
git submodule update --init external/paradigm
mkdir build
cd build
cmake ..
-DCMAKE_INSTALL_PREFIX=/path/
-DCWP_ENABLE_PYTHON_BINDINGS=ON
-DCWP_ENABLE_SHARED=ON

make
make install**_

During the make phase, the build fails while compiling the Cython-generated C source, with the following error:
Error compiling Cython file:
...
const int distant_points_barycentric_coordinates_index[],
const double distant_points_barycentric_coordinates[],
int stride,
cwipi_solver_type_t solver_type,
const void *local_field,
void *distant_field) noexcept:
^
/path/to/cwipi/build/Cython/cwipi/cwipi.pyx:1325:40: Syntax error in C variable declaration

Questions:

Are there specific compiler requirements (e.g., a minimum C++ standard or a particular compiler) needed to build the Python bindings?

Should the Cython output be compiled as C++ rather than C?

Is there a recommended Cython version or cythonize command-line flag to avoid inserting noexcept?

Any advice on how to resolve this build error on an HPC environment like Archer2 would be greatly appreciated. Thank you!

[bandrieu]

Hi @tristan0299,

Which version of CMake, Cython and which C++ compiler did you use?

Best regards,

Bastien

[tristan0299]

Hi @bandrieu ,

Thank you for your support.
Here are the versions I am currently using on ARCHER2:

CMake: 3.23.1

Cython: 0.29.36

C++ compiler: Cray CCE (via CC, version 15.x)

During the build process I encountered compilation errors related to noexcept. I managed to bypass them by removing 'noexcept' keywords in several files (e.g. pycwp.pyx.in). Could you confirm if this is an acceptable workaround, or if it may cause further issues?

At the moment, I am coupling the CWIPI Python interface with a Nektar++ solver. However, I noticed a mismatch:

The provided Python examples (e.g. using pycwp) call the new API.

The CWIPI interface inside Nektar++ still relies on the old API.

As a result, the two cannot be linked together.

I would like to ask:

1. Could you provide python examples or documentation for using the old API from Python, since all examples I found are written for the new API?

2. Alternatively, we plan to update the Nektar++ interface to the new API. Could you provide a one-to-one mapping list from old API functions to the new API, and also let us know what additional changes (beyond simple renaming) are required to ensure compatibility with the new API?

Thank you very much for your guidance.

Best regards,
Tristan

[bandrieu]

Hi @tristan0299,

The noexcept modifiers were indeed introduced in Cython 3.0. As indicated here, they do not appear to be backward compatible with older versions of Cython. In the long term, I suggest you to upgrade to a more recent version of Cython, but your workaround should work in the short term.

1. The test tests/python_api.py is an example using the old Python interface. If that's not enough, I can create an example more suited to your needs.
2. We have created a documentation that covers this point. I will try to upload it on GitHub shortly, and let you know when it's done! In the mean time, you can try to compile the documentation on your own by following the instructions in the README.

Best regards,
Bastien

[bandrieu]

Hi @tristan0299,

With the help of a colleague, we have uploaded the documentation on GitHub, you can find it here.
You can find the one-to-one mapping you are looking for on the "Old to New" page.

Let me know if you need more information.

Best regards,

Bastien

[tristan0299]

Hi @bandrieu ,

Thanks for the docs and the “Old to New” mapping—much appreciated.

Old Python interface — what I’m trying to do
I want a Python sender that provides a source term on a small mesh and a Nektar++ receiver with a larger mesh (one-way coupling). On the receiver side I’d like CWIPI to locate/interpolate only in the overlap, and set non-overlap to zero (same intent as
RegularGridInterpolator(..., bounds_error=False, fill_value=0.0)).

In tests/python_api.py it looks like both ranks effectively use the same (single) mesh, so I’m unsure how to do the small-mesh → large-mesh interpolation with the old interface. Could you clarify the intended usage?

Concretely, for the old Python API, could you please confirm/provide:

Different meshes per rank
Is it correct that I can just call define_mesh(...) with a small mesh on rank 0 (Python sender) and a large mesh on rank 1 (Nektar++ receiver), and CWIPI will handle point location/interpolation automatically (no custom callback needed)?

Non-overlap = 0
What’s the proper old-API sequence to make non-located receiver points zero?

Is there a “reorder with default” call (e.g., reorder(..., default_value=0.0)) in the old API?

Or should I prefill the receive buffer with zeros, call exchange(...), and then call the old API’s reorder/unpack to place only the located values back into the full receiver layout?

I'm not sure if my thoughts are correct. If you could provide a minimal, self-contained example using the old Python interface (small-mesh → large-mesh, one-way, with non-overlap set to zero), that would be greatly appreciated.

New interface
Thanks again for the one-to-one mapping. I’ve started adapting nektar++ to the new API; if I run into issues I’ll follow up.

Best regards,
Dao

[bandrieu]

Hi @tristan0299,

I have prepared for you a simple demo with the two attached Python scripts:
demo_old_api_sender.py
demo_old_api_receiver.py

This demo emulates a simple one-way coupling between a sender code (running in serial) and a receiver code (running in parallel), using the old Python API.

The meshes of both codes are offset so that some of the receiving degrees-of-freedom are not located, as show in the picture below (in gray the sender mesh ; in color the receiver mesh, each color representing an MPI rank) :

The field on the sending mesh looks like this:

And the received interpolated field looks like this:

On the receiver side, you will find the proper old-API sequence for dealing with unlocated dofs.

You can run the demo with mpirun -n 1 python3 demo_old_api_sender.py : -n 5 python3 demo_old_api_receiver.py, which will assign 1 rank to the sender code, and 5 ranks to the receiver code.

I hope it will be useful. If necessary, I can translate this demo to the new Python API.

Best regards,
Bastien

[tristan0299]

Hi @bandrieu ,

Thank you very much for your help! I tried running the example you kindly provided, but I encountered the following error:
[node002:1011498:0:1011498] Caught signal 11 (Segmentation fault: address not mapped to object at address 0x4f0)
[node002:1011497:0:1011497] Caught signal 11 (Segmentation fault: address not mapped to object at address 0x4f0)
I used mpirun -np 1 python demo_old_api_sender.py :
-np 1 python demo_old_api_receiver.py
to start mpi.

I also attempted to run my own code following the same pattern as in your example. However, at the define_mesh stage I observed a similar issue:
[node088:1673003:0:1673003] Caught signal 11 (Segmentation fault: address not mapped to object at address 0x4f0)
==== backtrace (tid:1673003) ====
0 0x0000000000012b20 __funlockfile() :0
1 0x000000000002a759 __pyx_pw_5cwipi_5cwipi_8Coupling_5define_mesh() cwipi.c:0

Could you please advise on how I might resolve this issue?
I am also wondering whether there have been any changes in CWIPI 1.3.0 regarding the way the cwipi package is imported that could be related to this problem.

Thank you very much for your time and support.

Best regards,
Tristan

[bandrieu]

I @tristan0299,

I've tried running the demo with versions 1.3.0 and 1.2.0 and it works fine with my setup.

Do you encounter the same problem when running other examples from the tests directory? For instance, you could try running mpirun -np 2 python3 python_api.py.

Can you build CWIPI in Debug mode so that we can investigate your problem further using the backtrace?

Best regards,

Bastien

[tristan0299]

Hi @bandrieu ,

I have solved that problem! thank you very much!

I am experiencing an issue when coupling CWIPI with Nektar++. The coupling setup initializes correctly, the handshake succeeds, and the mesh definition is accepted. However, during the first call to exchange() the process hangs without error messages.

Context:

Sender: Python script using CWIPI bindings (test_sender.py)

test_sender.py

Receiver: Nektar++ configuration (nektar++_receiver.xml).

nektar++_receiver.xml

Variables exchanged: F_0_p, F_0_u, F_0_v.

The sender provides data on a finer mesh, while the Nektar++ receiver uses a coarser central region mesh.

To rule out interpolation issues, I also tested with an identical mesh on both sides (same sender/receiver grid). The problem persists: coupling and handshake succeed, but the process hangs at the first exchange.

I attach the output log (output.txt)

output.txt

showing the initialization steps and the point where the exchange call blocks.

Could you please advise where the problem may occur (e.g., mesh definition, exchange configuration, or CWIPI/Nektar++ coupling settings)?

Besides, Apart from the difference in domain size, I would also like to ask whether the difference in mesh resolution between the sender and the receiver can affect the coupling process. Will CWIPI automatically interpolate the data from the fine mesh on the sender side to the coarser mesh used by the receiver? My final goal is to use a finer mesh on a small region in the sender and couple it to a larger region with a coarser mesh on the receiver side for the subsequent computation.

Thank you for your support.

Best regards,
Dao