[baineteo]

Hi guys,

I'm trying to do some very simple simulation of wind blowing against some buildings (4 square buildings, set in a square, to be precise).

In my simulation, I noticed that at Z=0 (which is the ground level, set as No-Slip wall), the velocity magnitude of my flow isn't zero. Shouldn't the area in direct contact with the floor (or any wall) be zero? Due to bonudary layer?

My initial conditions are like this:

- Velocity inlet = 2m/s
- Pressure outlet
- All other surfaces are non-slip walls (except the "sky", where it is set to Symmetry plane)

I'm also not sure what values I should use for the turbulent dissipation rate, turbulent kinetic engery and such. I've tried using the values from the "Simple Flow" tutorial as well as the "Introduction to Star-CCM+" tutorials but don't seem to be able to get the desired outcome.

Thanks in advance!

[Josh]

Velocity is a cell-centered quantity. Since cell centers obviously have some distance from the wall they touch, the velocity value will be nonzero. The finer the mesh at the wall is, the closer to zero the value should be since the distance between the cell center and the wall decreases. In the case of a probe, the value is interpolated from the surrounding cells. So, again, velocity would be nonzero (but should be close to zero). So, if you're plotting velocity profiles, for example, you should add a zero to each profile as the starting point.

Turbulence values are heavily dependent on your scenario. We can't tell you what to use. This is usually a parameter extracted from experimentation or estimated based on the bodies of interest. If you're modelling buildings, your turbulent length scale should probably be quite large, roughly of the order of magnitude of the building. You may have to perform some sensitivity studies, i.e., keep all the parameters constant and only alter, say, turbulence intensity.

[baineteo]

Hi there,

Thanks for help!

[baineteo]

Hi Josh,

I've read several times that residuals are not good indicators of solution convergence. Hence, I have set up 3 velocity magnitude monitors behind my buildings to see if the velocity has stabalize, hence checking if the solution has converged.

I did a couple of runs, and one of them came out weird (all values were indentical, except for the buildings' dimensions). Instead of flattening out, my velocity magnitude for one of the simulations looks like a sine wave after several iterations (going up and down, and repeating). What does this mean?

[Josh]

It sounds like your building is shedding flow structures like a von Karman vortex street. Make a scalar plane around the building (looking down on the roof) with velocity or pressure as the contour and create a movie of the contour. If the simulation is explicitly steady state, you can set the contour to export a picture file every n iterations. If you can visualize unsteadiness in the flowfield, then you should run the solution as unsteady.

[baineteo]

Indeed, it did look like von Karman vortex developing behind the building. Thanks for pointing that out!

I did try running the simulation in implicit unsteady state, but I'm not sure if I was doing it correctly. I'm not sure what to use for parameters such as Time Step, Inner Iterations etc, and how the residuals should look like.

I did, however, manage to get a rather steady output for my velocity magnitude monitors. But this was only after 2000 iterations, which is taking too long. I've seen people suggesting to run the solution as steady before running it as unsteady, but when should I make the change over? Would it be ok if I were to make the switch the moment the "cyclic rythm" appears when running the solution as steady?

Thanks!

[Josh]

The primary benefits of running steady state initially are 1) your flowfield becomes established, which saves time, e.g., since nothing needs to be transported from the inlet, and 2) you have one less variable to worry about causing divergence. And yes, a good time to switch to unsteady would be when the cyclic rhythm, i.e., unsteadiness begins.

You'll have to perform sensitivity analyses with your timestepping scheme. Start with a very small timestep and a large amount of (inner) iterations per step to help convergence. Once the residuals appear to be converging, you can gradually increase your timestep to the desired size and decrease your inner iterations.

To determine a crude timestep, t_step, divide your smallest building length, L, by your flowfield velocity, u, to determine how much time, t, it will take for the flow to pass that building: t = L/u. That's one unit of time. Now, decide how many units, n, you want to capture the flow around the building and divide the time it takes to pass the building by the unit of time: t/n = t_step

[baineteo]

Hi Josh,

Thanks for the help. It seems that my solution converges after the first run as unsteady (my velocity magnitude monitors flattened out), although time time step was small and my inner iteration was huge. Not sure if this is alright.

Could I also ask if it is possible to plot "Turbulence Intensity" in STAR-CCM? Thanks!

[Josh]

Originally Posted by baineteo

It seems that my solution converges after the first run as unsteady (my velocity magnitude monitors flattened out), although time time step was small and my inner iteration was huge. Not sure if this is alright.

Well, we can't tell you. It depends on how long you want to run the simulation for. How many physical units of time in "real life" do you want to measure? If your timestep is, say, 1E-3 s, and you want to measure 10 seconds of real time, you'll need 10000 timesteps. Also, remember what I said - start with many inner iterations, then decrease them. You shouldn't need more than, say, 10 inner iterations once the solution stabilizes.

Originally Posted by baineteo

Could I also ask if it is possible to plot "Turbulence Intensity" in STAR-CCM?

Yes. It would be a pretty lousy CFD program if you couldn't calculate turbulence intensity. It's not a built-in function, so you'll need to define it as a field function.

Tu = sqrt((2/3)*k)/v

where

Tu is turbulence intensity
k is turbulent kinetic energy
v is a reference velocity
(if you want Tu as a percentage, multiply the right side by 100)

So, in the field function, the definition would be

(sqrt((2/3)*$TurbulentKineticEnergy))/v

where v is a reference velocity, e.g., your inlet velocity

Then, just define a scalar and plot your field function.

[baineteo]

Ar.. thanks for helping out with the Turbulence Intenity.

Anyway I previously said that my velocity magnitude monitors "flattened" out when I ran the solution as unsteady, but it seems that it wasn't really flattening out. The plot actually simply doesn't move from the last value (i.e. it goes in a cycle, and then once I run as unsteady, it simply becomes constant).

I (for some unknown reason) decided to try using a different mesh instead. I was using polyhedral volume mesh, and decided yesterday to try using tetrahedral for volume mesh. Using the same parameters and settings, I ran both files.

What I got was that the tetrahedral mesh finally converged (on 1000 iterations) but the poly-mesh didn't. I'm guessing it could be due to the low quality (too coarse) of the mesh. It does seem that less cells was generated using the polyhedral volume mesher.

Strangely though, in my initial problem at the beginning of the post, I was using tetrahedra mesh (the mesh were of the same size and growth rate).

I was using polyhedral because I've seen several comments about using polyhedral over tetra..

and oh, there doesn't seem to be an option for k-epsilon RNG or standard settings? I was meshing around in Fluent and there was the option between Standard and RNG. Searching the help file for RNG didn't turn up anything.

[Josh]

Perhaps your timestep is too large and it is dampening the unsteady effects, or maybe it's too small and you haven't given it enough time to capture anything. We'll need more details.

Always, ALWAYS use a poly over a tetra. There is no advantage to using a tetrahedral mesh. It's only incorporated in the program in case you need to compare to similar polyhedral mesh simulations.

Of course less cells were generated with the poly mesh. Think about a polyhedron, let's say 8-sided, occupying a space. Now consider how many tetrahedra (4 sides) would be required to resolve that same amount of space. For more info on other benefits, see: http://www.plmmarketplace.com/upload...polyhedral.pdf

You're correct about RNG. It is not included in CCM+. It is not one of the more revolutionary k-e developments. There are many, many turbulence models available to implement so a company must be selective in choosing their models. Rest assured that the programmers have read and performed many, many studies using a variety of turbulence models and have selected the preferred ones.

[baineteo]

Hi Josh,

Thanks for posting the link on polyhedral advantages. It was quite useful.

Anyway in my control volume, there are 2 buildings - one directly behind another. Each building is 20m by 20m by 50m (height), with a gap of 10m between them. My wind velocity is 2m/s. Hence based on your previous message, t would be 25seconds.

I've tried setting t_step to 50 seconds (hence only 1 unit of time) with max inner interations at 1000. When I set t_step to 50s I do get "better" results (than when I first set t_step to, say 1 second).

What I got from t_step = 50s was that the velocity magnitude monitors evened out at a slower rate than it did when t_step 1s. In other words the values didn't simply just became a straight line.

However, the velocity magnitude monitors flattens out way quicker than when the residuals flattens. You mentioned that I start with a small t_step and large number of inner iterations, and when I see that the solution appears to be converging, I should gradually increase my step size and decrease the inner iterations.

Actually I don't really know when exactly is "appears to be converging" refers to. Does it refer to having the residauls dropping, or them flattening out?


Should I be doing this? (The first drop is the first unsteady run; second peak is the second unsteady run etc)

Sorry, but I'm really quite confused here..

[Josh]

It sounds like you need to read some basic CFD literature to understand what convergence means. Residuals decreasing monotonically indicates that the equations are reaching a resolved, precise state. When they flatten out, they are not getting any more precise and you have reached a "steady" solution. Precision, however, is not synonymous with accuracy. To determine accuracy, you must monitor some other convergence criterion, e.g., drag of the buildings.

Actually, based on my previous message, the time required for the flow to pass the building would be 10 s (i.e., (20 m)/(2 m/s)). Hence, your absolute minimum timestep should be < 10 s. To start, let's say t_step = 1 s, which is still pretty coarse. I'd start with a timestep of 0.1 s and 20 inner iterations.

In your diagram, the results before iteration 450 are probably not converged. Most of the residuals have only dropped by 2 orders of magnitude. Residuals, as a rule of thumb (but not officially), should drop by at least 3 orders of magnitude. The second and third runs are much better.

I recommend picking up a CFD intro book.

http://www.cfd-online.com/Books/