IQN-IMVJ Displacement Mapping Slow


I am running into an issue with either data mapping, IQN-IMVJ or both. I am doing FSI simulations using OpenFOAM and Calculix
I have found IQN-IMVJ to be better for my setup, taking less iterations to converge, compared to IQN-ILS. To my understanding, after the the chunck-size number of time-windows is reached, the Jacobian is recomputed and this takes some time, right? However, I have noticed that this time seems to increase the longer the simulations runs. Is this due to there being more time-windows to reuse? Also looking at the output of the first particiapant (fluid) I see that the force mapping is almost instantaneous, and the long wating period comes while the displacment mapping occurs.
I have attached my precice-config.xml below. Let me know if you need more information.

precice-config.xml (3.0 KB)

Hi, openFoe. Thank you for your question.

Actually no. Since by every restart call we always have the same amount(i.e. the chunk-size) of operations to do.

About the mapping problem, could I ask which version of preCICE you are using?

Best Regards

Thanks for the answer regarding the time-windows.

I am using
preCICE precompiled binary: libprecice2_2.5.0_jammy.deb
OpenFOAM adapter version 1.2.2
CCX adapter is the precomiled calculix-precice2_2.20.0-1_amd64_jammy.deb

Hi Jun,
I figured I might add some data to my claim. I checked the ExecutionTime and the ClockTime OpenFOAM shows. As you can see, the ExecutionTime steadily rises, which at least shows that each iteration takes OpenFOAM the same time. Looking at the ClockTime, you can a jump every 8 time-windows, when the IMVJ restarts. Unfortunately, this jump does seem to increase over time, indicating that the restart takes more and more time. Any ideas what might cause this?

Update on the situation. I changed imvj-restart-mode from RS-SVD to * RS-LS*.
From the graph you can see that this massively improved the situation. The restarting still includes an overhead every 8 time-windows, however it appears to be the same overhead every time.


Thank you for the clear testing.

In principle we say that the SVD-restart has linear runtime complexity in the number of unknowns on the interface, under the assumption that we always only need small number of ranks to represent the inverse Jacobian, i.e. preCICE is able to truncate most small single values after the restart update and only keep several large ones.
Here I suppose the DoF is constant, so I would suspect that the number of single values after truncation has increased gradually. This number also influences the runtime complexity directly. You could check if it’s the case in the log file(might need debug level), it’s written like:

SVD factorization of Jacobian is truncated to xxx DOFs.

Hope you can find some useful info there :slight_smile: