[drdet]

I have a transient gas decay process I want to model in Flow Simulation. I read somewhere once that the default time step size chosen by Flow Simulation is very conservative, and may be based on the Courant number. I also read that the Courant number isn't so important for some solving schemes, and instead the Peclet number needs to be considered.

The default time step size for my simulation with automatic mesh was 0.004 seconds, and I need to simulate a 300-second duration of time. The simulation was estimated to take nearly 600 hours to complete - far too long for what I need to do (I have to run ~130 similar simulations over the next two months). I wanted to get some advice about how to proceed using Flow Simulation.

My plan was to find the best grid size by performing a grid dependency study, then do a time-step sensitivity study. Similar studies performed by other researchers using Phoenics for CFD used a time step size of 10s for the transient gas decay process, and showed good agreement with measured data. If I want to use a time step size of 1, 5, or 10s, can I achieve a time-accurate solution with Flow Simulation? Do I need to manually specify a large number of iterations at a very small time increment before the first second to make sure the solution has converged before marching forward in time at the larger time step sizes? Are there any guidelines for the math function to use to do this (i.e. some exponential function to determine the time step to use for each iteration up to 1s)?

[Boris_M]

Hi Dan,

this is correct. I think you can use the Courant number to estimate the time step but you can also try it with the Peclet number. That way you have two numbers for your time step convergence study to include. I don't know which version of SWFS you use but in the very latest where there is also the sliding mesh capability for rotation, it will be possible to set a higher time step if the calculation is only fluid flow, heat transfer and radiation. Other features such as rotation or cavitation and humidity are not supported yet by the new transient solver that is implemented. The old solver does one iteration per time step and the new solver does a range of iterations per time step. The solver will automatically switched depending if you use the mentioned features or if a not supported feature is included. So it does internal iterations per time step which makes it possible to increase the time step and still get accurate results. Of course only up to a certain value and then the accuracy also decreases. You should see that in your study. We've seen 24x speed increase in the overall solving time for one case we tested it with. The old solver gave only accurate results (meaning without larger deviation from the measurement) up to a certain time step and the new solver was able to increase the time step drastically so that the calculation was still accurate within that deviation from measurements but was 24x faster done.

Have a try,
Boris

[drdet]

Wow, I must try that, thanks! I have been running SWFS 2013 SP3.0, and did not want to change to 2015 because of some VBA coding I wrote that works fine in 2013 and I don't want to chase down all of the changes that 2015 is likely to include (menu locations have moved, there was something different in how the API was initialized, etc). But if it will help me with my transient simulations for this one problem I'll give it a try.

[drdet]

Originally Posted by Boris_M

So it does internal iterations per time step which makes it possible to increase the time step and still get accurate results.

Hi Boris,

I am running the new version now, and set up my problem as transient. I don't see anything different happening in the solver - does it show the internal iterations? It seems to be just as fast as before, requiring ~13 seconds per iteration using a 1s manual time step. I know you said the program automatically switches depending on the options selected, but is there a way for me to know it is happening? Also, are the convergence criteria used for transient simulations now? In the past, I just set them for information only since many times the stopping time was reached before convergence of all variables.

Thanks,

Dan

[Boris_M]

Hi Dan,

no, you won't be able to see any difference happening except for a more accurate solution with higher time steps. Where you were used to reduce the time steps to get an accurate result you can now use larger time steps.
It doesn't show the internal iterations. It uses convergence criteria to abort the internal iterations if the accuracy is enough within a time step and go to the next time step. By default it does a maximum of 25 iterations within a time step.
Yes, the CPU per iteration might be about the same speed or a little longer but since you can do larger time steps (you have to manually define the time steps in the calculation control options) the time overall is less to get from for example 0-1s.

As an example:
The old version you did 0.01s to get from 0-1s and it took you 10 seconds CPU time per iteration. So the overall time was 1000 seconds.

The new version you can do 0.2 seconds to get from 0-1s and the iterations might take 20 seconds so that the overall time for the calculation is then 100 seconds.

I hope this explains how it will be faster and why. Unfortunately I cannot show you the example I have as a graph. But consider you did tests on a model with time steps as in the left column below and the temperature result are in the middle column to see the time step convergence in accuracy, similar to what you would try to do with the mesh convergence. The right column shows the new solver as example accuracy:

time step___T [°C]______New Solver T [°C]
0.001______120____________120
0.005______120.5__________120.1
0.01_______120.2__________120.3
0.02_______115____________119.9
0.05_______108____________120.1
0.1________crash__________120.3
0.2________crash__________114.4
0.5________crash__________106

(sorry for the ___ but the formating would be gone if I leave them out.)

As you can see in this example the new solver is still accurate for high time steps up to 0.1s as time step. All the values are just to illustrate it, they are not actual results. So the upper limit time step is not to be taken as 0.1 as I have it here but will be different for the every model just like it is for the old solver.

No, you won't see if the solver is used as it is just a temporary solution until the whole solver is converted for all the physics you can select in the calculation. This solver works for fluid flow (except for real gas and steam as fluid), heat conduction and radiation. It will use the old solver for cavitation, rotation, humidity, steam, real gas and the high mach number option. So knowing what you set in your simulation you know which solver is used.

Convergence criteria are always deactivated as "stopping criteria" if the project is created as a transient project from the beginning this was the case and is still the case. The goals can be used for convergence or monitor only as a stopping criteria, they do not influence the convergence but tell the solver if you are within the limit you can stop if all goals are fulfilled. Especially in transient cases the criteria can be large enough for the solver to stop since the values change only very little. The reason for that is that the convergence is checked in a certain interval and if the time step is so small that also the value is growing so little that it is still within the criteria it would stop because it is fulfilled. So this is one reason why it is by default deactivated as stopping criteria for transient cases, the other is that no one can tell or nature is not necessarily converging within the physical time you define for the calculation. This time is the stopping criteria for transient cases. If you switch a steady state project to a transient, these options are not changed so your stopping criteria will be the maximum travels "or" the goals. I emphesised "or" because the default setting is "if one is satisfied".
You can activate or deactivate the goals for transient but usually you don't want them for a transient case as it should stop when the time has passed and not the goal is converged.

I hope this explains it,
Boris