Dear Dao, I am not aware that any of our current active developers are particularly familiar with CWIPI. Certainly changing the version of CWIPI library to 1.3.0 will not change the API calls made by the code, so your observation makes sense. Does the CWIPI documentation claim to allow the exchange of data between applications using different forms of the API? If it does, it is possible we will need to identify if we (or the Python side) is not using its respective API correctly. If it does not, it is possible that both API versions could potentially be supported in Nektar++ (maybe through a compile-time switch), but this would depend on how different the APIs are. I am about to go on leave, but if you are still having issues when I return in early September I can try and have a look at what might be involved in supporting both API forms. Kind regards, Chris On 19/08/2025 20:34, dxz324@student.bham.ac.uk wrote:

This email from dxz324@student.bham.ac.uk originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list <https://spam.ic.ac.uk/SpamConsole/Senders.aspx> to disable email stamping for this address.

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

_______________________________________________ Nektar-users mailing list Nektar-users@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/nektar-users

-- Chris Cantwell Reader in Computational Engineering Director of Postgraduate Studies (PhD) Department of Aeronautics Imperial College London South Kensington Campus London SW7 2AZ Tel: +44 (0)20 759 45050 Email:c.cantwell@imperial.ac.uk www.imperial.ac.uk/people/c.cantwell