CFD Online Discussion Forums

CFD Online Discussion Forums (
-   OpenFOAM Bugs (
-   -   wallDist error in OF-1.5.x (

elisabet August 19, 2010 11:27

wallDist error in OF-1.5.x
3 Attachment(s)
Hi everybody,

I've experienced some problems with the wallDist function for the case shown below. It consists on two banana shaped channels (inlet at left and outlet at right) and the U-bend that connects both channels. I need to evaluate the wall distance from the patch market in black (at the left of the figure)

Attachment 4458

The wallDist function seems to return the good wall distance for the inlet channel but for the outlet channel it somehow follows what would be a fluid trajectory:

Attachment 4459

In order to obtain the right wall distance I've had to create a new geometry without the separation of both channels and, over it, apply the wallDist function. Afterwards, interpolate the result to the real geometry:

Attachment 4460

In my case, as I needed the wall distance as a pre-processor and not during the simulation, the above mentioned solution was good enough (despite not elegant at all...).

I guess the solution is not straightforward but for those who like maths challenges... here you are!



mattijs August 19, 2010 12:06

wallDist calculates the distance to any 'wall' patches. Where are your walls?

Can you post/send the mesh?


elisabet August 19, 2010 12:41

Dear Matiijs,

For the pre-processor I modified the boundary file in order to have one unique wall type boundary condition: the one that I want as a reference for the wallDist function (shown in black in the first figure).

I'll send you the mesh in a private mail.


mattijs August 20, 2010 06:11

The wall distance is used in turbulence models to determine the effect of the wall so the current behaviour seems to be correct - it is the shortest path through fluid to the wall - it does not 'jump' gaps. If you want to change the behaviour you'll have to change finiteVolume/fvMesh/wallDist to do the calculation yourself.

elisabet August 20, 2010 16:45

3 Attachment(s)
Yes, I first thought this, but when I tried to define the inlet as the 'wall' boundary and find the wall distance, wallDist function jumped the gap.

See for instance the U-shaped channel defined by Attachment 4473. When the bottom is defined as the unique 'wall', the output of wallDist is: Attachment 4471

However, when the inlet (left and bottom boundary) is the unique 'wall', the output is:
Attachment 4472

hence, in this case, it jumps the gap!

mattijs August 23, 2010 16:14

1 Attachment(s)
Hi Elisabet,

you are indeed right - it does jump the gap. The information travels on the mesh but then the distance is calculated 'as the crow flies'.

Attached an interesting hack in the form of replacements for wallDist.C, patchWave.[CH] and wallPoint*[CH]. It calculates the cumulative distance through the mesh which I think is what you want for your case. It also reads the wallDistance if it is already there so you can calculate your own as a preprocessing step.


elisabet August 27, 2010 16:48

Dear Mattijs,

Sorry for the delay, but I've been really busy these days....

I've saved your new files in the src directory and run Allwmake. There are some problems related with the usage of 'distSqr' in:

1. wallPointDataI.H: there are no arguments to ‘distSqr’ that depend on a template parameter, so a declaration of ‘distSqr’ must be available

2. wallPointYPlusI.H: ‘distSqr’ was not declared in this scope

3. inverseFaceDistanceDiffusivity.C: ‘const class Foam::wallPoint’ has no member named ‘distSqr’

4. patchDataWave.C: ‘const class Foam::wallPointData<Foam::Vector<double> >’ has no member named ‘distSqr’

5. wallPointDataI.H: ‘distSqr’ was not declared in this scope

Any suggestions?


mattijs August 30, 2010 11:59

My fault - tested it just with a copy of a solver - they will not be drop-in replacements. Just copy your favourite solver and add the files (and add wallPoint.C, patchWave.C, wallDist.C to the Make/files).

elisabet September 7, 2010 10:56

Hi Mattijs,

I've arrived today from real holidays (those without any available PC), so probably I'm not reaaly concentrated today and I missed something.

I've saved all your files (.C and .H) in my application folder. In order to make it compile, I've changed the line 74 in wallDist.C:


labelHashSet wallPatchIDs(getPatchIDs<wallPolyPatch>());

labelHashSet wallPatchIDs(getPatchIDs(wallPolyPatch::typeName));
but it still provides the wrong result when I call the function

what am I missing?


mattijs September 7, 2010 11:20

1 Attachment(s)
Attached my little test program (a stripped down yPlusRas) which just calculates and writes wallDist. It compiles fine under 1.7.x, probably needs some small changes for 1.5.x.

elisabet September 8, 2010 04:13

Ok, again the same results but I've realized that, based on the geometry I attached some days before:

1. If 'inlet' is the unique patch: your dumpWallDist works perfectly

2. If the 'refWall' is the unique patch: keeps giving the same result as before

so.... almost you get it!


HagenC March 27, 2017 04:24

sorry very basic question: How do I access the wallDist value?
For the k-Omega SST model ywall is calculated, but where is it saved, how can I output these values to check their accuracy?

elisabet March 30, 2017 09:07

Hi Hagen,
It's quite a long time since I last used this function, I'm not sure about the possibility of calling it from controlDict file. I suggest you to look into the solvers or utilities in your OF version and look how it is called (grep wallDist -r .). Then, call it in the same way in your own utility/solver.

An alternative that I've just discovered is the use of the Test-wallDist utility (complied in applications/tests/wallDist). Once compiled, just go to your case folder, modify your fvSchemes as hereafter indicated, and run Test-wallDist. As a result, two new files will appear in your 0 folder (nWall and yWall, being the normal direction to the wall and the distance, respectively)


method meshWave;
nRequired false;
Good luck!


HagenC April 27, 2017 02:39

Thank you very much!
Test-wallDist is what I was searching for.
Now I see that advection diffusion methods sometimes struggles to solve for my complex geometry. It seems like meshwave is more robust on that.
Thank you again.

All times are GMT -4. The time now is 21:40.