Dear Nektar++ team,

I hope this email finds you well. I am trying to couple Nektar++ (AcousticSolver) with a Python code using CWIPI 1.3.0. I’m running into a handshake failure that looks like an API mismatch between the two sides.

Although I confirmed with：

ldd $(which AcousticSolver) | grep -i cwp

libcwp.so.1.3.0 => /.../lib/libcwp.so.1.3.0

Logs (abridged to the relevant parts)

Python side clearly initializes the new API:

[PyApp] Rank 0: Calling pycwp.init()...

[CWP_Init][rank=0] called with n_code=1, is_active_rank=1

[CWP_Init][rank=0] code_names[0] = 'PyApp_'

Nektar++ side appears to initialize the legacy API:

[APDB][init] ENTER: comm_rank=1 comm_size=2 applicationName=nektar

...

mergeNames raw buffer (len=8): PyApp_\0\0

...

python: .../cwipi/src/new/codePropertiesDB.cxx:270: ... Assertion `index <= totalLength' failed.

My understanding is:

that Nektar++ links to CWIPI 1.3.0, the logs show that Nektar++ still calls the legacy API (cwipi_init, ApplicationPropertiesDataBase), while the Python side uses the new API (CWP_Init, CodePropertiesDB). This causes inconsistent name exchange (PyApp_[python side application name] vs empty string) and an assertion failure in codePropertiesDB.cxx.

>From CommCwipi.cpp I see:

cwipi_init(MPI_COMM_WORLD, localName.c_str(), &localComm);

so it seems Nektar++ is not yet adapted to the new API.

My questions:

1. Is it correct that Nektar++ currently does not support the new API?

2. If yes, is there a way to configure or build Nektar++ so that it uses the new API, or would migrating CommCwipi.cpp be necessary? Roughly how much effort would such a migration take?

3. Is there any other way to solve this problem?

Since CWIPI no longer provides downloads of the old version code, I wanted to check with you on the recommended way forward.

Thank you very much for your guidance.

Best regards,

Dao