View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000968||OpenFOAM||[All Projects] Bug||public||2013-08-16 22:45||2015-02-05 23:01|
|Platform||Intel x86-64||OS||Red Hat Enterprise Linux Serve||OS Version||6.3 (Santiago)|
|Fixed in Version|
|Summary||0000968: Wall Distance Calculation Does Not Calculate True Distance|
|Description||Dear 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.
Philippe Spalart, Boeing
Matt Churchfield, NREL
Chris Rumsey, NASA
Daniel Wei, Notre Dame
|Steps To Reproduce||Compile 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.|
|Tags||No tags attached.|
wallDistFiles.tar.gz (33,747 bytes)
|We currently have no switchable wall distance calculation. Once we have this we can plug in an exact version (with its own limitations).|
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.
||For future reference, this is related to this report: http://www.openfoam.org/mantisbt/view.php?id=826|
||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?|
|(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.|
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.
Last edited: 2015-01-06 07:47
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: http://turbmodels.larc.nasa.gov/bump_sa.html).
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 Boeing.com
||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.|
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
||File Added: wallDistFiles.tar.gz|
||Note Added: 0002425|
||Note Added: 0002436|
|2014-12-29 14:54||wyldckat||Note Added: 0003396|
|2015-01-05 13:03||henry||Note Added: 0003509|
||Note Added: 0003510|
|2015-01-05 14:43||henry||Note Added: 0003511|
||Note Added: 0003512|
||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|