[Tellur]

Dear all,

First of all thank you for taking the time to read my post.

I have been working the past few days on developing OF simulations of rotating geometries, a difficult task to get into but rewarding as time passes.

I have managed to go through the meshing and case preparation stages with what I am guessing to be correct options. Most of my current simulations are simple geometries, imagine a square room, with a bladed fan at the center of the ceiling.

Since there is a rotating region (the 3D cylindrical region encompassing the blades of the fan) and a static region (essentially everything else in the model) I am using the MRF method. The fan blades and body are meshed into the room with SHM. I use topoSet to extract the cells in the fan region and create the cellzone to feed to MRF.

All that went ok but I am having some issues with my results. There appear to be high bounded values for (mainly) k and epsilon.

For k the region of high values is concentrated around the rotating region, outside the boundaries of the fan.

For the epsilon values, the values are actually concentrated in a really small area where the body and blades touch.

I was wondering if anyone else had issues like these in fan simulations. At the moment I am not using the nonrotatingpatches option in the MRF dict. Could it be that the part of the "body" geometry within the fan region should be added to the nonrotatingpatches, since it would be in reality a static geometry. Is it a matter of fvSchemes perhaps?

This is a steady-state case and I am using quite standard boundary conditions and schemes with:

U: fixedValue for the window of the room, inletOutlet for the door (outlet)
p: zeroGradient (window), fixedValue uniform 0 (outlet)
k, epsilon: fixedValue (inlet), inletOutlet (outlet)

I am using realizableKe, based on a small research for rotating geometries. My schemes were selected based on the very low non-orthogonality of the mesh.

An additional question I have, if anyone has experience with this, would be how to design such a model without the need for a separate inlet and outlet. Is it possible to design a room with a window that acts as both? Obviously, doing that only with a fixedValue would not work due to violation of continuity. Would an inletOutlet condition work for this? If anyone has any thoughts/experience on this I would appreciate it.

MRF properties dict:

MRF1
{
    type        MRFSource;
    selectionMode    cellZone;
    cellZone        FanRegion;
    active          yes;

    // Fixed patches (by default they 'move' with the MRF zone)
    nonRotatingPatches ();

    origin    (47.522577 -6.090035 2.324509);
    axis      (0 0 1);
    omega     19.05899543; //RPM 182
}

topoSet dict:

actions
(

    {
        name    FanRegion;
        type    cellSet;
        action  new;
        source  surfaceToCell;
        sourceInfo
        {
        file            "IndividualSTLs/C2_LivingRoom_FanRegion.stl";
        outsidePoints   ((46.23 -6.31 1.331));    
        includeCut      true;              
        includeInside   true;              
        includeOutside  false;              
    nearDistance    -1;
    curvature    0.9;                                              
        }
    }

    {
        name    FanRegion;
        type    cellZoneSet;
        action  new;
        source  setToCellZone;
        sourceInfo
        {
            set FanRegion;
        option any;
        }
    }
);

fvSchemes:

ddtSchemes
{
    default             steadyState;
}

gradSchemes
{
    default         cellLimited leastSquares 1.0;
    grad(U)        cellLimited leastSquares 1.0;
}

divSchemes
{
   default none;
    div(phi,U)          bounded Gauss linearUpwind grad(U); //upwind;
    div(phi,epsilon)    bounded Gauss upwind; //upwind;
    div(phi,k)          bounded Gauss upwind; //upwind;
    div((nuEff*dev2(T(grad(U))))) Gauss linear;
}

laplacianSchemes
{
    default             Gauss linear limited 0.5;
}

interpolationSchemes
{
    default             linear limited;
}

snGradSchemes
{
    default             limited 0.5;
}

fluxRequired
{
    default             no;
    p            ;
}

The attached images show the areas where the issue arises. The values do appear normal in this case. However, other cases have values for epsilon around 1000.



Thank you so much in advance for any comments.

Kind regards,
theodore.