[Gerry Kan]

Howdy folks:

I am wondering if anybody has run into similar behavior before.

I am running a variant of rhoPimpleFoam (rhoReactingFoam to be exact, but without the reactions). For testing I have a box setup using blockMesh, where T, p, and U are prescribed as fixedValue BCs on the top and bottom walls, while the side walls are either cyclic (with U) or zeroGradient, as with the remaining scalars.

For the moment, U = 0 at said top and bottom boundaries. If T and p are identical at the boundaries (i.e., trivial solution), I get what I expected. However, as soon as introduce a pressure or temperature difference, I started to notice that UZ profile zig-zags along the z-axis. The amplitude of this zig-zag are more pronounced near the top and bottom walls, and as a whole the mean value (i.e., averaging across the zig-zags) gives me something plausible. Similar zig-zag behavior, although less prominent, can also be seen in All other scalars (i.e., U, T) have otherwise smooth profile.

The following is my PIMPLE settings. Changing the settings, particularly nOuterCorrectors and nCorrectors, do not alter zig-zag behavior above, which led me to believe that this might not be an issue of pressure-momentum coupling (i.e., checkerboard):

PIMPLE  {

    momentumPredictor        no;
    nOuterCorrectors        120;    // PIMPLE loop
    nCorrectors               5;    // momentum-pressure coupling
    nNonOrthogonalCorrectors  0;

    residualControl  {
        U  1.0e-6;
        p  1.0e-6;
        h  1.0e-6;
        "(k|epsilon|Yi)"  1.0e-6;
    }

    outerCorrectorResidualControl  {
        "(U|p)"  {
            tolerance 1.0e-6;
            relTol    0.0;
        }
    }
}

My spidey sense tells me it might be numerical oscillation resulting from the change in boundary conditions. However, changing flux limiter (i.e., limitedLinear, Minmod, etc) do not affect this behavior.

The only remedy I can think of right now is to introduce numerical damping terms in UEqn.H and pEqn.H and hope that this will attenuate the oscillation. Before I do that, however, I would like to know if there are any other options that could be implemented without introducing code change.

Thanks in advance, Gerry.

[jherb]

How have you set the boundaries? Normally, you want an "inlet" with fixedValue for U and zeroGradient for p (or does this solver use p_rgh, then its fixedFluxPressure for p_rgh) and vice verse for the "outlet".


Also, if you use nOuterCorrectors, then you normally also use under-relaxation.

[Gerry Kan]

Dear Joachim:


Thanks for your response. To be honest I have been doing a lot of OF code changes for the last few weeks, that I forgot it could be a BC issue. Thanks for your reminder.


Based on your advice, I changed my top pressure boundary from fixedValue to zeroGradient and saw improvement in the near-wall oscillation on both Uz and p, although it did not go away completely. So I think this is the right direction, and I am glad that it is simpler than I originally thought.


As for the system, it is not a classic "inlet-outlet-wall" type of setup, but rather it is some kind of open space. So the bottom is the ground, where fixedValue BCs are prescribed for p, T, and U. The top is "free stream", prior to your suggestion, all of p,T, and U BCs are of the fixedValue variety. The remaining walls (on the side) are marked as cyclic.


What I am uncertain about, is whether I should use static or total pressure to prescribe the bottom wall pressure. In a compressible flow setting, it is standard (at least for me) to extend the inlet to a quiescent reservoir and prescribe a total pressure BC at the extended inlet. Here I don't have to option to do so. What could be a good alternative?


Thanks in advance, Gerry.

[jherb]

Have you tried fixedValue for pressure and zeroGradient for U?