# Relationship between mesh size, increase in turbulent viscosity and non-convergence?

 User Name Remember Me Password
 Register Blogs Members List Search Today's Posts Mark Forums Read

 LinkBack Thread Tools Display Modes
 March 14, 2014, 12:29 Relationship between mesh size, increase in turbulent viscosity and non-convergence? #1 Member   Join Date: Mar 2014 Posts: 31 Rep Power: 3 I'm trying to model k-omega turbulence through a relatively simply fluid domain but Star-CCM+ doesn't seem to be cooperating. I'm modelling the flow around two buildings (50m high and 17m square) within a domain that is 1000x517x300m. TurbModel = k-omega Turb Intensity = 0.5 Turb Velocity Scale = 5m/s (It's a log-law inlet velocity profile but 5m/s is an average) Turb Viscosity = 0.1 I'm using a segregated solver for reasons which will become apparent in a minute. The mesh is trimmed with a surface wrapper and the base size is 4.5m. Wake refinement is applied anisotropically to both buildings with a reference size 25% of the base. Now, the Tke and Sdr residuals are fine. They seem to converge relatively quickly. However, the Continuity and X-Y-Z-Momentum residuals "flatline" after reducing by 2-3 orders of magnitude. To make matters worse, around 124 iterations, the turbulent viscosity is limited in _ cells and the number of affected cells increases with each iteration, with no signs of decreasing. What could be causing these problems? Is the mesh too coarse? The computational domain consists of ~3 million cells. The buildings themselves are just extrude cut cuboids, so nothing fancy there. Boundaries: Velocity Inlet, Pressure outlet, Wall for the ground and building surfaces, lateral and vertical boundaries are Symmetry... The reason the mesh is so coarse is because I was originally running the simulation on my local machine. I'm running it in batch now. However, will an increase in mesh cells solve my problem? Since I'm running it in batch I can also switch to a coupled solver? Would this make a difference? Apologies for the longwinded nature of my post... Many Thanks, Muzz

 March 19, 2014, 15:24 #2 Senior Member   Join Date: Nov 2010 Posts: 418 Rep Power: 8 That warning is usually related to incorrect turbulent boundary conditions. Looking at your values, 50% turbulent intensity is far, far too high. The input is in decimal, so if you were looking for 0.5%, you should enter 0.005.

March 20, 2014, 12:21
#3
Member

Join Date: Mar 2014
Posts: 31
Rep Power: 3
Quote:
 Originally Posted by me3840 That warning is usually related to incorrect turbulent boundary conditions. Looking at your values, 50% turbulent intensity is far, far too high. The input is in decimal, so if you were looking for 0.5%, you should enter 0.005.
I reduced the intensity to 0.005 and still received the same error. Curiously, when expressing the initial turbulence conditions as k-omega, the simulation begins with a high number of viscosity limited cells and approaches a constant value.

http://www.cfd-online.com/Tools/turbulence.php

I used that calculator for my values. I just don't see what the issue is here. Running it in bash mode, I can't run diagnostics on my mesh but given how simple my geometry is, a trimmed mesh shouldn't have too many discrepancies that would result in such large solution errors.

If you PM me your e-mail address, would you be able to have a look at the unmeshed .sim file? I know it's a big ask but I'm completely out of ideas here...

 March 20, 2014, 12:24 #4 Senior Member   Join Date: Nov 2010 Posts: 418 Rep Power: 8 I try to avoid specifying turbulence parameters directly with calculators like that, but I'd be happy to look at your sim file. However I will still post findings here so that others can see it.

 March 20, 2014, 12:55 #5 Member   Join Date: Mar 2014 Posts: 31 Rep Power: 3 Absolutely. Post away. I greatly appreciate it. I'll send that over now.

 March 20, 2014, 13:33 #6 Senior Member   Join Date: Nov 2010 Posts: 418 Rep Power: 8 So I don't know if this will solve your problem, but I have some questions on your mesh: 1. Why is the wrapper on? Your geometry is clean and closed to begin with, there's no reason to use it that I can see. 2. Why tets? The trimmer is a good choice here since your flow is very aligned with a particular direction. 3. Check your y+ values. You have the all y+ wall treatment enabled, so your y+ values should be either from 1-5 or from 30-100. I will imagine yours will be high because you have no prism elements near the surface of the buildings or on the ground. 4. Your mesh is nearly a constant size in the entire domain. This means you have only 4 cells across your buildings of interest. You want to concentrate your cells in areas where the gradients are strongest i.e. near your buildings, and coarsen the cells elsewhere. Let's not cover anything on physics until the mesh is adequate. It's a quality mesh, it seems, but I don't think it will do well at resolving the flow features. crevoise likes this.

 March 20, 2014, 13:51 #7 Member   Join Date: Mar 2014 Posts: 31 Rep Power: 3 1. Just from running through tutorials etc... A lot of them used the surface wrapper so I suppose that I'm just carrying that on with the philosophy that "It couldn't do any harm to overkill the mesh generation"... I'll get rid of it. 2. My bad. Those shouldn't be tets... I must have been playing around with it and forgot to switch back to trimmer. That will also be changed. 3. y+ values were always something I wasn't sure on. When using FLUENT, I had some reference y+ values from another simulation but I assumed Star-CCM+ automatically determined appropriate y+ values with its near wall treatment... A silly error there also... Where can I set the y+ values? Looking at the y+ near wall model in Physics > Models, there's no option. 4. The base size covers the entire domain but in Regions > Body 1 > Mesh Values... I have a series of trimmer wake refinements which are quite an inelegant way of refining the mesh but they should be concentrated there.

 March 20, 2014, 14:17 #8 Senior Member   Join Date: Nov 2010 Posts: 418 Rep Power: 8 3. The y+ value is not 'set' anywhere, it's calculated based on the combination of the flow physics and the height of the first cell. If your y+ is too high, you need to reduce the first cell height. The near-wall treatments in all CFD codes are only valid for certain ranges of y+ values. Check this guy out: http://www.cfd-online.com/Wiki/Dimen...stance_(y_plus) 4. I can't see your wake refinements since the version I have uses tets. However I would highly recommend using volume controls in addition to the wake refinements.

 March 20, 2014, 15:40 #9 Member   Join Date: Mar 2014 Posts: 31 Rep Power: 3 Thanks for that... I've set "High y+ Wall treatment" since the user guide recommends this for k-omega... However, it specifies the same range you mentioned (30-100), yet I still can't find where this is available for change after calculation. 4. Added a volumetric control. Running the sim again...

 March 20, 2014, 16:04 #10 Senior Member   Join Date: Nov 2010 Posts: 418 Rep Power: 8 Where does the user guide recommend the high y+ treatment? That kind of recommendation doesn't make any sense. In order to change the wall y+, you need to change the height of your first cell. How you do this depends on your prism layer settings. If you are using a stretch factor, you can: 1. Make the growth ratio larger 2. Increase the number of cells in the prism layer If you are specifying the near-wall height directly, you can just change the value.

 March 20, 2014, 16:25 #11 Member   Join Date: Mar 2014 Posts: 31 Rep Power: 3 Done and done... Increased number of cells in prism layer to ten and resubmitted. The meshing is taking considerably longer now so I won't be able to check on it for some time. Hopefully, it starts to improve. Modeling Physics > Modeling Turbulence and Transition > Using Wall Treatment Models > How Do I Decide on a Wall Treatment? That's the UG section on the wall treatment. It's entirely possible I've misinterpreted it though.

 March 20, 2014, 16:45 #12 Senior Member   Join Date: Nov 2010 Posts: 418 Rep Power: 8 I think you're misinterpreting it; the type of wall treatment (wall function or wall integration) you use is dependent on what you want to resolve, not the turbulence model chosen. The mesh shouldn't take that much longer, the trimmer is a very fast algorithm. I wouldn't mind looking at your new mesh, or if you want to post a picture of it that'd be fine.

 March 20, 2014, 16:50 #13 Member   Join Date: Mar 2014 Posts: 31 Rep Power: 3 I've sent it to you. I have to mesh in batch as well since my computer dies whenever I try to mesh locally. I only get to see the output but I won't see the mesh graphically until the simulation has ran.

 March 21, 2014, 15:08 #14 Senior Member   Join Date: Nov 2010 Posts: 418 Rep Power: 8 Okiedokie, several more points: 1. If you look closely, you notice you don't get a prism layer. You need to enable the surface remesher to get one. 2. Your mesh is extremely large - the way you have it set up ran my laptop out of it's 32GB. I'm certain we can cut this down if we're more careful. Take a look at: http://imgur.com/a/SsExL This is my 3.6M cell grid 3. When using the trimmer, always specify relative mesh sizes in multiples of two. The trimmer is only capable of producing cells half as big or twice the size of any given cell. Therefore for all of your percentages, they should be multiples of 2 from 100. Going down: 100, 50, 25, 12.5, 6.25, 3.125 ... Going up: 100, 200, 400, 800 ... 4. You have a lot of wake refinements, which isn't really necessary. For the mesh I posted I used a single wake refinement and a single volume control, as well as specifying the mesh size on the surface of the building. You can see I have ~30 cells or so across the building, and that my prisms transition smoothly to the core mesh. Try and reproduce something like my grid. I'm not saying it's the absolute best, you can certainly change and refine it, but I'm sure it will result in a better solution than your initial grid crevoise likes this.

 March 21, 2014, 15:10 #15 Senior Member   Join Date: Nov 2010 Posts: 418 Rep Power: 8 On second thought, it's probably a good idea to extend the wake refinement so that the mesh does not get coarser as we approach the second building, but you can see the different by solving both if you like.

 March 21, 2014, 16:02 #16 Member   Join Date: Mar 2014 Posts: 31 Rep Power: 3 That looks awesome. That's exactly the kind of mesh I'm looking for. Could you clear the volume mesh and send me the .sim file? I know it's kind of like having someone else do your homework for you, which isn't the way to learn, but I keep running into trouble with these volume meshes freezing in batch mode and I'd like to see how you've done it. Also, thanks for the tip with the prism layers... As I said, I can't see the mesh until it's ran completely in batch since my local desktop sucks. Surface remeshing commencing.

 March 22, 2014, 20:11 #17 Senior Member   Join Date: Nov 2010 Posts: 418 Rep Power: 8 Your volume meshes are probably freezing because your machine is running out of RAM. Your original mesh size is far, far too fine. Quadrouple your base size and get a mesh. Find out where all the fine parts are, and why they're happening. Coarsen those settings, then reduce the base size again.

 March 24, 2014, 10:30 #18 Member   Join Date: Mar 2014 Posts: 31 Rep Power: 3 Hey... Great suggestion with quadrupling mesh base size and analysing it that way before reducing it to it's "actual" size... It seems to have had an effect on the solution... However, could you send me .sim file you meshed previously? I'm not convinced my meshes are constructed similarly and I'd like to compare... If you still have the file... On a slightly less encouraging note, I'm still receiving turbulent viscosity warnings even though I'm quite happy with my now modified initial conditions...

 March 24, 2014, 11:58 #19 Senior Member   Join Date: Nov 2010 Posts: 418 Rep Power: 8 I didn't save the file after I meshed it, I didn't think there was much point. I wouldn't run a solution up until you get the grid you want. What's your current one look like?

 March 24, 2014, 12:07 #20 Member   Join Date: Mar 2014 Posts: 31 Rep Power: 3 I think the apparent increase in convergence was false... Running the simulation interactively with reduced base size has revealed that I made a bit of a schoolboy error. I had created a block shape part and then created an automated mesh operation but it wouldn't mesh until the block had been assigned to a region. So, instead of refining the mesh, I've just created this additional block which is disrupting the flow... Need to get on the cd-adapco portal and discover how to mesh this block shape without assigning it to a region. Will send screenshots soon.

 Tags convergence, mesh, viscosity limitation

 Thread Tools Display Modes Linear Mode

 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 OffTrackbacks are On Pingbacks are On Refbacks are On Forum Rules

All times are GMT -4. The time now is 05:21.

 Contact Us - CFD Online - Top