View Issue Details

IDProjectCategoryView StatusLast Update
0003843OpenFOAMPatchpublic2022-05-30 15:18
Reporteruser136Assigned Tohenry 
Status closedResolutionno change required 
PlatformHPC-ClusterOSCentOSOS Versionunknown
Product Version9 
Fixed in Version 
Summary0003843: REOPENING: Linear solver residual tolerances should not always be normalized
Description@henry: This is a reopening of in order to discuss the mentioned points.

Your wrote: "It is not clear to me that removing normalisation is a useful general approach"
Answer: The proposed patch neither removes normalisation from the code nor is it proposed to be a general approach. The normalization can _optionally_ be switched off when using the proposed patch.

You wrote: "we would not recommend it as it makes the stable operation of the case more sensitive to the solver convergence settings"
Answer: Yes, using it would make the case more sensitive to the convergence settings. That's exactly the purpose. It is sometimes necessary for an efficient solution procedure. The setting is optional and not the default. Thus, normally the current procedure will be retained.

Your wrote: "If it is necessary or useful to control the component convergence separately"
Answer: The example is just an example, that shows the background. It shows the obvious problem of a separate normalization for each component in a displacement. The basic considerations apply also for other set-ups, e.g. for highly transient problems. The normalization equilibrates the used computational effort over time and increases the effort for "calm" periods. Example: Tracer transport. While there is no tracer in the system, the normalization factor is near zero, resulting in excessive iterations in order to bring down the error below the residual divided by "near zero".


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 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 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
TagsNo tags attached.



2022-05-30 15:08

reporter (38,463 bytes) (5,757 bytes)


2022-05-30 15:18

manager   ~0012605

I think the approach I suggested previously in which the tolerances could be optionally specified component-wise would be better and we will implement and maintain this when we have secured funding to do so.

Issue History

Date Modified Username Field Change
2022-05-30 15:08 user136 New Issue
2022-05-30 15:08 user136 File Added:
2022-05-30 15:08 user136 File Added:
2022-05-30 15:18 henry Assigned To => henry
2022-05-30 15:18 henry Status new => closed
2022-05-30 15:18 henry Resolution open => no change required
2022-05-30 15:18 henry Note Added: 0012605