[deepbandivadekar]

I have a very simple geometry and I have created it using blockMesh only. So there are two blocks: first is the horizontal duct while the second is another smaller duct merging with the first bigger duct at 90deg. See attached pictures for visualisation.

Now I want to define these two blocks as separate cellzones. e.g. say one of them as porous zone. How can I do that? (The related tutorials use SHM or FHM, I want to avoid that)

I also noticed that after running blockMesh, [sets] folder is created in polyMesh. Isn't that created when blockMesh can't use some the faces or points? The [sets] folder for me contains these exact two zones that I mentioned above!! I don't understand why?

1. Is there any way I can perhaps use these region0 and region1 ?

2. If not, is it a good idea to use something like

  splitMeshRegions -makeCellZones

[Tobi]

Hi,

in your particular case (I am not familiar with the capabilities of blockMesh) I would use setSets and use the sets in order to create a cellZones. Its easy and should be a 3 liner - if you do not have the sets, build a cellSet and based on that, you can create a cellZone.

[Antimony]

Hi,

Not sure how you created your blockMesh, but you can name each block as well. So instead of "region0" and "region1" you could have something like "bigBlock" and "smallBlock"

As Tobi has mentioned you can use setSets to create your cellZones. Alternatively, you can use topoSet and convert these sets (region0 & region1) into cellZones using setToCellZone (Ref: https://github.com/OpenFOAM/OpenFOAM...et/topoSetDict)

Hope this helps.

Cheers,
Antimony

[Bloerb]

This is how you can create cellZones with blockMesh

hex (0 1 2 3 4 5 6 7) nameOfCellZone  (1 2 3) simpleGrading (1 1 1)

[deepbandivadekar]

Whoa, alright. Thanks for your inputs guys. Let me try this out today and I'll update!

[deepbandivadekar]

OK. Update:

I did not try what Tobi and Antimony suggested as this seemed to work.

Originally Posted by Bloerb

This is how you can create cellZones with blockMesh

hex (0 1 2 3 4 5 6 7) nameOfCellZone  (1 2 3) simpleGrading (1 1 1)

It created the required zones in "cellZones" file.

However when I run the solver (porousSimpleFoam) am now getting "floating point exception (core dumped)" error. The log.porousSimpleFoam file has only this:

Starting time loop

Time = 1

GAMG:  Solving for p, Initial residual = 1, Final residual = 855359.7971, No Iterations 1000
time step continuity errors : sum local = 2261772.402, global = -549976.5525, cumulative = -549976.5525
smoothSolver:  Solving for epsilon, Initial residual = 0.9989955956, Final residual = 0.04815760269, No Iterations 16
smoothSolver:  Solving for k, Initial residual = 1, Final residual = 0.02483197907, No Iterations 2
ExecutionTime = 625 s  ClockTime = 649 s

Time = 2

1. The time step continuity error is a very big number. Could it be related to this error?
2. While defining the interface boundaries (for the two ducts), I had used mergePatchPairs to project the smaller surface onto the larger surface. "Type" for both of these was wall. Is that a wrong choice? I was a bit skeptical about this since considering my geometry only part of the bigger duct bottom is the real wall while the interface should allow flow.

I have attached my fvSolution and fvScheme files here for reference.

fvSchemes

FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    location    "system";
    object      fvSchemes;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

ddtSchemes
{
    default         steadyState;
}

gradSchemes
{
    default         Gauss linear;
}

divSchemes
{
    default         none;

    div(phi,U)      bounded Gauss upwind;
    div((nuEff*dev(T(grad(U))))) Gauss linear;
    div(phi,epsilon) bounded Gauss upwind;
    div(phi,k)      bounded Gauss upwind;
}

laplacianSchemes
{
    default          Gauss linear corrected;
}

interpolationSchemes
{
    default         linear;
}

snGradSchemes
{
    default         corrected;
}

fluxRequired
{
    default         no;
    p               ;
}

fvSolution

FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    location    "system";
    object      fvSolution;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

solvers
{
    p
    {
        solver          GAMG;
        tolerance       1e-08;
        relTol          0.05;
        smoother        GaussSeidel;
        cacheAgglomeration on;
        nCellsInCoarsestLevel 20;
        agglomerator    faceAreaPair;
        mergeLevels     1;
    }

    "(U|k|epsilon)"
    {
        solver          smoothSolver;
        smoother        symGaussSeidel;
        nSweeps         2;
        tolerance       1e-07;
        relTol          0.1;
    }
}

SIMPLE
{
    nUCorrectors    2;
    nNonOrthogonalCorrectors 0;
}

relaxationFactors
{
    fields
    {
        p               0.3;
    }
    equations
    {
        U               0.7;
        k               0.9;
        epsilon         0.9;
    }
}

[deepbandivadekar]

Alright. I found a work around. Although I do not know what is the reason for this.

I shifted the underrelaxation factor for U from equations to fields brackets. And this worked. Which brings up new question. I'm going to open a new thread to clarity about that.

Update: and the thread is here: Difference between "fields" and "equations" relaxation sub-directories in fvSolution

Thank you folks for your help.