#### View Issue Details

ID Project Category View Status Date Submitted Last Update 0003841 OpenFOAM Contribution public 2022-05-27 12:57 2022-05-27 13:30 user136 henry normal feature always closed no change required HPC-Cluster CentOS unknown 9 0003841: Normalization of residuals in linear solvers not allways wanted In the implementation of the linear solvers, the calculated L2-norm (?) of the residual vector is compared to user supplied absolute and relative tolerances. Before comparison, the calculated residual is normalized with an estimate of the scale of the problem, which is computed from an initial guess for the solution and the RHS of the equation system. This is helpful, if the expected absolute values of the residuals are unknown to the user. It is a disadvantage, if the expected absolute errors are known. Thus it is proposed to optionally switch of the normalization of the residuals. The provided example is a basic testcase to illustrate the issue, which is independent from the physics of the problem. It comprises the solution of a mesh deformation with a Laplacian solver. The domain is a cubic block mesh (1 m in length). The xmin patch is fixed, the xmax patch is moving with a prescribed velocity (vx 1.E-03 m/s vy 1.E-13 m/s vz 0.0 m/s). All other boundaries are zero gradient.  As vy is much smaller than vx (ten orders of magnitude), the user supposedly does want to minimize the numerical effort for the y-movement.    Please unzip example.zip and run moveMesh. The output contains [...] Time = 0.1 smoothSolver: Solving for cellDisplacementx, Initial residual = 1, Final residual = 9.9092267e-15, No Iterations 875 smoothSolver: Solving for cellDisplacementy, Initial residual = 0.99999995, Final residual = 9.9915763e-15, No Iterations 875 [...] Though the displacement in y-direction is 10 orders of magnitude smaller than the displacement in x-direction, the calculated initial residuals are nearly the same. Also the number of iterations is the same. This is due to the normalization and could be unwanted. [...] Time = 1 smoothSolver: Solving for cellDisplacementx, Initial residual = 0.052631579, Final residual = 9.8682478e-15, No Iterations 792 smoothSolver: Solving for cellDisplacementy, Initial residual = 0.052593143, Final residual = 9.8554109e-15, No Iterations 792 [...] In the last timestep, the initial residual has dropped by a factor 20. This is due to the normalization and not conforming to the "real" problem, which is roughly linear and thus the initial residuals should roughly stay the same for all timesteps. This makes it difficult to choose a tolerance. Proposal: Give the user the possibility to switch of the normalization (or change to another method in the future). In the attached source codes the calculation for normFactor was extended, so that it returns "1", if the user specifies "residualNormalization none" in the solver dictionary. If nothing is specified, the old behaviour is retained. New output with the proposed change: [...] Time = 0.1 smoothSolver: Solving for cellDisplacementx, Initial residual = 0.002, Final residual = 9.8382033e-15, No Iterations 698 smoothSolver: Solving for cellDisplacementy, Initial residual = 1.9987589e-13, Final residual = 9.7597962e-15, No Iterations 43 [...] The initial residual for cellDisplacementy is ten orders of magnitude smaller than the x-direction residual. This is conforming to the boundary condition. The number of iterations is much smaller, too, as the desired error level is reached much earlier. [...] Time = 1 smoothSolver: Solving for cellDisplacementx, Initial residual = 0.0019982016, Final residual = 9.763543e-15, No Iterations 699 smoothSolver: Solving for cellDisplacementy, Initial residual = 2.0936632e-13, Final residual = 9.6705254e-15, No Iterations 49 [...] For the last timestep the initial residuals are roughly the same as for the first. This conforms to the linear behaviour of the problem. I would appreciate if these patches help the OpenFOAM development. Best regards, Carsten Thorenz P.S.: I'm not sure if the normalization offers any benefit over the method to compare the relative reduction of the residua (i.e. relTol). But that's another story. No tags attached.

#### Activities

 2022-05-27 12:57 reporter example.zip (38,463 bytes) OF9_patch.zip (5,757 bytes) 2022-05-27 13:30 manager   ~0012601 It is not clear to me that removing normalisation is a useful general approach and we would not recommend it as it makes the stable operation of the case more sensitive to the solver convergence settings. If it is necessary or useful to control the component convergence separately specifying a Type tol and relTol would be a better approach which is already supported by the LduMatrixSolver and could be added to fvMatrixSolve given funding for the development and maintenance effort.