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|
|Status||closed||Resolution||no change required|
|Fixed in Version|
|Summary||0003841: Normalization of residuals in linear solvers not allways wanted|
|Description||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.
|Steps To Reproduce||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.
|Additional Information||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.
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.
|Tags||No tags attached.|
example.zip (38,463 bytes)
OF9_patch.zip (5,757 bytes)
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.
|2022-05-27 12:57||user136||New Issue|
|2022-05-27 12:57||user136||File Added: example.zip|
|2022-05-27 12:57||user136||File Added: OF9_patch.zip|
|2022-05-27 13:30||henry||Assigned To||=> henry|
|2022-05-27 13:30||henry||Status||new => closed|
|2022-05-27 13:30||henry||Resolution||open => no change required|
|2022-05-27 13:30||henry||Note Added: 0012601|