View Issue Details

IDProjectCategoryView StatusLast Update
0000968OpenFOAM[All Projects] Bugpublic2015-02-05 23:01
Reporteruser286Assigned Tohenry 
Status resolvedResolutionfixed 
PlatformIntel x86-64OSRed Hat Enterprise Linux ServeOS Version6.3 (Santiago)
Product Version 
Fixed in Version 
Summary0000968: Wall Distance Calculation Does Not Calculate True Distance
DescriptionDear OpenFOAM developers,
We have found out that the distance calculation does not locate the exact projection of the field point onto the solid surface. It is a common issue in CFD codes. With a skewed grid, the distance can be over-estimated, by about 10%. This is especially relevant to the Spalart-Allmaras turbulence model, because then the destruction term is under-estimated by about 20%, giving excessive eddy viscosity and therefore skin friction. The problem has been previously identified in bug report 826, but is yet unresolved, and we wish to help resolve it. One of us, Dr. Wei, has rewritten the subroutine in wallDist.H and wallDist.C, which are attached. It has passed our tests in terms of accuracy, but the code has not been optimized for speed. The new code is attached in the hopes that it helps you resolve this problem. Also, Dr. Churchfield has created two very simple test cases and a code (calcWallDist) that calls the wallDist calculation and writes out wall distance to the screen. The code and test cases are also attached. Both test cases are single column grids with a wall at the bottom of the column; in one case the grid is non-skewed, and in the other, it is skewed, yet both cases should return exactly the same wall distances. We would like to submit this issue and the solution to your attention.
Best regards.
Philippe Spalart, Boeing
Matt Churchfield, NREL
Chris Rumsey, NASA
Daniel Wei, Notre Dame
Steps To ReproduceCompile the calcWallDist code. Run it on the two test cases (orthogonal and nonorthogonal). It will right out wall distance, and in each case you'll see different wall distance, except at the wall adjacent grid point. Try it again with the new wallDist.C and .H in place of the current ones, and both cases will return the identical wall distances.
TagsNo tags attached.



2013-08-16 22:45


wallDistFiles.tar.gz (33,747 bytes)


2013-08-19 10:45


We currently have no switchable wall distance calculation. Once we have this we can plug in an exact version (with its own limitations).


2013-08-21 16:28


Are there plans for the future to have a switchable wall distance calculation with more options than the current method?

We realize that there are limitations with the exact method, and we do see why it has been coded as it currently is coded. Dr. Wei also has seen the current method cause the Spalart-Allmaras model to work inconsistently in places where skewed grids are unavoidable, and Dr. Spalart is concerned that most people who use the code and don't understand the details maybe getting inconsistent results.

We appreciate your help.


2014-12-29 14:54

updater   ~0003396

For future reference, this is related to this report:


2015-01-05 13:03

manager   ~0003509

I am working on run-time selectable wallDist methods at the moment and also studying the code provided by Dr. Wei. Could you clarify what the current limitations of this code are? It appears that it runs in parallel but there is no specific treatment for cyclic or other coupled boundaries, particularly processor patches requiring transforms. Has it been tested on cases including these features?


2015-01-05 14:36


(1) Henry, I did not consider those features. (2) I wrote it as a workaround last year in order to do some turbulence model researches. It worked very well in all my v&v tests. (3) But PDE method is considered to be more efficient, but I didn't have time to pursue it.


2015-01-05 14:43

manager   ~0003511

Last edited: 2015-01-06 07:47

View 2 revisions

Thanks for getting back to me on this. I already have a PDE method implemented but we replaced it with the current marching-front method as it is MUCH more efficient than the PDE approaches which do not converge very rapidly. However, we could use the marching-front method as a predictor step for the PDE algorithm without much problem. But are you sure the PDE methods are sufficiently accurate for your purpose? They are dependent on discretization accuracy of the Laplacian and other operators and these are affected by non-orthogonality so the resultant near-wall distance would not be exactly equivalent to exact methods based on ray-tracing, octree seaching etc.


2015-01-06 02:09


Last edited: 2015-01-06 07:47

View 3 revisions

Thank you Henry. You are most probably right. I am not completely sure about the grid convergence behavior of PDE method in Turb modeling. But the current marching-front method apparently could not satisfy us in terms of v&v accuracy (I mean for example this case:
I think I still have the test cases and test meshes available. If you have the PDE method ready to use and test. I can give it a try. Please let me know via daniel.wei AT



2015-01-06 07:53

manager   ~0003513

I agree that the current method is not sufficiently accurate an very distorted meshes and we need to consider alternatives. I will have the run-time selection system implemented in the next day or so and I will also implement Tucker's Poisson equation approach and resurrect the Eikonal I wrote year ago for testing.


2015-01-09 16:24

manager   ~0003522

Wall-distance is now run-time selectable in OpenFOAM-dev

and in addition to the original meshWave method I have provided the Poisson and advective-diffusive form of the Eikonal equation methods decribed in

        P.G. Tucker, C.L. Rumsey, R.E. Bartels, R.T. Biedron,
        "Transport equation based wall distance computations aimed at flows
         with time-dependent geometry",
        NASA/TM-2003-212680, December 2003.

Resolved by commits

Issue History

Date Modified Username Field Change
2013-08-16 22:45 user286 New Issue
2013-08-16 22:45 user286 File Added: wallDistFiles.tar.gz
2013-08-19 10:45 user4 Note Added: 0002425
2013-08-21 16:28 user286 Note Added: 0002436
2014-12-29 14:54 wyldckat Note Added: 0003396
2015-01-05 13:03 henry Note Added: 0003509
2015-01-05 14:36 user313 Note Added: 0003510
2015-01-05 14:43 henry Note Added: 0003511
2015-01-06 02:09 user313 Note Added: 0003512
2015-01-06 02:27 user313 Note Edited: 0003512 View Revisions
2015-01-06 07:47 henry Note Edited: 0003511 View Revisions
2015-01-06 07:47 henry Note Edited: 0003512 View Revisions
2015-01-06 07:53 henry Note Added: 0003513
2015-01-09 16:24 henry Note Added: 0003522
2015-01-09 16:24 henry Status new => resolved
2015-01-09 16:24 henry Resolution open => fixed
2015-01-09 16:24 henry Assigned To => henry