What you experience is a divergence:

```
PIMPLE: Iteration 11
smoothSolver: Solving for Ux, Initial residual = 0.7320385686, Final residual = 20.08690705, No Iterations 1000
smoothSolver: Solving for Uy, Initial residual = 0.7140772146, Final residual = 5.819994424, No Iterations 1000
```

Look at your final residual: it is too high (it should be much lower than 1). A hint for that is that the simulation has reached the maximum number of iterations (set here to 1000). This means that the results you get are very unphysical.

preCICE also has troubles converging at this situation, already from the first time step (notice the `it 50 of 50`

part):

```
PIMPLE: Iteration 50
smoothSolver: Solving for Ux, Initial residual = 6.73806608e-16, Final residual = 6.73806608e-16, No Iterations 0
smoothSolver: Solving for Uy, Initial residual = 2.411149517e-17, Final residual = 2.411149517e-17, No Iterations 0
GAMG: Solving for p, Initial residual = 4.206542465e-11, Final residual = 4.206542465e-11, No Iterations 0
time step continuity errors : sum local = 7.039356843e-16, global = 6.156768306e-18, cumulative = -5.143514102e-12
GAMG: Solving for p, Initial residual = 4.206542214e-11, Final residual = 4.206542214e-11, No Iterations 0
time step continuity errors : sum local = 7.039356843e-16, global = 6.156768306e-18, cumulative = -5.143507945e-12
ExecutionTime = 88.09 s ClockTime = 92 s
---[preciceAdapter] [DEBUG] Writing coupling data...
---[preciceAdapter] [DEBUG] Advancing preCICE...
(0) 03:39:37 [mapping::PetRadialBasisFctMapping]:873 in printMappingInfo: Mapping Forces0 conservative from Fluid-Mesh-Faces (ID 0) to Calculix_Mesh (ID 2) for dimension 0) with polynomial set to separate
(0) 03:39:37 [mapping::PetRadialBasisFctMapping]:873 in printMappingInfo: Mapping Forces0 conservative from Fluid-Mesh-Faces (ID 0) to Calculix_Mesh (ID 2) for dimension 1) with polynomial set to separate
(0) 03:39:37 [mapping::PetRadialBasisFctMapping]:873 in printMappingInfo: Mapping Forces0 conservative from Fluid-Mesh-Faces (ID 0) to Calculix_Mesh (ID 2) for dimension 2) with polynomial set to separate
(0) 03:39:37 [mapping::PetRadialBasisFctMapping]:873 in printMappingInfo: Mapping Displacements0 consistent from Calculix_Mesh (ID 2) to Fluid-Mesh-Nodes (ID 1) for dimension 0) with polynomial set to separate
(0) 03:39:37 [mapping::PetRadialBasisFctMapping]:873 in printMappingInfo: Mapping Displacements0 consistent from Calculix_Mesh (ID 2) to Fluid-Mesh-Nodes (ID 1) for dimension 1) with polynomial set to separate
(0) 03:39:37 [mapping::PetRadialBasisFctMapping]:873 in printMappingInfo: Mapping Displacements0 consistent from Calculix_Mesh (ID 2) to Fluid-Mesh-Nodes (ID 1) for dimension 2) with polynomial set to separate
(0) 03:39:37 [impl::SolverInterfaceImpl]:390 in advance: it 50 of 50 | dt# 1 | t 0 of 10 | dt 0.001 | max dt 0.001 | ongoing yes | dt complete no | read-iteration-checkpoint |
```

Furthermore, if we look at the succeeded case with Re=20, something looks very odd already in the inlet boundary (so, a CFD-specific problem, nothing with coupling yet):

I would recommend that you take a step back and run the CFD model alone for an extended simulation time and see that everything is fine there first. Eitherway, the last result files I see in the succeeded case are for t=0.6s. What happens if you run it for longer?

## Parabolic inlet profile

I am not sure what is going wrong here:

```
inlet
{
type fixedProfile;
profile csvFile;
profileCoeffs
{
nHeaderLine 0;
refColumn 1;
componentColumns 3(2 3 4);
separator ",";
mergeSeparators 0;
file "Fluid/0.orig/0.2U.csv";
}
direction (0 1 0);
origin 0,0,0;
}
```

but it would be a good idea to try with groovyBC (part of swak4Foam). I donâ€™t have a config with me at the moment, but if you make one (or find the problem with the csv approach), it would be nice to post it here.

Keep in mind that you also need a time-varying velocity inlet.

## PETSc error

PETSc just catches and forwards the errors/signals of any application using it (same with MPI). This indeed makes it very cryptic. The error here is: `Caught signal number 8 FPE: Floating Point Exception,probably divide by zero`

and it usually means a numerical explosion somewhere (in this case, in the velocity calculations).