[SGWANG]

Hi guys,

I am struggling in a simulation of a rotating propeller using an overset mesh of OF1812. After checking the hole cutting results, I find that the acceptor (interpolated) cells in the background mesh are so close to the propeller surface that may cause some interpolation errors because of the large gap of local gird size between background and overset region.

I tried both inverseDistance and cellVolumeWeight for the oversetInterpolation. the results were different but still close to the solid surface.

So are there some methods in OpenFOAM that could move the acceptor cells to the outside a little far away from the propeller surface (as pictures show below)?

Thank you in advance...

[Swift]

Hi SGWANG,

Its hard to make out what you are showing in your images. However, I can recommend that you read through this link for tips with meshing when using overset. Its applicable to openfoam as well.

Notably, on slide 17:

Keep cell sizes similar between regions at the interface
– Interpolation error should be in same order as discretization error for
convective and diffusive flux
– Coarser mesh determines error level
Minimum of 4 cell layers between bodies and overset boundaries
– Therefore 8 cells between wall boundaries in multiple overlapping regions

Slide 18 may also be useful.

Is there any reason that you are not using openfoam's moving method? It seems that this would also work. Check the propeller tutorial, for example. This would avoid the difficulty that you are experiencing.
Also, check later versions of openfoam (1906), as many improvements have been added to overset.

Thomas

Regards,
Thomas

[SGWANG]

Hello, Thomas,

Thank you so much for your reply.

What I am trying to do is the tip you quoted.

Keep cell sizes similar between regions at the interface
– Interpolation error should be in same order as discretization error for

As shown in the newly added picture (Hadzic, 2005 used in star c), after hole cutting, an overlapping region is generated. The outline (C0) of overlapping region is the overset boundaries we specified, while the inner line (dashed) is selected automatically by the program.
I want to know if there are some methods in OpenFoam to set the dashed line a little far away from the body surface.

Capture.PNG

In order to capture the features of the propeller, grids should be fine enough near the solid surface in the overset mesh, resulting in a huge gap of local grid size between background and overset mesh. Now, the selected interpolated cells (dashed line) is too close to the body surface. Since the local grid size is fixed, if I want to reduce the interpolation error, the only way is to make some other cells far away from the propeller surface be marked as interpolated cells...

Is there any reason that you are not using openfoam's moving method? It seems that this would also work. Check the propeller tutorial, for example. This would avoid the difficulty that you are experiencing. Also, check later versions of openfoam (1906), as many improvements have been added to overset.

I just want to do a comparative study of these body-motion methods in Openfoam. I have already done the simulation using AMI as the propeller tutorial does... Maybe I have to try the latest version...

[Swift]

Hi,

I'm still struggling to understand what you have done.

Is the background mesh around the propeller approximately the same size as the overset mesh? From the first images that you sent, it is not clear if this is the case or not. I think if the mesh sizes are similar, the acceptor cells that you want to configure would move further away from your surfaces.

I know I had to do this to get good results.

Thomas

[mAlletto]

I think the problem is that the domain size of the mesh around the propeller ist too small. The cells used to interpolate at usually the one adjacent the boundary with type overseer.

[SGWANG]

Thank you so much~

[mAlletto]

It means the interpolated cells moved away from the propeller? Can you just post a few pictures of the current solution?

[SGWANG]

Sorry for the late reply.

I tried to enlarge the domain size and mesh with a similar local size for background and overset, it only worked with a minor change.

Besides, the option 'searchBoxDivisions' in oversetInterpolation can affect the interpolated cells searched near the solid surface.

oversetInterpolation
{
    //method	      cellVolumeWeight;
    method          inverseDistance;
    //method          leastSquares;

    // The inverseDistance method uses a 'voxel' like search structure.
    // Optionally specify the extent and number of divisions n.
    // Note that it will allocate an array of nx*ny*nz. If not specified:
    // - searchBox          : local mesh bounding box
    // - searchBoxDivisions : root (2D) or cube-root(3D) of number of cells
    searchBox           (-0.1 -0.175 -0.175) (0.55 0.175 0.175);
    searchBoxDivisions  (65 35 35);

    layerRelax 0.3; //control the number of interpolated cells
}

Now I am trying thsi with OpenFoam-v1906, I will post some results if there are sth different.

[courant_numero_uno]

Did you manage to solve this problem? I am having similar problems on a cylinder case.

[courant_numero_uno]

Here is an example from the tutorials (overSimpleDymFoam). It is an overset airfoil case.


The overset grid is nice airfoil grid from snappy. The background grid is very coarse. See attached screenshots. Note: red = hole, white = interpolated, blue = solved.



Why are the interpolated cells on the background grid so close to the airfoil? Why doesn't the solver decide to interpolate much farther from the surface? Surely interpolating such a huge cell difference affects the accuracy. Look at the screenshot for the trailing edge.


On the background grid, the solver seems to decide the interpolated cells based on the location of the wall, rather than the location of the overset patch. My question is this: shouldn't the interpolated cells for the background and overset grids be as close as possible?

[courant_numero_uno]

Here is a drawing of what I would expect the solver to do. Forgive the crude paint.

[louisgag]

Hi
@courant_numero_uno
@SGWANG
I'm trying to do the same, did you find a parameter to do so?

[louisgag]

I've ended up coding it, you can see the code for different overset interpolation methods here: https://develop.openfoam.com/Develop.../-/issues/2106

[Tianyz]

Originally Posted by louisgag

I've ended up coding it, you can see the code for different overset interpolation methods here: https://develop.openfoam.com/Develop.../-/issues/2106

Hi Louis,

Many thanks for your contribution, it's quite useful. I have a quick question, how can I understand the searchBoxDivisions entry inside of fvSchemes/oversetInterpolation, can we just leave it by default?

Best,
Tian

[louisgag]

there are a few ways you can write it but it consists of telling the search algorithm in how many slices you split your domain in x,y,z directions:


In 2D you leave z to 1, e.g.:

searchBoxDivisions  (100 100 1);

[Tianyz]

Originally Posted by louisgag

there are a few ways you can write it but it consists of telling the search algorithm in how many slices you split your domain in x,y,z directions:


In 2D you leave z to 1, e.g.:

searchBoxDivisions  (100 100 1);

Hi Louis,

Many thanks for your reply. So according to your message, searchBox defines the searching zone, which should better cover the whole overset domain; searchBoxDivisions define the slices, which means the mesh I set along the x and y axis for a domain. Am I right? I noticed that the case can run without these two entries, it will choose the whole computational domain by default, so can these two entries speed up the calculation to some extent?

Best,
Tian

[louisgag]

Hi Tian,




Two people recently contacted me by email with questions because they were not able to reproduce my scaling, I approcciate that you did it on the forum, it helps any others who might have the same issues.


Yes. What happens with searchBoxDivisions is that it determines the numbers of "subblocks" in your search domain. And yes, fewer is faster (you'll quickly run into a wall in 3D if you use for example 1000x1000x1000)


The size of the search domain is somewhat more complicated and I don't remember everything but I think it changes according to the overset method you use and it is determined based on the extend of both your overset components and the processors they find themselves in.


What my code (idea actually taken from Nicolas Edh) is that it also allows dividing the box using a subblock size and it thus optimizes this box given the maximum automatically determined search domain size, but you'll have to read the code to get exact information on this one...

[Tianyz]

Hi Louis,

I appreciate your explanation in detail. And I noticed that in the latest version, that is OpenFOAM-v2212,
they've already improved this issue by including a new entry inside the fvScheme file, which is similar to your work. An extra question I want to consult with you is about the parallel calculation. I employ a hierarchical method, and just did the simple configuration according to the tutorial from Wolfdynamics. Please check the details below:

numberOfSubdomains 4;
method hierarchical;
coeffs
{
n (2 2 1);
}

Now the case works well with fine mesh and turbulence models. But it's time-consuming, I'm not sure if the current method is suitable or not, and I noticed that your configuration about parallel has more coefficients and the results improved a lot. Since I'm not clear about this part, is it possible if you can provide more clues about how to speed up the calculation with overset mesh method?

[louisgag]

if you're only using 8 processors I guess you won't notice a difference.
For a 3D case (perhaps where the overset components do not cover the whole background mesh, no sure) I would assume a hierarchical decomp would already speedup things.. the goal here was to keep small processor search boxes.. I'm also not sure how this works with the new code and I've done this some time ago so I don't remember all the details!