|
[Sponsors] |
Hole cutting problem using overset of OF1812 |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
October 14, 2019, 05:39 |
Hole cutting problem using overset of OF1812
|
#1 |
New Member
Shuguang Wang
Join Date: Feb 2018
Posts: 13
Rep Power: 8 |
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... |
|
October 15, 2019, 05:52 |
|
#2 | |
Member
Thomas Sprich
Join Date: Mar 2015
Posts: 76
Rep Power: 11 |
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: Quote:
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 |
||
October 15, 2019, 08:33 |
|
#3 | ||
New Member
Shuguang Wang
Join Date: Feb 2018
Posts: 13
Rep Power: 8 |
Hello, Thomas,
Thank you so much for your reply. What I am trying to do is the tip you quoted. Quote:
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... Quote:
|
|||
October 16, 2019, 09:37 |
|
#4 |
Member
Thomas Sprich
Join Date: Mar 2015
Posts: 76
Rep Power: 11 |
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 |
|
October 16, 2019, 15:27 |
|
#5 |
Senior Member
Michael Alletto
Join Date: Jun 2018
Location: Bremen
Posts: 616
Rep Power: 16 |
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.
|
|
October 20, 2019, 04:09 |
|
#6 |
New Member
Shuguang Wang
Join Date: Feb 2018
Posts: 13
Rep Power: 8 |
Thank you so much~
|
|
October 20, 2019, 04:52 |
|
#7 |
Senior Member
Michael Alletto
Join Date: Jun 2018
Location: Bremen
Posts: 616
Rep Power: 16 |
It means the interpolated cells moved away from the propeller? Can you just post a few pictures of the current solution?
|
|
October 24, 2019, 08:52 |
|
#8 |
New Member
Shuguang Wang
Join Date: Feb 2018
Posts: 13
Rep Power: 8 |
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. Code:
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 } |
|
March 24, 2020, 09:22 |
|
#9 |
New Member
Join Date: Sep 2019
Posts: 17
Rep Power: 7 |
Did you manage to solve this problem? I am having similar problems on a cylinder case.
|
|
March 24, 2020, 09:40 |
|
#10 |
New Member
Join Date: Sep 2019
Posts: 17
Rep Power: 7 |
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? |
|
March 24, 2020, 09:46 |
|
#11 |
New Member
Join Date: Sep 2019
Posts: 17
Rep Power: 7 |
Here is a drawing of what I would expect the solver to do. Forgive the crude paint.
|
|
May 5, 2021, 12:16 |
|
#12 |
Senior Member
|
Hi
@courant_numero_uno @SGWANG I'm trying to do the same, did you find a parameter to do so? Last edited by louisgag; May 6, 2021 at 04:14. Reason: adding image |
|
June 11, 2021, 08:06 |
|
#13 |
Senior Member
|
I've ended up coding it, you can see the code for different overset interpolation methods here: https://develop.openfoam.com/Develop.../-/issues/2106
|
|
April 14, 2023, 10:49 |
|
#14 | |
New Member
Manchester
Join Date: Aug 2022
Posts: 27
Rep Power: 4 |
Quote:
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 |
||
April 20, 2023, 05:15 |
|
#15 |
Senior Member
|
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.: Code:
searchBoxDivisions (100 100 1); |
|
April 21, 2023, 16:25 |
|
#16 | |
New Member
Manchester
Join Date: Aug 2022
Posts: 27
Rep Power: 4 |
Quote:
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 |
||
April 24, 2023, 00:51 |
|
#17 |
Senior Member
|
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... |
|
April 24, 2023, 12:51 |
|
#18 |
New Member
Manchester
Join Date: Aug 2022
Posts: 27
Rep Power: 4 |
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? |
|
April 26, 2023, 04:52 |
|
#19 |
Senior Member
|
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! |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
FLUID THROUGH A HOLE (2D) interFoam | AmélieO | OpenFOAM Running, Solving & CFD | 0 | January 17, 2018 18:25 |
Overset mesh issiue | engineer_1993 | STAR-CCM+ | 3 | July 25, 2017 15:46 |
natural convection problem for a CHT problem | Se-Hee | CFX | 2 | June 10, 2007 07:29 |
Adiabatic and Rotating wall (Convection problem) | ParodDav | CFX | 5 | April 29, 2007 20:13 |
Periodic flow boundary condition problem | sudha | FLUENT | 3 | April 28, 2004 09:40 |