This looks more like an system-specific execution issue, which I assume you solved already. Can you reproduce it?
While one-way coupling is a natural first step when setting up a simulation, I would not expect a one-way FSI to converge. But this diverges too early, which hints an issue with the configuration.
Looking at your precice-config.xml:
<coupling-scheme:serial-implicit>
<participants first="Fluid" second="Solid" />
<max-time-windows value="100000" />
<time-window-size value="1e-4" />
<exchange data="Force" mesh="Solid-Mesh" from="Fluid" to="Solid" />
<exchange data="DisplacementDelta" mesh="Solid-Mesh" from="Solid" to="Fluid" />
<max-iterations value="30" />
<relative-convergence-measure limit="1e-3" data="DisplacementDelta" mesh="Solid-Mesh" />
<relative-convergence-measure limit="1e-3" data="Force" mesh="Solid-Mesh" />
<acceleration:IQN-IMVJ>
<data name="DisplacementDelta" mesh="Solid-Mesh" />
<preconditioner type="residual-sum" />
<initial-relaxation value="0.1" />
<max-used-iterations value="10" />
<time-windows-reused value="1" />
</acceleration:IQN-IMVJ>
</coupling-scheme:serial-implicit>
The preciceDict you posted above:
interfaces
{
Interface2
{
mesh Fluid-Mesh-Faces;
patches (interface);
locations faceCenters;
readData
(
);
writeData
(
Force
);
};
};
The config.yml you posted above:
participants:
Solid:
interfaces:
- nodes-mesh: Solid-Mesh
patch: interface
read-data: [Force]
write-data: [DisplacementDelta]
Some observations:
- You are (correctly) exchanging both force and relative displacement, but (based on the
preciceDict I saw before) you are not reading those displacements.
- You are writing displacements from CalculiX, but not reading them in OpenFOAM, which looks unmotivated.
- You are (correctly) using an implicit coupling scheme, but this requires a bi-directional coupling to work, as it is based on iterations and corrections. If one participant always gives the same values, preCICE will complain.
When you say “it diverges”, what exactly do you mean? Who is “it” and what errors / logs are you getting?
Correct. But this is, in this case, important to check that the definition of the mesh is correct. You previously observed that CalculiX was “only defining 3/4th of the pipe”. Do the Solid exports confirm this observation? Are the nodes there and always with the same results, or simply not there?
I don’t know how the results are expected to look like, but if you are applying a pulse at the inlet (as we do in Elastic tube 3D | preCICE - The Coupling Library), it is normal that the values near the outlet will stay constant for a few time steps.
Make it first bi-directional, we are not yet at the point that it needs fine-tuning.
The coupling scheme and acceleration method you have selected are appropriate, but the convergence measures may be a bit too relaxed. There are a few more parameters in the acceleration, which would need looking closer into the case. The mapping also looks reasonable.
But this could be a nice question for 
I think that