- Nektar-users - imperial.ac.uk

Question about CWIPI�CNektar++ coupling performance and CG iterations
by dxz324＠student.bham.ac.uk 10 Oct '25

10 Oct '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 you are doing well. I would like to ask for your advice regarding the performance issue I have encountered during the CWIPI�CNektar++ coupling tests. When running the coupled simulation, I observed that each sending step from the Python side takes about 34 seconds, and the Nektar++ output shows the following messages: Initial Conditions: - Field p: 0 - Field u: 0 - Field v: 0 sent P 1 (issend+wait walltime: 1.303886s) about to send P 2 WARNING: relocating 262112 of 262112 points WARNING: relocating 261920 of 261920 points ... CG iterations made = 0 using tolerance of 1e-09 (error = 0, rhs_mag = 1) CG iterations made = 191 using tolerance of 1e-09 (error = 9.33e-10, rhs_mag = 0.627) CG iterations made = 192 using tolerance of 1e-09 (error = 9.35e-10, rhs_mag = 3.23) Receive total time: 34.41s, Receive waiting time: 8.6887e-05 Receive start time: 1.7303e-05 sent P 2 (issend+wait walltime: 34.722994s) From my understanding, this coupling is intended to transfer data from a small, fine-resolution acoustic source region to the larger, coarser Nektar++ mesh, where the source region occupies only a small portion of the overall computational domain. However, the data exchange still takes a long time (about 34 s per step), and I am trying to understand the reason for this large cost. I also tried to pre-interpolate the source data in Python onto exactly the same Nektar++ mesh before sending it. After doing this, the ��relocating �� points�� warnings disappeared, which suggests the point-location process is no longer repeated. Nevertheless, the CG iterations still appear in the log, and the total runtime became even longer. Could you please clarify: 1. What exactly do these ��CG iterations made = �� lines represent in Nektar++? Are they part of the time-integration or linear-solver stage? 2. When you performed similar CWIPI�CNektar++ coupling before, did you encounter the same long per-step runtime? 3. Would it be necessary to modify the Nektar++ source code to restrict the receive operation only to the acoustic source region (rather than the full mesh)? Thank you very much for your time and advice. Any guidance on how you addressed this issue in your earlier work would be greatly appreciated. Best wishes, Dao

1 0

Issue with convective ouflow BC
by Alexander Schukmann 08 Oct '25

08 Oct '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 everyone, I tried running an Adjoint Stability Analysis including Dongs convective outflow BC enforced through a Robin type specification as detailed in the user guide. I use a 2.5D expansion with version 5.7.0 and obtain satisfactory results with a high-order pressure BC. However, as I switch to a Robin BC, the following error appears: double free or corruption (!prev) ...indicating segmentation violation. I've attached some files of a MRE, which is basically just a cylinder at Re = 42. Is there anything wrong with my setup? Any help would be much appreciated. Best, Alex Gesendet mit [Proton Mail](https://proton.me/mail/home): Ein sicherer E-Mail-Dienst.

2 3

Conjugate Heat Transfer Development in Nektar++
by Abhishek Kumar 26 Sep '25

26 Sep '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 would like to know if there is any branch of Nektar++ that includes conjugate heat transfer (CHT) development. From what I can see, this feature does not appear to be included in the current code. I am exploring ways to perform CHT calculations with Nektar++. Could you please let me know if there has been any past development in this area? Best regards, Abhishek Abhishek Kumar CFD/MHD Analyst abhishek.kumar(a)tokamakenergy.co.uk<mailto:abhishek.kumar@tokamakenergy.co.uk> www.tokamakenergy.co.uk<http://www.tokamakenergy.co.uk/> Tokamak Energy Ltd, 173 Brook Drive, Milton Park, Abingdon, OX14 4SD [cid:46e2000d-de1a-4ec1-92e1-5b361360221f] This e-mail and any attachments are confidential and may contain personal views that are not the views of Tokamak Energy Ltd unless specifically stated. If you have received this email in error, please notify the sender immediately and then delete it from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.

2 2

Validation of Biglobal Floquet Analysis of Cylinder
by Gaurav Gupta 19 Sep '25

19 Sep '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 All ! I am trying to validate the Barkley JFM paper on the Biglobal floquet analysis of cylinder. I am doing the simulations at the following Re and Beta values to find the neutral modes and create a curve of neutral modes (as done in the paper) to identify the critical Re and Beta. 1. Re 190; Beta = 1.4 and 1.8. 2. Re 200, Beta = 1.2 and 2.0 For the above cases, the leading eigenvalue magnitude should be approximately 1. But the solver is producing eigenvalues with magnitude greater than 1. For example, converged eigenvalues for Re=190 and Beta=1.4 Magnitude Angle Growth Frequency EV: 0 1.28858 0.886868 0.202835 0.709494 EV: 1 1.28858 -0.886868 0.202835 -0.709494 EV: 2 1.13585 0.342226 0.101906 0.273781 EV: 3 1.13585 -0.342226 0.101906 -0.273781 For the base flow, I am doing DNS for around 40 shedding periods (~200s) and then storing 32 snapshots for the 41st shedding period. DNS solution is converged and validated against CD, and St values. The DNS mesh has around (~2050 Quads and 7th order polynomial). I also made sure that the 1st snapshot is not equal to the 32nd snapshot as mentioned in the user-guide. Later, I am interpolating the DNS snapshots to a coarser mesh (~550 Quads and 7th order polynomial) using FieldConvert. These interpolated chk files are used as baseflow for the Floquet Analysis. I would be highly grateful, if anyone could help me out with this. I have attached my case setup files for Re=190 and Beta=1.4 case. Case Files: https://drive.google.com/drive/folders/1-0fbs1mxAuQVKfYpbSpj5PBod2aQjKKS?us… Thanks! Regards, *Gaurav Gupta* Scientist/Engineer-SC Space Applications Centre, ISRO Ahmedabad, GJ, India

2 1

Re: [Nektar-users] Problem in Validation of Biglobal Stability Analysis with ARPACK
by Abhishek Kumar 02 Sep '25

02 Sep '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 Gaurav, Thank you for your kind email. I would suggest reducing the Krylov dimension to 16. Since your base flow is 2D2C, you can use HalfMode as the ModeType, which will reduce your computation time. Furthermore, I noticed that for β = 1, you have set Lz = 1, which is incorrect. It should be Lz = (2π)/β. I have also found that ModifiedArnoldi sometimes works better than Arpack: So I suggest the following solver condition: ** ** ** ** ** ** ** ** and the following parameter condition: ** kdim = 16 ** ** nvec = 1 ** ** nits = 500 ** ** evtol = 1e-06 ** ** HomModesZ = 1 ** ** BETA = 1.0 ** ** LZ = (2*PI)/BETA ** Best regards, Abhishek On Sun, Aug 31, 2025 at 6:15 PM Gaurav Gupta <gauravxpgupta(a)gmail.com> wrote: > Hello Prof. Abhishek, > I saw your answers to multiple queries in the NEKTAR++ community and > believe would be help me with stability analysis using NEKTAR++. I am > trying to validate the results of biglobal LSA of NACA0012 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 will be highly grateful, if you could > check my implementation and highlight any possible issues. > > Thanks! > > Regards, > *Gaurav Gupta* > Scientist/Engineer-SC > > Space Applications Centre, ISRO > > Ahmedabad, GJ, India >

1 0

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