October 2025 - Nektar-users

Pressure boundary conditions for velocity correction scheme
by Michałowski Krzysztof (STUD) 16 Oct '25

16 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, I am a student at Warsaw University of Technology and I will be using Nektar++ for my masters thesis. I have a question about pressure boundary conditions for velocity correction scheme. To ask this question i had to write down some formulas that is why it was more conviniant to attache it to this message as a pdf document. Best Regards, Krzysztof Michałowski

5 6

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