CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Post-Processing

NearWallFields functionObject too slow for large meshes

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree1Likes
  • 1 Post By Yann

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   February 21, 2023, 21:00
Default NearWallFields functionObject too slow for large meshes
  #1
New Member
 
pisharoti05
Join Date: Feb 2020
Posts: 10
Rep Power: 6
nainavinod is on a distinguished road
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:

Code:
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):

Quote:
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 is offline   Reply With Quote

Old   February 22, 2023, 16:19
Default Update on Implementation of NearWallRegions for Overset Meshes
  #2
New Member
 
pisharoti05
Join Date: Feb 2020
Posts: 10
Rep Power: 6
nainavinod is on a distinguished road
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):
Quote:
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:
Quote:
--> 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:
Code:
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:
Quote:
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?
nainavinod is offline   Reply With Quote

Old   February 23, 2023, 13:55
Default
  #3
Senior Member
 
Yann
Join Date: Apr 2012
Location: France
Posts: 1,140
Rep Power: 27
Yann will become famous soon enough
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:

Code:
--> 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:

Code:
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 likes this.
Yann is offline   Reply With Quote

Old   February 23, 2023, 14:16
Default
  #4
New Member
 
pisharoti05
Join Date: Feb 2020
Posts: 10
Rep Power: 6
nainavinod is on a distinguished road
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.
nainavinod is offline   Reply With Quote

Reply

Tags
nearwallfields, overset mesh, postprocess function, postprocessing, sampling function object

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Preserve meshes in Fluent parametric run hwerner2014 FLUENT 2 February 28, 2022 16:29
Cannot find functionObject file residuals vava10 OpenFOAM Pre-Processing 2 November 14, 2020 12:21
nearWallFields error in postProcessing wilove OpenFOAM Post-Processing 4 April 11, 2019 03:37
Fluent running increadibly slow MayTheFlowBeWithYou FLUENT 12 May 22, 2018 02:04
[Salome] IdeasUnvToFoam is very slow when converting meshes armitatz OpenFOAM Meshing & Mesh Conversion 1 May 2, 2017 12:48


All times are GMT -4. The time now is 23:33.