Currently I am running flow analysis of the internals of a building and am the part where I need to set the run time. I’ve trailed with the default timesteps but that was only done for the first run which had a much coarser mesh (700k nodes) as compared to this one (20mil nodes).
So basically I’ve already run into computational time limits which I’ve read about on another thread. However in trying to adjust for the optimal run time, I don’t understand what are the benefits and drawbacks to the different time types along with what the correct configuration is to get an accurate enough result.
Hi @Get_Barried, I had a look at your project. First thing is that you are running a steady state, this means that the timestep length doesn’t actually matter, think of it as more like iterations. So a time step length of 1s running for 1000s will just be 1000 iterations.
The cause of your computational time limit issue actually is the setting ‘maximum runtime’:
The maximum runtime restricts the computation time (real time!) to a chosen value. If the calculation is still running at that point of time, it is forced to terminate. If your simulation is not converging because of a oversized timestep length for example, you can interrupt it after a certain amount of time without you having to check on it repeatedly. Please be aware that in the case of a maximum runtime termination, intermediate results may not be ensured.
Meaning that you are hitting this time limit, you can just increase this. I usually run at about 30k(s) however with the size of your mesh you are going to take a long time to run. My advice is to make your mesh more efficient, your first mesh looks better, just needs a few more refinements to get the desired detail. After that increase the runtime slightly and you should be good.
Is this what you wanted to know? I saw you ran a transient simulation as well? or did you want more info on under relaxation etc?
Thanks for the info on how the timestep write control functions. I had a rough idea but this clears it up alot! However does timestep with a length of 1000s mean that every 1s it re-runs the simulation? Or does it simply follow up from the previous calculation till the end of set length? I know that you can control when the data saved through a value in the write interval, but what do the iterations in between do?
I have read about the maximum runtime and reacted accordingly by increasing it. Thanks for the heads up.
I wanted to know about the other write control methods and how to really use them. I’ve looked into the documentations and haven’t really got a sense of how exactly I should use them. For example, how does “Clock Time” and “Run Time” differ? When should I or should I not use them? Also what is a good write control to select for say a nice 10-20 second flow animation that can be captured in ParaView?
Ah yes the transient simulation, I was playing around with that and for my use case I did get a different result that differs from steady state results by about 5%, may I ask how does it differ from steady state flow? Is it simply just the flow type or some underlying numerical change? Isn’t any underlying numerical flow change governed by the preliminary selection of the desired turbulence models? Or if you have some documentation I can read through to get a better understanding of such I would love to read through it!
I have read through a SimScale forum post about “Under relaxation” so I do roughly understand about the numerics governing that.
so to clarify, if time step length is 1s and the end time is 1000s then we get 1000 timesteps, that is of simulated time, not real time or clock time. So if we simulated a building for say 100s in real time this would take an age, but the simulated time would be 100 seconds.
Timestep: Specifies the write interval via the actual simulation time steps
Runtime: Specifies the write interval via the computing time
Clock time: Specifies the write interval via the real time, measured on the computing machine
CPU time: Specifies the write interval via the real time, measured by the CPU
Adjustable runtime: Specifies the write interval via the actual simulation time steps
I find most of these to not really be much good in my use cases, I tend to use timestep if steady state, this allows me to say when I want a write in terms of iterations, if transient I tend to use adjustable runtime, this allows me to make a garanteed write at a time regardless of weather im using automated timestepping.
This could be many number of things, but most likely:
You simulate a more accurate fluid flow due to transient flows (vortex shedding for example)
the transient flow is not fully developed, there is a certain amount of your simulation that is kind of not relevant at the begining where the flow pattern is still developing.
It feels like not long ago when I asked the same sort of question!
I can give you some pointers but the short answer is, your still gonna use alot of core hours.
So adjustable run time uses courant number to adjust the timestep a good artical was actually posted on the simscale blog:
So this can be taken two ways we can use it to ensure that time steps are kept at the correct length, but we can also say that if the mesh size is smaller the time steps will also be smaller. So a quick way to increase time step length correctly would be to only use the maximum refinment level that will represent your geometry correctly. Anything finer you will need to take the computing cost hit as a consequence.
the second peice of advice also relates to mesh size in a way. reducing the mesh size in terms of cell number to the point that you can run on fewer cores. This might seem counter intuitive, but the advantage of increasing cores is only a real time advantage, in terms of results per core hour there is a disadvantage due to comunication time between the processors. There is alot of information available online about this.
After these two there really isnt much more you can do, and you might just be better off asking yourself do I need transient results?
your project is cool, would love to stay in the loop 