View Issue Details

IDProjectCategoryView StatusLast Update
0003841OpenFOAMContributionpublic2022-05-27 13:30
Reporteruser136Assigned Tohenry 
PrioritynormalSeverityfeatureReproducibilityalways
Status closedResolutionno change required 
PlatformHPC-ClusterOSCentOSOS Versionunknown
Product Version9 
Fixed in Version 
Summary0003841: Normalization of residuals in linear solvers not allways wanted
DescriptionIn 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 ReproduceThe 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 InformationProposal: 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.







TagsNo tags attached.

Activities

user136

2022-05-27 12:57

reporter  

example.zip (38,463 bytes)
OF9_patch.zip (5,757 bytes)

henry

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.

Issue History

Date Modified Username Field Change
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