August 2025 - Nektar-users

Problem in conversion of NEK5000 data to NEKTAR++ data
by Gaurav Gupta 31 Aug '25

31 Aug '25

******************* 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. ******************* Hello, I am trying to convert the DNS data from NEK5000 (.f%5d files such as cyl0.f00001) to NEKTAR++ .fld/chk files using the following command: *FieldConvert cyl0.f00001 cyl_0.fld* The conversion fails with the following error: Field contains unknown variable: X [virgo1:10341] *** Process received signal *** [virgo1:10341] Signal: Aborted (6) [virgo1:10341] Signal code: (-6) [virgo1:10341] [ 0] /lib64/libpthread.so.0(+0xf630)[0x7f8b79596630] [virgo1:10341] [ 1] /lib64/libc.so.6(gsignal+0x37)[0x7f8b791ef387] [virgo1:10341] [ 2] /lib64/libc.so.6(abort+0x148)[0x7f8b791f0a78] [virgo1:10341] [ 3] /home/manukv/local/nektar/lib64/libFieldUtils.so.5.8.0(_ZN6Nektar10FieldUtils12InputNek50009v_ProcessERN5boost15program_options13variables_mapE+0x198b)[0x7f8b8085b63b] [virgo1:10341] [ 4] FieldConvert[0x4219e5] [virgo1:10341] [ 5] FieldConvert[0x41e777] [virgo1:10341] [ 6] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f8b791db555] [virgo1:10341] [ 7] FieldConvert[0x4210ed] [virgo1:10341] *** End of error message *** Aborted (core dumped) Has anyone figured out how to solve this issue ? It would be a great help.I have attached the NEK5000 file for reference. Thanks! Regards, *Gaurav Gupta* Scientist/Engineer-SC Space Applications Centre, ISRO Ahmedabad, GJ, India

1 0

Asking for solutions to "CWIPI API mismatch in Nektar++"
by dxz324＠student.bham.ac.uk 21 Aug '25

21 Aug '25

******************* 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 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

2 1

Question about Nektar++ and CWIPI coupling issue
by dxz324＠student.bham.ac.uk 18 Aug '25

18 Aug '25

******************* 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++ developers, I hope this email finds you well. I am currently working on coupling Nektar++ with CWIPI, but I have encountered a problem during the initialization phase. I am using nektar++5.2.0 and cwipi 1.3.0 in archer2. I am launching the MPI task with srun: rank 0 is the CWIPI transmitting side, rank 1 is the Nektar++ receiving side. However, the process always gets stuck at the initialization stage and no data is transmitted. After some debugging, I noticed that the issue seems related to the way usernames (application names) are linked between the two sides. Below is a part of the debug output: [APDB][debug] namesLength: 1 7 -> recomputed totalLength=8 [APDB][post-Allgatherv] namesLength = 1 7 [APDB][debug] rank=1 After Allgatherv: totalLength=8 [APDB][debug] mergeNames raw buffer (len=8): PyApp_\0\0 [APDB][debug] End of buffer dump [APDB][rank 1] ==== loop begin irank=0 ==== pre-assert: index=0 totalLength=8 [APDB] cur-seg hex (len=6, show=6): 0000 : 50 79 41 70 70 5f [APDB][rank 1] cur-seg meta: max_left=8 nul_off=6 safe_len=6 [APDB][rank 1] cur-seg as string(bounded)='PyApp_' [APDB][rank 1] parsed currentName='PyApp_' size=6 compare with applicationName='nektar' -> strcmp=-30 [APDB][rank 1] currentString != currentName (prev='') [APDB][rank 1] -> insert DISTANT app 'PyApp_' success=1 [APDB][rank 1] setBeginningRank(0) for 'PyApp_' [APDB][rank 1] update currentString='PyApp_' j=1 [APDB][rank 1] advance index by size+1 = 7 -> index=7 (totalLength=8) [APDB][rank 1] ==== loop end irank=0 ==== [APDB][init] ENTER: comm_rank=1 comm_size=2 applicationName=nektar, CommCompare vs MPI_COMM_WORLD = 0 which indicates that the Nektar++ side did correctly read its local application name as nektar, during the MPI stage it did not insert its own name into mergeNames. As a result, only the CWIPI side (rank 0) name is included. On the Nektar++ side, I launched the solver with: AcousticSolver --cwipi 'nektar' and in the XML configuration file I added: <COUPLING NAME="NekApp" TYPE="Cwipi"> </COUPLING> May I ask if there is anything else that needs to be configured on the Nektar++ side to ensure that the names match correctly? It seems that the problem originates from the Nektar++ endpoint recognition. Thank you very much for your time and advice. Best regards, Dao

1 0

Problem in Validation of Biglobal Stability Analysis with ARPACK
by Gaurav Gupta 18 Aug '25

18 Aug '25

******************* 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. ******************* Hello, I am trying to validate the results of biglobal LSA of naca 0012 at AOA=16 with ARPACK. I was able to recreate the base-flow and tried to do the direct analysis with shift invert transformation at 0i, 2i, 4i, 6i, 8i and 10i and beta=1 but the eigenvalues are not correct. I have attached the case files as well as the reference paper. I would be highly grateful, if someone could check my implementation and highlight any possible issues. Thanks! Regards, *Gaurav Gupta* Scientist/Engineer-SC Space Applications Centre, ISRO Ahmedabad, GJ, India Telephone: +91 (0) 79-2691-2269

1 0

Request for advice on CWIPI–Nektar++ coupling setup (stuck at initialization)
by dxz324＠student.bham.ac.uk 08 Aug '25

08 Aug '25

******************* 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++ developers, I am currently trying to run a CWIPI–Nektar++ coupled example on Archer2, where a Python program (CWIPI source side) sends data to Nektar++ (AcousticSolver) to compute APE. I would like to confirm whether my setup steps are correct and ask for any advice from those who have successfully used CWIPI with Nektar++. 1. CWIPI side (Python) CWIPI initialization is done as follows: comm = MPI.COMM_WORLD code_name = "PyApp" coupled_code_name = "NekApp" intra = pycwp.init(comm, [code_name], True) cpl = pycwp.Coupling( code_name, "LambFile", # matches XML coupling name coupled_code_name, 2. Nektar++ side In the Nektar++ XML condition file (Condition_try.xml), the coupling section is: <COUPLING NAME="LambFile" TYPE="Cwipi"> # the variables for source are set to 0 in source function </COUPLING> Nektar++ is started with: AcousticSolver --cwipi 'NekApp' mesh.xml Condition.xml --verbose so the local code name is "NekApp", matching the coupled_code_name in the Python script. 3. Archer2 run setup I created two shell scripts: run_cwipi.sh: export MPICH_SMP_SINGLE_COPY_MODE=CMA source ... exec python -u cwipi_source.py run_nek.sh (Nektar++ side): export ... exec AcousticSolver --cwipi 'NekApp' mesh.xml Condition.xml --verbose and a .conf file--multi.conf: 0 ./run_cwipi.sh 1 ./run_nek.sh Run command on Archer2: srun --ntasks=2 --multi-prog multi.conf 4. The issue When running, both sides print the CWIPI initialization banner: cwipi 1.3.0 initializing ------------------------ 5. Request for advice I would like to confirm: Is my CWIPI–Nektar++ code-name mapping correct (PyApp ↔ NekApp, "LambFile" coupling name)? Is srun --multi-prog with shared MPI_COMM_WORLD the recommended way for intra-communicator mode? Are there known restrictions in CWIPI–Nektar++ coupling when each code only has one MPI rank? Could there be additional configuration required on the Nektar++ side for CWIPI to complete initialization? Any guidance or examples from someone who has successfully run CWIPI with Nektar++ would be very helpful. Thank you in advance for your time and assistance. Best regards, Dao

1 0