using the calculation control options you can set the time step manually. This will give you a faster calculation with a reduction in accuracy (likely not much based on the size of your plate).
You can set it to solve with goals and track the temperature to determine when you have reached what you consider a steady-state soluton. If you do not specify goals and let it stop based on those goals converging, then it will run until it reaches the real time limit you set.
given that once the convection field is established it will be more or less steady, you could use flow freezing to speed up the calc. You would need to have the calc go for say 1/4 to 1/2 a travel and then invoke flow freezing. You may have to put in forced saving at specific times to ensure you get adequate temporal resolution.
What Bill suggests may work, but perhaps another approach may be considered as well. Not many users know this method that I will describe.
Basically, you can begin a transient analysis from a steady state solution. To accomplish this, when you are at the Ambient / Initial Conditions screen in the Wizard, click in the line at top that says Prescribed (or something like that since I'm writing this from memory), in the drop down menu that is then presented, you can change the option to "Transferred." Here it will bring up a dialog to select either a previous Flow Sim project or a results file (FLD) from a previous solution.
(An aside: Best way to learn software is to click EVERYWHERE! And this is especially true for the Flow Sim software.)
Thus, you can set up the flow part (basically velocity and pressure) of it by running a steady solution for it, and then solve the transient thermal problem from that. This will allow you to use a time step that is dependent mostly on how quickly the temperatures are changing (and not all of the simultaneously solved quantities).
This sounds like a good approach. Unfortunately, SW crashes every time I try to enter the transferred .fld file so I'll have to contact my VAR to see if they know what might be causing this.
I think I understand the premise though- determine the time it takes for one travel, determine how many cells you want for a properly refined mesh, and then from this calculate an appropriate time step, right?
Thanks also for the background information, I definitely like to know what the underlying principle is to validate my assumptions.
The reason that it is taking a long time to calculate a transient analysis in Flow Simulation because the software's solver uses a conservative approach to ensure stability in the solution. This is done intentionally so that the software can be suited to a wider user base without the need for prior knowledge, although I'll admit that in this case it can lead to frustration to the user. I would not suggest a user to go barging straight into a transient analysis without greater instruction and understanding of the underlying calculation.
In short, the same way mesh size ensures a good calculation in space for a steady solution (well, it does also apply to time dependent problems too), the time step ensures accuracy in time for all the primary calculated values for a transient solution. Too large of a time step may can cause the solver to diverge. Flow Sim (being geared towards a general audience) tends to make the time step smaller, sometimes much more so than it really needs to be. The time step that can be used is dependent on the timescales of momentum, mass, energy and species, or in other words, velocity, pressure, temperature and concentration.
An estimate that can be used for determining the appropriate time step is determining how many cells a molecule of fluid can traverse in a single time step; this value is known as the Courant number. In a simplified one-D case:
- Courant number = (Velocity) * (time step) / (cell (or element) size).
Typical values for Courant number can vary anywhere from 1-10, where smaller is better, and still be acceptable, but I would recommend to keep it closer to 1, and less than one is best for stability. Knowing a priori how quickly your results will vary in time will also allow you to determine what time step is appropriate, but do note that just because values that you are interested in may not change that rapidly, there are other quantities being calculated simultaneously that may have a much smaller time scales, so you will need to be conscience of them as well.
In the formula above for Courant number, you will notice that the element size is a limiting factor, and can be devastatingly limiting if you have very small cells. Why? Because you only have one time step, but many many calc cells, thus the time step for the calculation is based on the smallest cell in the domain.
What to do? Without prior knowledge, first do a time dependent problem with a very coarse mesh! Solve this to figure out how the quantities are changing, and then use this information to select an appropriate time step when going about refining the mesh in space (to the geometry and flow field). As Chris Michalski noted, you can change the time step manually.
For more on the Courant number, you could read about the CFL condition in any text book, or perhaps get an overview here on Wikipedia.
Message was edited by: Joe Galliera. Spelling, and added line about CFL condition with link to Wiki article.
"What to do? Without prior knowledge, first do a time dependent problem with a very coarse mesh! Solve this to figure out how the quantities are changing, and then use this information to select an appropriate time step when going about refining the mesh in space (to the geometry and flow field)."
This was key. I've now got a basic time-dependent solution that solves in a reasonable amount of time. Use of symmetry and control planes to get a refined mesh where it's important (and a loose mesh where it's not) were critical, too. The interesting thing is that the time step is iterative too (if you don't use a manual time step), so in some cases Flow Simulation will eventually settle on a time step that is greater than the one you might have calculated manually.
Thanks to all three respondents for your suggestions.
p.s. The transferred boundary conditions were crashing the setup wizard but could be changed manually in the Input Data afterwards (?).