[elisabet]

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)

banana_shape.png

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:

banana_wallDist.png

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:

unifiedBanana_wallDist.png

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!

Regards,

Elisabet

[mattijs]

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

Can you post/send the mesh?

Mattijs

[elisabet]

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.


Elisabet

[mattijs]

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]

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 blockMeshDict.txt. When the bottom is defined as the unique 'wall', the output of wallDist is: bottom_wall.png

However, when the inlet (left and bottom boundary) is the unique 'wall', the output is:
inlet_wall.png

hence, in this case, it jumps the gap!

[mattijs]

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.

Mattijs

[elisabet]

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?

Elisabet

[mattijs]

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]

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:

old:

labelHashSet wallPatchIDs(getPatchIDs<wallPolyPatch>());

new:

labelHashSet wallPatchIDs(getPatchIDs(wallPolyPatch::typeName));

but it still provides the wrong result when I call the function

wallDist(mesh).y()

what am I missing?

elisabet

[mattijs]

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]

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!

elisabet

[HagenC]

Hi,
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?
Thanks.

[elisabet]

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)

wallDist
{
method meshWave;
nRequired false;
}

Good luck!

Elisabet

[HagenC]

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.