|
[Sponsors] |
December 12, 2007, 15:33 |
Hi,
I am trying to get mes
|
#1 |
Senior Member
Kevin Smith
Join Date: Mar 2009
Posts: 104
Rep Power: 17 |
Hi,
I am trying to get mesh motion to work on a hex cell grid. I had originally done the mesh with unstructured/tet cells and the motion worked great but was having problems with the results so I took the time to make a nice structured mesh. So after copying the newly converted hex mesh into the openfoam case and running, the solver fails after my moving boundary starts crossing into the mesh. I saw this same phenomena on Frank Bos' website - http://www.aero.lr.tudelft.nl/~frank/index.php?id=research/cfd/problems/2D_movin gmesh_wing - Is there anything I was supposed to change in the case dictionaries to make the mesh motion work with a hex mesh? Thanks. |
|
December 12, 2007, 17:14 |
Hi Kevin,
Could you please
|
#2 |
Senior Member
Frank Bos
Join Date: Mar 2009
Location: The Netherlands
Posts: 340
Rep Power: 18 |
Hi Kevin,
Could you please be more specific about your problem. 1) What error message do you get? 2) Is your case setup correctly? You don't get dictionary related error, right? 3) Did you run checkMesh? 4) What is your Courant number? You didn't give information about your case, but maybe your timestep is too large.... Regards, Frank
__________________
Frank Bos |
|
December 13, 2007, 08:20 |
And more, which OF version are
|
#3 |
Senior Member
Francesco Del Citto
Join Date: Mar 2009
Location: Zürich Area, Switzerland
Posts: 237
Rep Power: 18 |
And more, which OF version are you using?
What mesh motion algorithm (finite element or finite volume)? I moved very big hex/tet meshes without problems... Francesco |
|
December 13, 2007, 08:41 |
Me too, but large rotation is
|
#4 |
Senior Member
Frank Bos
Join Date: Mar 2009
Location: The Netherlands
Posts: 340
Rep Power: 18 |
Me too, but large rotation is still a problem for small boundary layer cells......The SBRstress fvMotionSolver seems to behave best for large displacements/rotations.
For different meshes I am still not able to rotate a wing (tip up 60 degrees combined with pitch up 45 degrees), but I got the feeling that there's still something to gain with modifying the SBRstress slightly and the diffusion coefficient... Regards, Frank
__________________
Frank Bos |
|
December 13, 2007, 10:57 |
Frank,
Here's some more i
|
#5 |
Senior Member
Kevin Smith
Join Date: Mar 2009
Posts: 104
Rep Power: 17 |
Frank,
Here's some more info about my case - 1) Getting a floating point exception error 2) As far as I know, the case is setup correctly, no dictionary errors 3) checkMesh , ok this one fails, thought I had run this, looks like I have a problem here.. 4) I wasn't using adjustable time steps because the Co number seemed to either explode, or implode (approaching zero) I think that is the crux of it, mainly having problems with time steps regardless of the motion. I went ahead and made a finer tet mesh and ran it with a fixed time step of 5e-05 and the motion works fine and it doesn't crash, but the results are obviously very wrong - getting turbulent regions propogating upstream (case is a 2D object in uniform flow field). Basically as soon as the simulation starts, I see ripples over the entire flow field start to develop and they continue to get more turbulent until I get very ugly results. I am using the 1.4.1-dev version for this with the finite volume motion algorithm - here's the content of dynamicMeshDict (wall-4 is the moving boundary) - dynamicFvMesh dynamicMotionSolverFvMesh; twoDMotion yes; solver laplaceFaceDecomposition; diffusivity quadratic patchEnhanced; frozenDiffusion off; distancePatches ( wall-4 ); I am still pretty new to openFoam and CFD in general so I really appreciate any help. I will rerun my fine tet mesh case with an adjustable time step and report what I get. Thanks, Kevin |
|
December 13, 2007, 13:58 |
After running the fine unstruc
|
#6 |
Senior Member
Kevin Smith
Join Date: Mar 2009
Posts: 104
Rep Power: 17 |
After running the fine unstructured mesh again with a Courant number of 0.3, the results turn out much better, not as much ripples; I will reduce the Co further and see what happens..
Well it sounds like if I had created a valid hex mesh and used an adjustable time step all should be well - which I still want to do to capture the wake region in more detail and get a more efficient run overall. Kevin |
|
December 13, 2007, 14:37 |
Kevin, just as an FYI, I would
|
#7 |
Senior Member
Srinath Madhavan (a.k.a pUl|)
Join Date: Mar 2009
Location: Edmonton, AB, Canada
Posts: 703
Rep Power: 21 |
Kevin, just as an FYI, I would like to point out that Hrv has shown the effect of high Courant numbers in his thesis. You may want to check it out[1]. The reason I'm pointing this out is because I used to blindly assume that maintaining a Co of 0.98 was sufficient as it was below the stability criterion (unity). It turns out however that temporal accuracy (not just stability) depends quite strongly on Co. These days I never exceed a Co of 0.4. I try to keep it around 0.2 to 0.3 and things work quite well for me.
Also, I think it would be better to maintain a cell peclet number (which is kind of a Reynolds number but based on the local grid size as opposed to the characteristic length scale of the problem) of 1 to 1.5 in regions where strong gradients of velocity/pressure are expected, especially when using the linear [central differencing] scheme. References: [1] http://powerlab.fsb.hr/ped/kturbo/Op...jeJasakPhD.pdf |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Mesh motion independent mesh regions | philippose | OpenFOAM Running, Solving & CFD | 12 | August 5, 2008 16:16 |
Oscillatory mesh motion setup mesh flux ERROR | jaswi | OpenFOAM Running, Solving & CFD | 5 | August 23, 2007 04:41 |
Refining Mesh using Tets and Prisms | Help Please | CFX | 11 | March 31, 2006 12:39 |
tets vs. hex mesh | Simon | Main CFD Forum | 6 | October 6, 2003 07:24 |
Adding cells during mesh motion | Serkan Cetin | Siemens | 1 | December 23, 2002 03:22 |