[nainavinod]

Hello Foamers,

I was looking for a function that helps me sample pressure, velocity and wall-shear stress around my moving wall so that I can calculate the boundary layer properties for multiple time instances. My case involves an overset simulation of a propeller with very fine resolution near the propeller surface for good boundary layer resolution.

I fortunately found the function: nearWallFields which gives me exactly what I am looking for. I copied the sub-dictionary from the tutorial case: $FOAM_TUTORIALS/incompressible/pisoFoam/RAS/cavity/system/FOs/FOnearWallFields and modified it for my case:

nearWallFields1
{
    // Mandatory entries
    type            nearWallFields;
    libs            (fieldFunctionObjects);
    fields
    (
        (U UNear)
        (p pNear)
    );
    patches         (Propeller);
    distance        1e-3;

    // Optional (inherited) entries
    log             true;
    timeStart       0.44998;
    timeEnd         0.457499;
    executeControl  timeStep;
    executeInterval 20;
    writeControl    timeStep;
    writeInterval   40;
}

However, when I started the simulation, the case just wouldn't go past the sampling part (part of the log file shown below):

Reading/calculating face velocity Uf

No MRF models present

No finite volume options present
Courant Number mean: 0.00347282116229 max: 315.403649129

Starting time loop

nearWallFields nearWallFields1: Sampling 1 fields

The simulation gets stuck after this point. I believe it is due to the size of my mesh (~65 million cells overall). To give you further context, my nPatchFaces = 600466 for the propeller patch.

Does the functionObject not scale well for larger meshes? Scaling down the mesh size is not an option for me. So any other suggestions to speed this post-processing utitlity would be greatly appreciated.

Regards,
Naina.

[nainavinod]

I have an update on the above issue. Looks like I need to specify the right region for the function object. Earlier, the solver was taking region0 as the default which is my background mesh (region0), while I want the operation to take place in my moving mesh region (region1).

So now my sub-dictionary input includes the following (bold portion indicating the new addition):

nearWallFields1
{
// Mandatory entries
type nearWallFields;
libs (fieldFunctionObjects);
fields
(
(U UNear)
(p pNear)
);
patches (Propeller);
distance 1e-3;

// Optional (inherited) entries
region region1;
log true;
timeStart 0.44998;
timeEnd 0.457499;
executeControl timeStep;
executeInterval 20;
writeControl timeStep;
writeInterval 40;
}

However, region1 is not identified and I get the following error:

--> FOAM Warning :

request for objectRegistry region1 from objectRegistry simpleRotor failed
available objects of type objectRegistry are
1(region0)

From const Type& Foam:bjectRegistry::lookupObject(const Foam::word&, bool) const [with Type = Foam:bjectRegistry]
in file /home/pnaina/OpenFOAM/OpenFOAM-v2006/src/OpenFOAM/lnInclude/objectRegistryTemplates.C at line 463.
From bool Foam::functionObjectList::read()
in file db/functionObjects/functionObjectList/functionObjectList.C at line 895

--> while loading function object 'nearWallFields1'

Now I understand this comes up because I have not explicitly defined what region1 is in my simulation. However, I am not entirely sure how to do that.

One thing I tried was to create cellZones for my two regions and then use splitMeshRegions to separate the regions. But that seems to be mixing up the zoneIDs for the background and moving mesh regions, which is something I do not want.

My topoSetDict looks like this:

actions
(
    {
        name    c0;
        type    cellSet;
        action  new;
        source  regionToCell;
        insidePoints
        (
            (0 0 -1)
        );
    }

    {
        name    c1;
        type    cellSet;
        action  new;
        source  cellToCell;
        set     c0;
    }

    {
        name    c1;
        type    cellSet;
        action  invert;
    }

    {
       name     BackgroundMesh;
       type     cellZoneSet;
       action   new;
       source   setToCellZone;
       set      c0;
    }

    {
       name     movingMesh;
       type     cellZoneSet;
       action   new;
       source   setToCellZone;
       set      c1;
    }

);

The splitMeshRegions output log looks like this:

Writing region per cell file (for manual decomposition) to "/fastscratch/pnaina/Overset1_RPM2000_Inflow5/constant/cellToRegion"

Writing region per cell as volScalarField to "/fastscratch/pnaina/Overset1_RPM2000_Inflow5/0/cellToRegion"

Region Cells
------ -----
0 42141036
1 25334521

Region Zone Name
------ ---- ----
0 1 BackgroundMesh
1 0 movingMesh

Sizes of interfaces between regions:

Interface Region Region Faces
--------- ------ ------ -----

Reading volScalarField: cellToRegion


Adding patches


Adding patches


Region 0
--------
Creating mesh for region 0 BackgroundMesh
Mapping fields
Mapping field cellToRegion
Deleting empty patches
Writing new mesh
Writing addressing to base mesh
Writing map pointRegionAddressing from region0 points back to base mesh.
Writing map faceRegionAddressing from region0 faces back to base mesh.
Writing map cellRegionAddressing from region0 cells back to base mesh.
Writing map boundaryRegionAddressing from region0 boundary back to base mesh.

Region 1
--------
Creating mesh for region 1 movingMesh
Writing dummy "movingMesh/fvSchemes"
Writing dummy "movingMesh/fvSolution"
Mapping fields
Mapping field cellToRegion
Deleting empty patches
Writing new mesh
Writing addressing to base mesh
Writing map pointRegionAddressing from region1 points back to base mesh.
Writing map faceRegionAddressing from region1 faces back to base mesh.
Writing map cellRegionAddressing from region1 cells back to base mesh.
Writing map boundaryRegionAddressing from region1 boundary back to base mesh.
End

So my new question is: Is there a better way of defining the region for NearWallFields and how?

[Yann]

Hello Naina,

I never used the nearWallFields function object on overset cases, so I do not know how the function behaves with overset meshes.

I don't think you can use the region parameter in your case, because this is initially meant to be used with multi-region cases where each region as its own mesh located in a different directory. This is how chtMultiRegionFoam works.

The mesh structure on overset cases is different: there is one single polyMesh directory containing all mesh data and the overlapping meshes are identified by their zoneID value.

Basically, you only have one region in your case (region0) and this is what OpenFOAM tells you when you try to define another region:

--> FOAM Warning :

request for objectRegistry region1 from objectRegistry simpleRotor failed
available objects of type objectRegistry are
1(region0)

splitMeshRegions will not help you, because your solver will not be able to work with splitted meshes.

Since this is not possible to select a cellZone when using nearWallFields, a trick could be to use a first function to filter the data, and then use the filtered data as an input in nearWallFields.

This is only an idea, but the expressions function object seems to have a fieldMask functionality which might be used to retrieve data based on their zoneID.

Another idea, maybe simpler, would be to use the volFieldValue function object, something like this:

UMovingMesh
{
    type            volFieldValue;
    libs            (fieldFunctionObjects);

    fields          (U);
    operation       none;
    regionType      cellZone;
    name	    movingMesh;
	
    writeFields     true;
}

Since there is a writeFields option, I think it's possible to write the result of this function as a new variable that you can use in nearWallFields.
Please note I have no idea if this would do the job, as I never used it myself, but hopefully it can give you some leads to find a solution.

Regards,
Yann

[nainavinod]

Hello Yann!

Thank you very much for the suggestions. I am actually trying out the volFields option. However, the issue currently is that I am using OF-v2006 and when I implement the functionObject, it returns an empty field. This issue was also discussed in the thread here:
Sample a volume field

So for now, I am updating my OF version to try that option out. Will post an update on the thread once I get it working. T

Thanks again. Really appreciate your help.

Regards,
Naina.