Optimisation for steady-state flows

From Gerris

Revision as of 19:06, 7 February 2008 Traumflug (Talk | contribs) (Added pictures of the surprising results.) ← Previous diff		Revision as of 22:08, 7 February 2008 Traumflug (Talk | contribs) (Added the optimisation of automatically ending calculations.) Next diff →
Line 32:		Line 32:
	<br clear=all>		<br clear=all>
		+
		+	== End the simulation when the state is steady ==
		+
		+	In the same mail thread, Stéphane 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 1e-3 DU
		+
		+	* <code>U</code> 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 <code>DU</code> is finally an 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).

---

Revision as of 22:08, 7 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 speed-ups exist.

Getting rid of advection calculations

In a mailing list thread people agree, a steady-state solution behaves equally to a pure Stokes flow and advection terms are negligible. You can switch them off:

AdvectionParams { 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 withoutadvection a lot later.

End the simulation when the state is steady

In the same mail thread, Stéphane 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 1e-3 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 an 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).