Timestep in transient analysis

[OmkarJ]

Hi,

I wanted to know the timestep the Solver is currently using for a transitnt analysis when the the ISC is turned on. I perused the "Status File" and spotted the "Delta T" which I suppose must be the timestep for that that particular set of inner iterations. Am I right? 

I have few questions:

1) How do I change the pace at which the ISC changes the chosen timestep? From observation, I see that the timesteps are reducing at the pace of 4-5%. Is it possible to change this rate?

2) When ISC is turned on, will the Solver increase the timestep as well, when the chosen timestep is too small? If I could increase the rate of change of timestep, I  can rather specify very small timestep and let ISC find the actual timestep quickly.

3) When timestep is too small, it gives the rounded value in the status file, e.g . 1e-5 s. Is there any way to get the decimal value?

Thanks

Omkar

[Royce_adsk · Accepted solution]

Hi Omkar,

You are going to want to monitor the .sol file which is found in the solver folder.  

1) How do I change the pace at which the ISC changes the chosen timestep? From observation, I see that the timesteps are reducing at the pace of 4-5%. Is it possible to change this rate?

Can't change this. 

2) When ISC is turned on, will the Solver increase the timestep as well, when the chosen timestep is too small? If I could increase the rate of change of timestep, I  can rather specify very small timestep and let ISC find the actual timestep quickly.

The timestep choosen for the simulation when you initially setup the solver will act as a limiter for the ISC maximum timestep.

3) When timestep is too small, it gives the rounded value in the status file, e.g . 1e-5 s. Is there any way to get the decimal value?

 Use the .sol file instead.  This was something I brough up with the solver team a while ago regarding the timestep rounding in the rotating region file and status file.  It isn't technically a rounding, but a 5 digit float to string conversion.

[OmkarJ]

Thanks Royce.. quick as always!

The timestep choosen for the simulation when you initially setup the solver will act as a limiter for the ISC maximum timestep.

This is a bit strange. So in case of extreme prescription of the timestep either of the following will happen:

1) Too small timestep specified: In this case, the Solver will always choose the timestep smaller than/equal to this, even though there is a scope to increase.  I have seen often that the transient analysis have the initial startup transients  that decay over time. Which means, relaxing the timestep is allowed. But as you say, the ISC will not go beyond the specified timestep. Result: Too slow progress in time.

2) Too large timestep specified: Solver will keep reducing the timestep until it is adequate for required CFL. But since the pace is 4-5%, all the initial timesteps are too large to resolve the transient variation. Result:Compromised temporal accuracy for that initial period.

How would you suggest, generally, to approach the timestep for ISC then? 

The age-old technique of (residence time/20 etc) won't work in case of some phenomena where timescales can't be estimated (e.g. vortex shedding due to undocumented shapes like perforated sheets, wedge wires etc).

In a hindsighr, probably it makes sense to give a window for timestep (min and max) when ISC is turned on? I have seen some CFD codes do it.

If I think aloud, then the manual timestep makes more sense? You can do a sensitivity study and keep monitoring the  monitor points of interest and "Resid In" to make sure they flatten at the end of every timestep. That is the adequate timestep...

Thoughts?

[Royce_adsk]

I don't disagree with anything that you said.  

I typically run a simulation with a quick guess for the time step with ISC turned on.  Then I reivew the .SOL file to see what timestep the solver eventually uses.  At this time I then go back and set a timestep and run with ISC turned off. Generally, I will end up using a larger timestep then what ISC was suggesting since it almost always ends up being a conservative number.  If I have time I go back and run the simulation again with a smaller timestep to test sensitivity.  Sim 360 is brilliant when doing sensitivity testing since you can send them all to the cloud.

Then, after the initial startup transient has completed I will stop the simulation and increase the timestep if needed.  When I did this a lot in the past I would write a script that would increase the time step every X number of iterations so I didn't push the time step up too fast.  I would run at least 100-200 iterations with each timestep change.  Many times at this point I will just runout with that smaller initial timestep unless we are talking a very long transient being solved for.

What do you think of that process?

I agree that we could do more with the approach we have with transient simulations solver controls. I would like to have a starting timestep with a maximum long term since now that first iteration is solved based on the initial timestep which may not be appropraite at t = 0.

[OmkarJ]

Then I reivew the .SOL file to see what timestep the solver eventually uses.

This timestep will be "auto_dt from Courant", right? Also, given that Solver reduces the timestep at 4-5% it may take a while before it ultimately reaches its ideal timestep. This is where I have a concern. Hence instead of "adaptive" approach, probably it may make sense to use the other suggestion you made... to initiate with different timesteps e.g. 0.1, 0.01, 0.001 etc.. and run the simulation for some time with ISC turned on and then check auto_dt. The timestep which doesn't show much change, is the one you want. 

since now that first iteration is solved based on the initial timestep which may not be appropraite at t = 0.

Exactly! This is why it makes sense to have a minimum and maximum window etc, or at least to allow Solver to icnrease the timestep if it is too small, unlike now where it is a max limiter. In past when using other CFD codes, I used to start with a very small dt and let Solver increase it at a larger rate (rate which was adjustable). This way the initial transients didn't suffer and you could arrive at an optimum timestep quickly, at a pace you desire. 

Will post this on the Idea Station...

[Royce_adsk]

I usually look at these two lines.  The numbers in this case are not important.

iter 1 solver_iter 0/0 RR 0.000000e+000/0.000000e+000 Flow_dt 7.542205e-002 Thermal_dt 7.542205e-002 time 0.000000e+000
auto_dt from Courant 7.542205e-002

Point 2: If you examine closely how the phesudo-transient (steady state) solver works it actually solves in the way you describe.  It starts at a very small timestep and then ramps up the phesudo time step to a very large number (final value depends on the physics) to drive the solution to a steady state result.  As a side note, some cases that come into support will result in us controlling that final maximum value to maintain stability.  Typically for compressible, radiation, and maybe natural convection analysis.

[OmkarJ]

If I may ask something on pseudo transient solver that is out of context of the original question...

The implementation of the pseudo transient algorithm in SimCFD resembles the one suggested in this paper, which is fairly popular. 

http://www.tandfonline.com/doi/abs/10.1080/01495728408961817

More specifically, the first recommendation in this paper to locally increase the timestep in pseudo transient solver by a factor that can be input in the setttings. So the timestep for different cells is different and is dependent on the multiple of local courant timestep. Thus solutions progress at a different pace at different parts of the domain.

If you have a look at SimCFD formulation:

http://help.autodesk.com/view/SCDSE/2014/ENU/?guid=GUID-F63BDCE0-F047-43DB-B924-F3B0F9A5950F

The factor I mention here is Delta_t_inertia. I don't know if it's an empirical constant but it seems to be. If yes, do we have access to it?

[Royce_adsk]

The delta_T_inertia are the radio buttons that you can adjust in the manual solver controls.  I use these adjustments very often for steady state compressible simulations that are unstable.  I typically only use the pressure and leave the temperature radio buttons alone.