Optimisation for steadystate flows
From Gerris
Revision as of 09:22, 8 February 2008 Traumflug (Talk  contribs) ← Previous diff 
Revision as of 17:05, 9 February 2008 Traumflug (Talk  contribs) (Added example test results for fully implicit solvers.) Next diff → 

Line 66:  Line 66:  
:''Also for Stokes flows, you probably want to use the fullyimplicit diffusion solver to avoid potential oscillations in time in the solution which can appear when using the default CrankNicholson diffusion solver. This decreases the timeaccuracy from secondorder to firstorder but it doesn't matter since you are looking for a steady solution.''  :''Also for Stokes flows, you probably want to use the fullyimplicit diffusion solver to avoid potential oscillations in time in the solution which can appear when using the default CrankNicholson diffusion solver. This decreases the timeaccuracy from secondorder to firstorder but it doesn't matter since you are looking for a steady solution.''  
  Again, it's simple to do so. Remove or comment out your <code>[[GfsSourceDiffusion]]</code> lines, then add a:  +  Lacking time accuracy should have no influence on steadystate flows of higher Reynolds numbers either. Again, it's a simple change. Add a <code>beta = 1</code> term to your <code>[[GfsSourceViscosity]]</code> line, e.g.: 
  [[GfsSourceViscosity]] {} 1 { beta = 1 }  +  [[GfsSourceViscosity]] 4.024e5 { beta = 1 } 
  [[User:TraumflugTraumflug]] 15:21, 7 February 2008 (PST) I have yet to reread what's the difference between GfsSourceDiffusion and GfsSourceViscosity, as only one of both is allowed. Additionally, running the example and comparing the results is yet to be done. In a first test, automatically ending the simulation suddenly worked and everything was done after only 3 time steps. Also, check the second part wether changing the line with GfsTime is neccessary or wether GfsEventStop has a higher precedece.  +  For comparison, I've run my favourite example with a Reynolds number of 2485 (water at 0.5 m/s) with both solvers: 
+  
+  [[Image:Doppelbogenwatervelocity.pngthumbleftCrankNicholsen solver]]  
+  [[Image:Doppelbogenwatervelocitynontimeaccurate.pngthumbleftfullimplicit solver]]  
+  
+  Wall clock time needed for the calculation the same within few seconds (of 4500 seconds). Results are the same within 2% accuracy. The timeaccurate version appears to have a slightly lower Reynolds number.  
+  
+  <br clear=all>  
+  
+  It looks like the fully implicit solver doesn't change anything in normal situations. Nonetheless, it might help in some border cases. 
Revision as of 17:05, 9 February 2008
Often, you're not particularly interested in how a flow or stream develops over time, but only how the constant flow behaves if it exists long enough to have all initial reactions and changes settled. While Gerris isn't optimised for such calculations, a few simplifications and speedups exist.
Contents 
Getting rid of advection calculations
In a mailing list thread people agree, a steadystate solution at very low Reynolds numbers (Re << 1) behaves equally to a pure Stokes flow and advection terms are negligible. You can switch them off:
GfsAdvectionParams { scheme = none }
For an example, see the Couette flow test case.
To give the removal of advection evidence, I've run the example from An engineer's pipe flow with the viscosity of water and up to time t = 1.1 (with advection it's divergent at t = 1.107) with and without advection:
With advection, the calculation time was 4436 seconds. Without advection, this shortened to just 77 seconds.
As you can see, there are pretty big differences.
A tenth of fluid domain time later, the advection version appeard to "explode". Shortly thereafter, the timestep goes down to almost zero and stays there forever.
Just for Info, the same flow without advection a lot later.
End the simulation when the state is steady
In the same mailing list thread, Stéphane Popinet shows how to stop simulation as soon as a steady state is reached. This optimisation won't decrease computing time of the simulation, but will end it automatically without watching you how the flow develops.
In your calculation script, remove the end time and insert an GfsEventStop. The result could look like this:
GfsTime { } GfsEventStop { istep = 1 } U 1e3 DU

U
is the variable to watch. Variables other than velocity should work as well.  The number behind this is the threshold (difference to previous value) at which the simulation is stopped when reached.
 The
DU
is finally a new, optional variable where the current difference is put in.
You can also add an additional
GfsOutputScalarNorm { istep = 1 } stdout { v = DU }
to watch this variable and how the velocity changes get fewer and fewer from step to step.
With this optimisation the simulation stops at a fluid domain time of 7.8 or a CPU time of 540 seconds and the results should be within a 1% accuracy of what you can reach.
 Nota Bene: It's a simulation after all and if a simulation would fit reality within a 1% accuracy, this would be stunning.
Pause
The above is wrong. GfsEventStop didn't stop the simulation at all. Because advection was turned off? The Couette flow script isn't a good measure as this simulation has a second stop condition (iend=100).
Using a different solver
The third point Stéphane made in this thread belongs to the type of solver. He writes:
 Also for Stokes flows, you probably want to use the fullyimplicit diffusion solver to avoid potential oscillations in time in the solution which can appear when using the default CrankNicholson diffusion solver. This decreases the timeaccuracy from secondorder to firstorder but it doesn't matter since you are looking for a steady solution.
Lacking time accuracy should have no influence on steadystate flows of higher Reynolds numbers either. Again, it's a simple change. Add a beta = 1
term to your GfsSourceViscosity
line, e.g.:
GfsSourceViscosity 4.024e5 { beta = 1 }
For comparison, I've run my favourite example with a Reynolds number of 2485 (water at 0.5 m/s) with both solvers:
Wall clock time needed for the calculation the same within few seconds (of 4500 seconds). Results are the same within 2% accuracy. The timeaccurate version appears to have a slightly lower Reynolds number.
It looks like the fully implicit solver doesn't change anything in normal situations. Nonetheless, it might help in some border cases.