CWIPI Version Mismatch and Forcing Newer CWIPI in Nektar++
******************* This email 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 have two questions about using CWIPI coupling in Nektar++ 5.2.0 on ARCHER2: Can a mismatch between the CWIPI library versions (the coupling application using CWIPI 1.3.0 vs. Nektar++ loading its bundled CWIPI 0.11.1) cause the MPI data exchange to deadlock at initialization? If so, what’s the recommended way to override Nektar++’s default CWIPI 0.11.1 at build/install time so it links against an external CWIPI 1.3.0 (or later) instead? For context, I’ve observed that on startup Nektar++ prints many: cwipi 0.11.1 initializing lines, while the external coupling application prints: cwipi 1.3.0 initializing and neither ever progresses to the “Coupling Config:” stage. I tried pointing -DCMAKE_PREFIX_PATH at my CWIPI 1.3.0 install, but ldd AcousticSolver still shows libcwp.so.0.11.1. I also attempted manually replacing libcwp.so.0.11.1 with a symlink to libcwipi.so.1, without success. Could you please confirm: Whether version mismatch alone can block the CWIPI handshake? The exact CMake or install steps needed to force Nektar++ to use an external CWIPI 1.3.0 instead of its internal copy? Thank you for your guidance. Best wishes, Dao
Dear Dao, I am not sure I can confirm about the communication deadlock. Cwipi support was added by a collaborator and I am not sure it was ever tested with different versions of Cwipi. I note from the CMake configuration that it searches for cwipi in paths given by the LD_LIBRARY_PATH and CWIPI_HOME/lib environmental variables. You could try setting one of those and seeing if that helps it detect 1.3.0. Make sure you try this on a clean configuration (i.e. an empty build directory). Kind regards, Chris On 26/07/2025 21:18, 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 have two questions about using CWIPI coupling in Nektar++ 5.2.0 on ARCHER2:
Can a mismatch between the CWIPI library versions (the coupling application using CWIPI 1.3.0 vs. Nektar++ loading its bundled CWIPI 0.11.1) cause the MPI data exchange to deadlock at initialization?
If so, what’s the recommended way to override Nektar++’s default CWIPI 0.11.1 at build/install time so it links against an external CWIPI 1.3.0 (or later) instead?
For context, I’ve observed that on startup Nektar++ prints many: */_cwipi 0.11.1 initializing_/* lines, while the external coupling application prints: */_cwipi 1.3.0 initializing_/* and neither ever progresses to the “Coupling Config:” stage.
I tried pointing -DCMAKE_PREFIX_PATH at my CWIPI 1.3.0 install, but ldd AcousticSolver still shows libcwp.so.0.11.1. I also attempted manually replacing libcwp.so.0.11.1 with a symlink to libcwipi.so.1, without success.
Could you please confirm:
Whether version mismatch alone can block the CWIPI handshake?
The exact CMake or install steps needed to force Nektar++ to use an external CWIPI 1.3.0 instead of its internal copy?
Thank you for your guidance.
Best wishes, 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
participants (2)
-
Chris Cantwell
-
dxz324＠student.bham.ac.uk