As of yet, I have not given much thought to being able to estimate good numbers for these prior to running of a simulation.
It is becoming apparent that I should do my patented ‘Dale with a bone in his mouth’ : review of how one should set these numbers for a CFD simulation
I am thinking that some rule of thumbs should be developed based on things like:
How many iterations does it take for the first particle of air that enters the domain, to exit the domain (if it follows an undisturbed path)? That is relatively easy too pre-calculate…
What is the largest spacing between two adjacent largest mesh cells? (again fairly easy to estimate)
What is the largest spacing between two adjacent smallest mesh cells? (again fairly easy to estimate)
Does anyone have rules of thumbs that they use? (@Retsam you seem to be a master here )
@DaleKramer approached the final verity about me being a anti-master and takes the opportunity to tease me a bit.
I’ve seen today your para glider (30 Mnodes) simulation and I understand your pain. Forces are stable after 50 steps, residuals flat after 200 steps, so why wait on 1200 steps? Moreover, steps in Steady State simulation are called ‘seconds’, which may be misleading. Hence your questions about time spent by particle in a BMB may not be relevant.
In case of low turbulence, forces on your geometry will be stable in very short time: I believe that the particle will be still in the BMB. Simulation calculation uses pressure and k (mainly), so it may explain why, for small turbulent condition, simulation time can be divided by 10…
Now, my rule of thumb is the following:
Set simulation time to 25 - 50 ‘seconds’. Use 0.5 sec steps. Write interval, say 6 seconds (it is also equivalence of times 50 -100, 1 sec step, 10-12 sec write interval).
Look at plot of forces: you should discover minimal time to get stable forces.
Look at k plot: you should observe the slope and decide if you have to add time (keeping the step size, but making interval bigger, as system prevents to have more then 12 intervals).
Because I look at the force plots over time, select a lowest point value near the end time, then I multiply that value by 1.01, use that 1.01 scaled value to find out the last iteration that was not above it (this becomes the start of 1% range and the end is the last iteration time).
Then I specify my actual value as 1.005 times the lowest value in the range and the result would be this 1.005 scaled value +/- 0.5%…
When I see stable but fluctuating results, I try to see if the best fit ‘center line’ of the fluctuations is stable to 1%… stable and use the ‘centerline’ middle value for my result value with a +/-% of the peaks of the fluctuation in the range… (this assumes that the fluctuations are themselves relatively small and stable).
Essentially I want my data to be stable within a 1% range over many hundreds of iterations…
To determine that 1200 was the shortest time I needed, I actually went to 2000s to be able to easily find my 1% stable range and the beginning of my 1% stable range was 1200s, so I use 1200s for my endtime for that geometry and inlet speed from now on…
If you want stable results, it takes iteration… (and cloud time)
Yes, very missleading, I complained about that when I first started here. but lately I see people using them as time relative to cell size, inlet velocity etc.
I need to absorb your rule of thumb and try it to see if your rLIFT and rDRAG matches mine to within 1%…
Ok, before I attempt your method, I must understand it…
It is now appearing to me that the only reason that you use something other than 1s interval is so that you can essentially have a write interval that is longer than 12 intervals, is that correct?
I understand ‘write interval’ in Simulation control to be how often full results are written. I always set ‘write interval’ here to ‘end time’ because I only need results at the end of a converged and stable simulation run…
In my ‘Force and Moments’ and my ‘Force and Moment Coefficients’ results items is where I set my ‘write interval’ to 10s or whatever you like, as there it only affects how often those results are written to the Solver Log…
I am also confused as to what to do once you look at the k slope…
Lets get on the same page before I try your rule of thumbs… I always caulked it up to that fact that you don’t seem to demand the same precision I do…
On a side note:
Sorry, wasn’t meant as a tease, but I have watched your projects in awe of their low core hours and I have never been able to get results that seem stable to me in your short runs… I have always chaulked that up to the fact that you do not seem to demand the same precision that I do…
Yes, @DaleKramer, I should possibly precise few things:
Please stay with your 1 seconds, my 0.5 seconds was kind of ‘habits’ and no valid reason can be proposed.
I always use ‘write intervals’, as, in my opinion, it allows me in early phases discover if flow rotates correctly (for MRF or momentum sources), what kind of eddies I have in the begin, how k develops on edges.
One can have only 12 write intervals, I use mainly 6 -10, which is enough for my observation. They would be evenly spaced in simulation time. They allow also animation, if necessary.
K slope would go asymptotically down to a level like 2-e3 or better, for a while. So I can see how much better i will get with k on that hyperbolic curve (yellow rectangle). However your geometry would be microscopically impacted by late development of k: forces should be, for practical reason, preserved.
OK, so I suspect that any actual force results that you get with you short simulations would vary significantly from my 1% stable force results…
BUT, that is OK since we have different data analysis goals… you are looking for only fully developed flow while I want stable precise results after the flow has developed…
Since you are such an expert in determining when the flow has fully developed, could you please do your magic on the ‘Incompressible - SOLID Mentor XS’ simulation I have here ? I really would like to see the rLIFT, rDRAG and PitchingMoment that we are left with when your needs have been met…
@DaleKramer: project took some time to downloads to the World’s Edge, but now I can only say that your validation of rotated inflow is impressive! As mesh is quite big, forces stabilize only around 800 steps. It should be an example to follow for all cases where AoA or drag / lift should be calculated with precision, however I would prefer a smaller one. In your case paraglider geometry from Rhino shows only ropes: everything looks like a ‘ghosty’ paraglider.
What bothers me is the simulation instability (collapses of residuals), starting from step ~430. K and omega go hectic for ~20 steps, then k tends to 0 in a crazy linear drop, recovering 50 steps later. That residuals instability does not affect forces calculation.
Yes, the ’ Mentor XS LINES geometry’ was extremely difficult to mesh to a 29M cell mesh and I am the first to admit, it is a questionable simulation. Even tho it is hard to see the lines, zoom in the mesh is there… (the lines did not need forces rotated as the lines were at 10aoa in the geometry file and the sim had 0iaa to the domain).
Here is the worst areas of the 29M mesh (ucky but marginally resolved in this small 0.6mm diameter line section):
The link I gave you was to a nice geometry of the SOLID wing only (no lines attached), whose geometry file was ‘Mentor_XS_SOLID_NURBS_geometry_with_BMB’ and it meshed nicely to a mesh named ‘SOLID Mentor XS 7192321v NURBS new mesh algo Fine3’. I have been using the ‘New mesh preview’ meshing algorithm lately and it is much more difficult to get convergence on the ‘New mesh preview’ meshes.
That convergence plot that you show for this 7192321v mesh is typical of my newalgo meshes when I do get them to converge and I have compared results of the newalgo meshes with results from a similar ‘number of volumes’ HexParametric mesh and the newlago results are very close, even with the strange residuals that you show.
As you say, fortunately, the Coefficients and Forces results don’t seem to be funny looking, so I have been ignoring those strange residual plots as long as the force results plot look nice, like this (from the same run as the residuals you show):
I would not believe such a fine structure can be meshed before seeing your exploit. It means that spider webs can be used in SimScale as well. I will be impressed for a while.
K collapses we see in residuals may be linked to an infinitesimal residuals calculations / math module precision / rounding errors or something.
Now I have to get out my magnifying glass to see and analyze the numerics differences give me a moment
To start with, lets looks at Laplacians:
SimScale numerics defaults Laplacians = Cell Limited Linear
SOLID numerics Laplacians = Gauss Linear Corrected
LINES numerics Laplacians = Gauss Linear Corrected
Now, Solvers:
SimScale numerics defaults Solvers=
U is Smooth solver U Smoother is Gauss-Seidel
P is GAMG P Smoother is Gauss-Seidel
k is Smooth solver k Smoother is Gaus-Seidel
w is Smooth solver k Smoother is Gaus-Seidel
SOLID numerics Solvers =
U is Smooth solver U Smoother is Gauss-Seidel
P is GAMG P Smoother is Gauss-Seidel
k is Smooth solver k Smoother is Gaus-Seidel
w is Smooth solver k Smoother is Gaus-Seidel
LINES numerics Solvers=
U is PBiGC
P is GAMG P Smoother is Gauss-Seidel
k is PBiGC
w is PBiGC
Now, Schemes Time Differentiation:
SimScale numerics defaults Schemes Time Differentiation = ALL CellLimited Gauss Linear
SOLID numerics Schemes Time Differentiation = ALL Gauss Linear
LINES numerics Schemes Time Differentiation = ALL Gauss Linear
Now, Schemes Divergence:
SimScale numerics defaults Schemes Divergence = u,k,w are Gauss Linear upwind and others Gauss linear
SOLID numerics Schemes Divergence = u,k,w are Bounded Gauss upwind and others Gauss linear
LINES numerics Schemes Divergence = u is Gauss Linear upwind - k,w are Gauss upwind and others Gauss linear
WOW, looking at all that I am in wonder as to why I changed all those things but, at the time when you are grasping at straws to converge, you do try a LOT of things with recommendations from everywhere.
I make no justifications for the differences, that is just the way they are and all the sim runs have nice stable results…
This is at least forcing me to TRY to get numerics under control again
I am not even sure that the strange residuals of the SOLID 7192321v mesh sim run really have anything to do with numerics, but I did mention my gut feeling earlier…
Just for the heck of it I will try:
On the SOLID sim, the LINES solvers
On the SOLID sim, the LINES Schemes Divergence
If neither of 1 or 2 fixes the SOLID strange residuals, I will try 1 and 2 together on the SOLID sim
Sigh… but I need sleep now
I am looking for nirvana numerics here, that work for NewMeshAlgo and HexParametricAlgo, not sure that they exist…
You are cooking for stellar future, with those solvers, Dale. .
I realize that k collapses can do nothing to results, only k spikes can destroy your simulation. I guess you tested simple solutions already and in projects there are still no place to put notes for ongoing simulations, so that mix of solvers is definitely your magic receipt, not really known even to you. Take a nap, at least!
Yes but that does not mean that these particular sims would not converge nicely on DEFAULT numerics, it is just that when you finally get a good convergence, you tend to stick using the numerics on your next sim so you have to go through all that again ; )
SO, while the strange residuals look better, but not gone, on Trys #2 and #3, their Cl plots were all over the place.
AND, Try #1 has slightly earlier appearance of the strange residual behaviour yet it still has a stable Cl and the Cl last iteration value is nearly identical to the first run Cl value (where the strange residual behaviour was first noted).
Conclusion:
These results somewhat backup my theory that the strange residual behavior is related to my ‘magic’ numerics, but the exact reason eludes me…
So ‘Lines solver’ gives stable results, ‘Lines schemes divergence’ is ‘overshooting’ and it is reflected by forces oscillations.
Mixing both is like mixing two medicines: you could be sure to have iatrogenic effects. Hence such a mixing, even in simulation, should be avoided. Nassim Taleb (Black Swan book and others) proposes a new approach to avoid iatrogenic effects: subtraction medical services (instead of addictive). Patients would be invited to provide a list of things they take already (pills, potions, supplements, etc.) and a doctor will ask them to drop most of those drugs. I agree, but for the moment I do not have even an aspirin handy…
review of how one should set these numbers for a CFD simulation 
I will be impressed for a while. 
, here are the comparisons of ‘residuals and numerics’ between…
.
