CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   FLUENT (https://www.cfd-online.com/Forums/fluent/)
-   -   Steady and Unsteady computations (https://www.cfd-online.com/Forums/fluent/167778-steady-unsteady-computations.html)

Luttappy March 8, 2016 12:49

Steady and Unsteady computations
 
Hi all
I have few doubts in steady and unsteady computations.

1. How do we know that flow is unsteady at given Reynolds number?

2. What will be the result if i do steady computation for a flow heat transfer problem which is actually unsteady?


Thanks in advance.

Luttappy

LuckyTran March 8, 2016 23:06

One problem is that "unsteady" is often used in a very vague sense and can refer to many different things.

I'm assuming you are talking about RANS:

1. Initial conditions and boundary conditions can lead to transient effects (i.e. a slab that is at a different initial temperature than its boundaries) . This is when you always know it will be unsteady.

Otherwise there would need to be some periodic vortex shedding or some inherent instability in the flow. Because of the separation of time-scales built-into RANS (turbulence happens at much faster time-scales than mean flow), the unsteady effects are not caused by turbulence but other laminar behaviors.

2. If there are inherent instabilities then it is unlikely you will ever get your solution to even converge. Even if you did, it wouldn't make any sense. It's like trying to measure an AC voltage with a DC multimeter, you'll get a completely aliased measurement. But suppose you did get it to converge, then you likely solved for a metastable case (an unstable equilibrium of the flow). This metastable condition however, may not be what you are investigating.

scipy March 9, 2016 05:46

I've always used some simple logic when it comes to steady vs. unsteady.

1. Everything in real life is unsteady. That said, most of it can be well-enough approximated by steady simulation since we care about averages most of the time (unless you explicitly care about pulsations, frequencies of some variable etc. but in that case you know ahead of time that you'll need to go unsteady).

2. I always try to go steady first. Let's take an example of flow around a cylinder:

http://www.thermopedia.com/content/5..._OVER_FIG2.gif

If you try to simulate all of these different Re flows with a steady simulation you will succeed with the 1. 2. and 5. because they inherently don't exhibit that much transient behavior. What's gonna happen with 3. 4. and 6. is that your residuals (as well as any force/other monitors that you set up) are going to start oscillating and your solution will not converge (as LuckyTran said).

This is when you switch to an unsteady solution and either guesstimate as time step based on the physics of the flow (higher frequency = smaller time step) or you try to calculate the time step before hand based on any number of recommendations out there (they vary for different physics and problems, internal flows or external flows, heat transfter or adiabatic etc).

3. If you're doing an unsteady simulation, make sure your force/other value monitors are not jagged but rather smooth (jagged means the time step is too large). Basically, you want to use the largest time step possible as long as it accurately describes/fits the period of your force monitors. For example, if we go back to flow around a cylinder at low Re we know there's gonna be separations coming from one side and then the other (top and bottom). This will lead to a pressure variation that will cause the vertical force on the cylinder to oscillate in a sine wave form. Now, if you chose too large a time step then you're force monitor would look like the upper wave in the following picture, and if you chose an appropriate time step it'd look like the lower wave.

http://www.cliftonlaboratories.com/u...es/swordf3.gif

I could always guesstimate a time step to get a nice and smooth looking force monitor and then I'd try increasing the time step until the force monitor started to look slightly jagged. At this point I'd go back to slightly smaller time step (it may be a little jagged or toothy but it should still described a sine function smoothly).

Hopefully this is all clear enough.


All times are GMT -4. The time now is 02:58.