View Issue Details
ID  Project  Category  View Status  Date Submitted  Last Update 

0002028  OpenFOAM  Bug  public  20160316 15:58  20160320 20:53 
Reporter  Lieven  Assigned To  henry  
Priority  normal  Severity  minor  Reproducibility  always 
Status  closed  Resolution  no change required  
Platform  GNU/Linux  OS  Ubuntu  OS Version  14.04 
Fixed in Version  dev  
Summary  0002028: residualControl ignores Uresiduals when using coupled PBiCCCG solver  
Description  When attempting to stop a simulation automatically by setting a residualControl in fvSolution, the Uresiduals are ignored when using the coupled PBiCCCG solver.  
Steps To Reproduce  Using the incompressible/simpleFoam/pitzDaily tutorial, set fvSolution to: solvers { p { solver GAMG; tolerance 1e06; relTol 0.1; smoother GaussSeidel; nPreSweeps 0; nPostSweeps 2; cacheAgglomeration on; agglomerator faceAreaPair; nCellsInCoarsestLevel 10; mergeLevels 1; } U { type coupled; solver PBiCCCG; preconditioner DILU; tolerance (1e8 1e8 1e8); relTol (0.001 0.001 0.001); } /* U { solver smoothSolver; smoother symGaussSeidel; tolerance 1e05; relTol 0.1; } */ "(kepsilonomegafv2)" { solver smoothSolver; smoother symGaussSeidel; tolerance 1e05; relTol 0.1; } } SIMPLE { nNonOrthogonalCorrectors 0; consistent yes; residualControl { p 1e1; U 1e2; "(kepsilonomegafv2)" 1e1; } } Note that the residualControlresiduals are set to very tolerant values for illustration purpose.  
Additional Information  When using the coupledsolver for U, the simulation "converges" in 7 iterations although the final iteration shows:  Time = 7 DILUPBiCCCG: Solving for Ux, Initial residual = 0.0458328, Final residual = 6.89602e06, No Iterations 9 DILUPBiCCCG: Solving for Uy, Initial residual = 0.0604103, Final residual = 1.84103e05, No Iterations 9 DILUPBiCCCG: Solving for Uz, Initial residual = 0.398129, Final residual = 0.000116036, No Iterations 9 GAMG: Solving for p, Initial residual = 0.0791176, Final residual = 0.00740836, No Iterations 4 time step continuity errors : sum local = 0.750902, global = 0.10451, cumulative = 0.979509 smoothSolver: Solving for epsilon, Initial residual = 0.0323437, Final residual = 0.00199505, No Iterations 3 smoothSolver: Solving for k, Initial residual = 0.0584042, Final residual = 0.00429584, No Iterations 4 ExecutionTime = 1.02 s ClockTime = 1 s SIMPLE solution converged in 7 iterations  When using the smoothSolver settings, the solution converges in 223 iterations, taking also the Uresidual into account: Time = 223 smoothSolver: Solving for Ux, Initial residual = 0.00128387, Final residual = 0.000127913, No Iterations 5 smoothSolver: Solving for Uy, Initial residual = 0.0099375, Final residual = 0.000729481, No Iterations 6 GAMG: Solving for p, Initial residual = 0.00680682, Final residual = 0.000619236, No Iterations 6 time step continuity errors : sum local = 0.0299118, global = 0.00248546, cumulative = 1.20842 smoothSolver: Solving for epsilon, Initial residual = 0.000812368, Final residual = 5.19083e05, No Iterations 3 smoothSolver: Solving for k, Initial residual = 0.00190921, Final residual = 0.00011103, No Iterations 4 ExecutionTime = 19.16 s ClockTime = 23 s SIMPLE solution converged in 223 iterations  
Tags  No tags attached.  

This should already be fixed in OpenFOAMdev, could you test it and report back? 

I've tested with the latest OpenFOAMdev and the problem is that the Z direction is being solved when it shouldn't :( Namely, the initial residual for Uz direction doesn't go below 0.28, hence it never falls below 0.01. This is very strange, I didn't look more closely to coupled matrix solvers a few months ago, as I had assumed this was already taken into account in those situations... give me a few minutes and I'll see if I can figure this one out. 

After investigating the code and doing some testing, there are two possible solutions that I can think of and none of them are pleasant to implement: 1 "normFactor" can be neutralized by setting to a highenough value for the respective invalid directions/components. The problem here is that each "invalid direction" is still solved with just numerical noise (all values near 0.0, but rarely zero) and if something weird occurs in the matrix solver (maybe somehow a division by zero or near infinite!?) while solving this direction, there will be a crash. Because this and other disabled directions will still be "solved" for the same number of iterations as the other directions, which is what this coupled matrixsolving feature was conceived for. 2 Having an automatic rescaling of number of components in the matrices to be solved. Although this is theoretically possible, it's somewhat of a nightmare situation to develop. This means having 2D vectors, 5 or more crippled tensors (without 1 or more components) and I don't even know what else. Therefore, the most practical solution that I can think of is this: do not use singleequationcoupled matrixsolvers for 2D cases. Although this reminds me of Henry's following question on issue #1824: http://www.openfoam.org/mantisbt/view.php?id=1824#c5427  namely: «There are still some choices to be made, for example should the segregated approach be maintained?» As far as I can figure out, this is a scenario where the segregated solver might be a more practical implementation for at least 2D simulations over a 3D volume, when solving the momentum equation. ... Although having at least a "vector2D" class would still be practical enough (it's just one more type)... it's the tensors that are a bigger concern... at least as far as I can deduce right now. 

Wyldckat, have you also tested this with a 3D case? I'm asking because, although I reported it using a 2D tutorial case, I initially encountered this problem when running a 3D case. 

@Lieven: Sorry, I should have been clearer: 1 I used OpenFOAMdev: https://github.com/OpenFOAM/OpenFOAMdev/  which is the repository with the latest developments for OpenFOAM and which will be part of the next major release. It's the version Henry asked about if you could test with it. I was afraid you wouldn't test with it, so I went ahead and tried it myself. 2 Using the following settings: residualControl { p 1e1; U 0.30; "(kepsilonomegafv2)" 1e1; } would result in simpleFoam stopping at Time = 9. But again, this was with OpenFOAMdev. And as I implied, on issue #1824  http://www.openfoam.org/mantisbt/view.php?id=1824  is a similar report to your report and that one was fixed in OpenFOAMdev, namely on this commit: https://github.com/OpenFOAM/OpenFOAMdev/commit/1944b09bb530a8b9a2546ac3b196b137668d329f This fix cannot be implemented in OpenFOAM 3.0.x, because it would break compatibility with 3.0.1 and 3.0.0, due to the extent of the changes that were needed to fix this issue. 

This is already fixed in OpenFOAMdev in which the convergence criterion may be specified for each component. 

Sorry to reopen+close again, but for the sake of completion, here's the updated example for the residual control per U component: residualControl { p 1e1; Ux 1e2; Uy 1e2; "(kepsilonomegafv2)" 1e1; } I had totally forgot about this feature :( 
Date Modified  Username  Field  Change 

20160316 15:58  Lieven  New Issue  
20160316 16:12  henry  Note Added: 0006039  
20160319 16:48  wyldckat  Note Added: 0006042  
20160319 20:11  wyldckat  Note Added: 0006043  
20160319 22:23  Lieven  Note Added: 0006044  
20160319 23:25  wyldckat  Note Added: 0006045  
20160320 10:38  henry  Note Added: 0006047  
20160320 10:38  henry  Status  new => closed 
20160320 10:38  henry  Assigned To  => henry 
20160320 10:38  henry  Resolution  open => no change required 
20160320 10:38  henry  Fixed in Version  => dev 
20160320 20:53  wyldckat  Note Added: 0006050  
20160320 20:53  wyldckat  Status  closed => feedback 
20160320 20:53  wyldckat  Resolution  no change required => reopened 
20160320 20:53  wyldckat  Status  feedback => closed 
20160320 20:53  wyldckat  Resolution  reopened => no change required 