I am running the GMRES solver with a statically condensed matrix system (IterativeStaticCond) and tried solving a Poisson, Helmholtz as well as ADR matrix. For any matrix, I found that the error in the GMRES iterations jumps to a high value after restarting. Interestingly, this problem does not occur when we use the ConjugateGradient solver. I have compared this against using the PETSc GMRES routine (PETScStaticCond) in the plot below. The orange and blue line is the N++ implementation with restarting where we can observe a saw-tooth shape. In comparison, the green line is also N++ but without restarting and we can observe no saw-tooth convergence. In contrast, the PETScStaticCond routine converges without any issues even when restarting the solver. The smaller iteration count to the solution is due to a more effective preconditioner that was used for PETSc.  The error seems to be either with the right-hand side **b** or the reconstructed solution **x^{nRestart}** after GMRES converges or restarts. My tests mainly consists of comparing GMRES + StaticCond to GMRES + Full, because the Full matrix solve does not show any issues with restarting. I will attach a test case (Kovasznay flow a basic case for the Incompressible flow solver) and link a [branch](https://gitlab.nektar.info/hwustenb/nektar/-/tree/fix/gmres_staticCond?ref_type=heads) for this issue where I add some verbosity to the GMRES routine for investigation. Note that one chooses the maximum iterations before restarting with `LinSysMaxStorage`. [mesh.xml](/uploads/c93dd06c1afb389815fe98ec8c72f766/mesh.xml) [sessionnpp.xml](/uploads/03678e0bc7fe9ebe056a3eed517b39ac/sessionnpp.xml) [sessionpetsc.xml](/uploads/038abe88aaaa8d41539ee55901d4ea68/sessionpetsc.xml) [.petscrc](/uploads/aab0c26e6c12c110c0c06342334ae9bc/.petscrc)