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