[Tom Lauriks]

Hi Foamers,

I'm using openfoam v6 (on ubuntu).

I modified the LES channel395 tutorial, so that it is convenient for me, but still retaining Re_tau=395.

I use a no slip condition for the velocity at the walls. Upon decomposition, the no slip BC is still present in the U files. For example, at time step 1388, in the processor0 dir, in the U file (at line 33116) can be found:

boundaryField
{
    bottomWall
    {
        type            noSlip;
     }

I extract the average velocity at the walls with a function object, see for example the FO specs for the bottom wall:

planeBottom1
    {
        type            surfaceFieldValue;
        functionObjectLibs ("libfieldFunctionObjects.so");
        enabled         true;
        ...
        regionType          sampledSurface;
        name      dummy;

        sampledSurfaceDict
        {
             type plane;
             interpolate true;
             planeType       pointAndNormal;
             pointAndNormalDict
             {
                  basePoint       (0 0.0 0);
                  normalVector    (0 1 0);
             }
        }
        operation       areaAverage;
        fields
        (
            U
        );
    }

This results in an average velocity at the wall of the order of 1e-21 m/s.


However, when I extract the velocity from the bottom wall with paraview, and average its magnitude across the bottom wall plane, the result is is 0.003 m/s.


Anyone any ideas on what's causing this discrepancy?


Since I'm having a lot of trouble simulating this case, it would be very helpful to solve this problem, since this would eliminate this as the cause of my problems. At the moment, I'm comparing the results to the Moser DNS data. The problems that I have are that my wall shear stress is too high and that my turbulence intensities are too low.

[sbaffini]

Not an OF expert but, might it be that what you see in Paraview actually is the value in the first cell near the wall?

Said otherwise, are you sure that you are exporting (and viewing) values at the wall as separate from those in the cells?

[Tom Lauriks]

Hi Paolo, thanks for your reply.


I found the cause of my problem. In the tutorial, for the initialized solution, the BC for the velocity at the walls is:

        type            fixedValue;
        value           uniform ( 0 0 0 );

while it is in the 0.orig file:

        type            noSlip;

Since I initialized the solution myself, I copied the latter BC to the 0 file before starting. This is causing the behavior in paraview. I changed my BC at the wall to uniform 0 and the behavior is gone.


I'm not sure whether this has any effect in the values that openfoam sees during runtime, because my result is the same as before. It could hence be that it is only paraview, that interprets the noSlip BC incorrectly.


Besides, I'm very sure that the values that paraview displays in the noSlip case are incorrect. To my understanding, the first cells (their centroid) next to the wall will have a non-zero velocity in case of a no slip. But it are the faces of these cells on the wall, that indeed contain the BC of zero velocity. I'm very sure that I was looking at these faces in paraview (I checked their coordinates) and that they had a non-zero velocity with the noSlip BC.

[Gerry Kan]

Dear Tom:

When you are looking at the solution of the 3D flow field in Paraview, it is in fact the solution of the first interior node, not the solution at the wall. This is why it is showing a small non-zero value.

For completeness, in addition to the 3D data, you will also need to load the corresponding boundary, which should show zero velocity if a no-slip boundary has been applied to the boundary in question.

Hope that helps, Gerry.

[Tom Lauriks]

Thanks for your reply. This clarifies things further, indeed leaving open the possibility that paraview and openfoam view the noSlip BC differently.


I would however like to emphasize that the velocty at the wall when using noSlip in paraview is not a small value. It is approx. 0.003 m/s. My bulk velocity is 0.21. The velocity at the wall is hence 1% of the bulk velocity, which does not seem small to me. The velocity at the wall that I extracted directly from the openfoam simulation is 1e-21 m/s. There is a large discrepancy between these values.

As mentioned above, I replaced the noSlip with uniform (0 0 0) as BC at my walls. As a result, paraview now also sees my velocity at the wall as 0. Since the behavior of my flow seemingly did not change as a result of this (I did not very thoroughly analyze the results yet), it seems to be the case that this is a bug only in paraview, not in openfoam.

[AtoHM]

I came across the same issue some time ago. As the values shown there are either the first node values or some interpolation, its value ("small" or "not small") should be depending on your grid spacing.

[Tom Lauriks]

Thanks all for replying.

For future reference, for people who might stumble upon the same problem, at the moment it seems that I solved the problem in my channel flow. The results were in fact correct, but I normalized with an incorrect u_tau. The reason for this, was an inconsistent use of symbols in the course notes that I'm following. After renormalizing with a correctly calculated u_tau, my results compare much better to the Moser et al. (1999) DNS data for Re_tau approx 400.

I would like to repeat that I'm pretty sure that it was only paraview, that incorrectly displayed the no slip boundary condition. Hence, I consider this as a (small) bug in paraview.

[sbaffini]

Not to bother you again, but this is indeed not a bug in Paraview, at least not in the common sense of a general Paraview bug. There are few aspects worth mentioning to clarify this, also for anyone coming here with the same problem in the future.

Paraview is not, actually, the visualizer coming with OpenFOAM, it is basically a showroom for vtk capabilities which, by the very vtk nature, happens to be a general purpose visualizer in itself and has several readers for several mesh and solution formats, including OpenFOAM.

Paraview can handle different topological entities and, among these, there are both volume and surface grids. To both of them you can attach different scalar, vector and tensor fields. In particular you can attach them to the grid nodes, the cell centers or both.

Note that this is not serendipitous or accidental. When someone (i.e., a software developer) exports a file to be read in paraview, he has to make these explicit choices.

Now, from my experience, what happens in the vast majority of cases is that someone who is coding the export of a finite volume code will, very likely, just export the volume grid and the solution in the cell centers (which is reasonable, because that is your actual and only solution). In this case, the volume grid will still have the nodes at a wall, of course, but the solution will be defined in the cells adjacent to the wall, not at the wall itself. In this case, Paraview can't do miracles and does the only reasonable thing that everyone else does as well, puts the cell center solution also on the adjacent faces on the boundary (i.e., 0 order extrapolation).

If you now note that OpenFOAM is not different, that the actual solution it writes is for cell centers only, you see that, at least in general, the Paraview behavior you observed is consistent with the previous reasoning.

However, as said before, Paraview has different readers for different mesh and solution formats, among which there is one for OpenFOAM. I don't know how this reader works but, from your expectation, I presume it has some mechanism by which it reads the boundary conditions as well and, with this specific additional information, also produces the solution at the boundaries.

So, if a bug is there, it probably is in how this OF reader in Paraview actually handles the bc entries in the OF files. Still, in my opinion, it is reasonable that it can actually handle only fixed values boundaries, as they are the only ones actually providing an explicit information on the values to be used. Everything else would be just speculation and makes much more sense, in these cases, to revert to the default behavior (which, by chance, automagically handles realistically a lot of other boundary conditions like inflows and outlfows).

If this is what really happens, I obviously agree that it should be written somewhere. But, again, it doesn't seem a bug to me.

Note that the same thing happens, for example, in Fluent. The standard solution that is visualized is the one in the cell centers. You need to explicitly ask the one in the nodes, and in this case Fluent uses additional information to produce it. But in Fluent like in Paraview, that is always a post-processing step, which might not take into account all the details of the solver (this starts to become relevant if your wall is actually a CHT boundary and you need the temperature on it)

[Tom Lauriks]

Paolo, I just reread your former question "might it be that what you see in Paraview actually is the value in the first cell near the wall?"

I would like to clearly summarize what I think I saw. (I say think, because I tried many many things, and I'm not 100% sure that what I remember is correct.)

In my experience, paraview correctly displays openfoam results at the boundaries, as the values that were set in the BC. Hence, at the BCs, it displays the values at the nodes on the boundaries. I'm pretty sure that this is what I saw in several models that I made. For instance, when I make a model with a BC at the inlet with a certain velocity profile, then in the first iterations in steady RANS, paraview correctly displays this profile at the inlet, while in the cells immediately besides the inlet, the velocity still has the initial condition value.

Now, in my channel flow, when I set the BC at the wall as a velocity of 0, then I correctly see a zero velocity on my wall in paraview. When I use noSlip at that same wall, in paraview the velocity on my wall was not zero, while in openfoam it was zero. I know this for sure, because I extracted the velocity there from openfoam.

Whether or not a bug, I would at least say that this behavior is unexpected and confusing.

[sbaffini]

Just to be clear, I didn't want to say that you were wrong. Actually, I'm pretty sure that this is exactly what happened to you. I just wanted to say that, sometimes, some behaviors are not accidental nor bugs, and I think this is one of those cases.

That is, I think Paraview can't reasonably determine values at boundary faces when your OF bc is not clear about that. fixedValues seems pretty explicit to me, noSlip is not (noSlip with respect to what?).

Not an expert of either Paraview or OF (or the Paraview OF reader) but, confusion for that specific bc (noSlip instead of fixedValues) seems legit to me.

If this is the case, the fact that this should be written somewhere, however, seems obvious to me as well. Unfortunately, it seems it isn't.