|
[Sponsors] |
April 16, 2019, 17:21 |
Setting Time Step
|
#1 |
New Member
MCKoz
Join Date: Apr 2018
Posts: 9
Rep Power: 8 |
Hi all,
I have a general question regarding setting the time step. If I am running a simulation for several days of physical time where I essentially just want to monitor the depletion and distribution of several User-Defined Scalars over several days and I am not interested in capturing specific phenomena at certain time points, is using a large time step acceptable? I see most simulations setting a time step with something like 0.001s to monitor flow phenomena over time, but if I'm simulating over 3 days of physical time, is it acceptable to pick a time step of several minutes if I still reach convergence for each time step in an appropriate number of iterations? Thanks for any input regarding this. |
|
April 16, 2019, 17:41 |
|
#2 |
Senior Member
Lucky
Join Date: Apr 2011
Location: Orlando, FL USA
Posts: 5,761
Rep Power: 66 |
Is it okay? Yes. But there is some unreasonable limit and that is governed by the Courant number.
When the time-scale you are interested in is much longer than the natural flow time-scales, then your problem naturally requires more time-steps and you have to just accept it. Even a simple problem can be computationally expensive. |
|
April 16, 2019, 18:19 |
|
#3 |
New Member
MCKoz
Join Date: Apr 2018
Posts: 9
Rep Power: 8 |
Hi there, thanks for the reply. I've done some reading on the Courant number and it seems like from what I've read that ideally the Courant number should not be greater than 1. Is this just a general rule of thumb when setting up simulations?
In my particular case, it seems the courant number is 1.08 with a time step of about 30 seconds, so I was planning on picking a time step that would reduce the courant number to 1. From your experience is this a logical process of determining the maximum time step that would be acceptable while still arriving at a meaningful solution? |
|
April 17, 2019, 02:45 |
|
#4 |
Senior Member
Alexander
Join Date: Apr 2013
Posts: 2,363
Rep Power: 34 |
1. run your case with small time step for few physical minutes (1sec time step or less)
2. run your case with big time step for the same physical minutes (30 sec timestep) 3. compare solutions best regards |
|
April 17, 2019, 12:19 |
|
#5 | |
Senior Member
Lucky
Join Date: Apr 2011
Location: Orlando, FL USA
Posts: 5,761
Rep Power: 66 |
Quote:
A Courant number of 1 is pretty good and if you are ok with 30s, that's a good place to start. But you mentioned that you wanted to take several minute time-steps... For explicit time-stepping the Courant number must be less than 1 or it will diverge. Here it is a very explicit rule. For an implicit solver (and Fluent is a an implicit solver) you can tolerate larger Courant numbers. You still have the numerical oscilllations but they are more manageable. Furthermore, Fluent uses under-relaxation (both explicit and implicit relation) which makes is nicely stable and Courant numbers of 2 and 10 are quite common. But you cannot get too large or you will also run into problems with accuracy even if it doesn't blow up. So yes it is a generally good idea and rule-of-thumb to have a Courant number <1. The best thing to do is run simulations at different Courant numbers and see how it affects the solution (start near a Courant number of 1). And then make a well-informed decision on what Courant number works for you. You'll also be tweaking the number of iterations per time-step anyway so this is a good time to do it. Btw you are not unique. Everyone that has done a transient simulation has encountered the problem you have. And you'll learn soon enough the impact of taking large time-steps. Happy learning. If you want to take bigger time-steps, you need to get a coarser mesh, which might not even be the solution for you if you need a particular spatial resolution. |
||
Tags |
time step size |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
bash script for pseudo-parallel usage of reconstructPar | kwardle | OpenFOAM Post-Processing | 42 | May 8, 2024 00:17 |
pimpleDyMFoam computation randomly stops | babapeti | OpenFOAM Running, Solving & CFD | 5 | January 24, 2018 06:28 |
pressure in incompressible solvers e.g. simpleFoam | chrizzl | OpenFOAM Running, Solving & CFD | 13 | March 28, 2017 06:49 |
simpleFoam error - "Floating point exception" | mbcx4jc2 | OpenFOAM Running, Solving & CFD | 12 | August 4, 2015 03:20 |
Help for the small implementation in turbulence model | shipman | OpenFOAM Programming & Development | 25 | March 19, 2014 11:08 |