.. _knowledge_base_timeStepping: :ref:`timeStepping ` ============================================= :code:`timeStepSize` --------------------- :code:`timeStepSize` prescribes the size of each physical time step. For steady case, there is only one physical time step with :code:`timeStepSize` = :math:`\infty`. For unsteady cases, there are two typical ways for determining the :code:`timeStepSize`: - Based on an expected :ref:`vortex shedding frequency ` - Based on the desired :ref:`angle of rotation per step ` :code:`timeStepSize` = :math:`\infty` activates the steady solver. If a single volume zone with a non-zero :code:`omega` is present in the simulation, setting :code:`timeStepSize` = :math:`\infty` activates a Single Reference Frame simulation. For multiple volume zones with different :code:`omega` values, the Multiple Reference Frame will be used. .. _vortex_shedding_freq: Vortex Shedding Frequency ^^^^^^^^^^^^^^^^^^^^^^^^^^ The vortex shedding frequency can be estimated by: .. math:: f = \frac{St \cdot U_\infty}{D } where :math:`U_\infty` is the freestream speed, :math:`D` is the characteristic length, for example the mean aerodynamic chord, and :math:`St` is the `Strouhal Number `_. An approximation of :math:`St = 0.2` is typically appropriate for most CFD applications. Typically, the physical time step size :math:`\Delta t` is set as: .. math:: \Delta t = \frac{1}{100} \cdot \frac{1}{f} Note that the nondimensional :code:`timeStepSize` in Flow360.json should be: .. math:: \text{timeStepSize} = \Delta t \cdot \frac{C_\infty}{L_\text{gridUnit}} Here is an :ref:`example ` showing how to convert the physical time step size to nondimensional :code:`timeStepSize`. .. _rot_angle_per_step: Angle of Rotation per Step ^^^^^^^^^^^^^^^^^^^^^^^^^^^ If there is a transient BET Line or a sliding interface modeled, then the :code:`timeStepSize` can be calculated from the desired angle of rotation in each physical step. .. table:: Recommended angle of rotation per step for different scenarios. :widths: 50 40 +------------------------------------------------------+---------------------------------+ | Scenario | Angle per :code:`timeStepSize` | +======================================================+=================================+ | Transient BETDisks (i.e., BET Line) | 6 deg/step | +------------------------------------------------------+---------------------------------+ | | Rotor in sliding interface, phase-I: | 6 deg/step | | | Initializing the flow-field with 1st-order solver | | +------------------------------------------------------+---------------------------------+ | | Rotor in sliding interface, phase-II: | 6 deg/step | | | Initializing the flow-field with 2nd-order solver | | +------------------------------------------------------+---------------------------------+ | | Rotor in sliding interface, phase-III: | 3 deg/step | | | Collecting the data with 2nd-order solver | | +------------------------------------------------------+---------------------------------+ | Strong blade-vortex interaction (hover/descent) | 1-2 deg/step | +------------------------------------------------------+---------------------------------+ | Generating high-quality time-resolved animation | 0.5-1 deg/step | +------------------------------------------------------+---------------------------------+ For more information about 1st versus 2nd order solution, see :ref:`orderOfAccuracy `. Once the angle per step is determined, then the :code:`timeStepSize` can be calculated: .. math:: \text{timeStepSize} = \theta \cdot \frac{\pi}{180} \cdot \frac{1}{\text{omegaRadians}} where :math:`\theta` is the angle of rotation in degrees. Note that the :code:`omegaRadians` here is the nondimensional rotation speed, which can be :ref:`easily converted from RPM `. .. _knowledge_base_maxPseudoSteps: :code:`maxPseudoSteps` ----------------------- - For steady cases, :code:`maxPseudoSteps` is typically 5K~10K. If the nonlinear residuals and/or the forces and moments are still changing, the user can always fork the completed case and let it run more pseudo steps. - For unsteady time-accurate cases, :code:`maxPseudoSteps` is typically slightly larger than :code:`rampSteps` so the :code:`final` CFL can be achieved. As shown in the examples below, when :code:`rampSteps` = 10 then :code:`maxPseudoSteps` should be set to 12. If :code:`rampSteps` = 33 then :code:`maxPseudoSteps` should be set to 35. Example :code:`timeStepping` for the 1st-order unsteady cases .. code-block:: javascript "maxPseudoSteps" : 12, "CFL" : { "initial" : 1, "final" : 1000, "rampSteps" : 10 } Example :code:`timeStepping` for the 2nd-order unsteady cases .. code-block:: javascript "maxPseudoSteps" : 35, "CFL" : { "initial" : 1, "final" : 1e+7, "rampSteps" : 33 } For more information about 1st versus 2nd order solution, see :ref:`orderOfAccuracy `. The CFL number will be discussed in the following subsection. .. _knowledge_base_CFL: :code:`CFL` ------------ The CFL number determines the pseudo step size in each physical step. Two different approaches exist in Flow360 to drive the CFL number (which are activated by setting the :code:`type` entry in the CFL section of the JSON file): - :code:`ramp`, where the CFL ramping is defined by the user - :code:`adaptive`, where the ramping is automatically adapted based on the linear residual values. :code:`ramp` ^^^^^^^^^^^^^ The CFL ramping is defined by the user using this approach by setting values for :code:`initial` , :code:`final` and :code:`rampSteps`. The table below shows recommended values for CFL number ramping for steady and unsteady cases. .. list-table:: Recommended CFL ramp up for steady and unsteady cases. :widths: 42 5 22 22 5 :header-rows: 1 * - Example - Type - :code:`initial` - :code:`final` - :code:`rampSteps` * - Simple wing or fuselage, mostly attached linear flow - Steady - 5 - 200 - 100 * - Full aircraft with nonlinear flow, some separation, simple actuator/BET disks - Steady - 1 - 100~150 - 1K~2K * - Full aircraft near onset of stall, large-scale separation, challenging actuator/BET disks - Steady - 0.1~1 - 10~50 - 3K~5K * - Forked/child case - Steady - parent :code:`final` CFL - parent :code:`final` CFL - 1 * - Rotor in sliding interface, 1st-order solver - Unsteady - 1 - 1000 - ~10 * - Rotor in sliding interface, 2nd-order solver - Unsteady - 1 - 1e+5~1e+7 - 30~50 #. For steady cases, :code:`initial` CFL < 1, :code:`final` CFL < 100, :code:`rampSteps` > 3K are considered as conservative. Such conservative values are only recommended for challenging cases. #. For unsteady cases, it is typically recommended to let the nonlinear residuals drop 2~3 orders of magnitude in each physical step. That is why higher :code:`final` CFL and more aggressive CFL ramping values are suggested. #. For unsteady cases running 2nd-order solver, :code:`final` CFL < 1e+5, :code:`rampSteps` > 50 are considered as conservative. Decreasing :code:`rampSteps` and :code:`maxPseudoSteps` within each physical step will decrease the overall cost and runtime. For more information about 1st versus 2nd order solutions, see :ref:`orderOfAccuracy `. .. _knowledge_base_adaptive_CFL: :code:`adaptive` ^^^^^^^^^^^^^^^^^ This approach adaptively adjusts the CFL number with criteria based on the linear residual values. The :code:`adaptive` CFL ramping approach offers several advantages when compared to CFL :code:`ramp`: - The user does not need prior knowledge on the complexity of the simulation in terms of how conservatively or agressively the CFL can be driven. - The :code:`adaptive` CFL will lead to faster convergence, when the user enters too conservative CFL settings in :code:`ramp` - The :code:`adaptive` CFL can prevent divergence when the user enters too agressive CFL settings in :code:`ramp` (when the divergence is related to the time stepping settings, rather than mesh related). - The :code:`adaptive` CFL will lead to deeper residual convergence when the user enters too agressive CFL settings in :code:`ramp`, but the simulation does not diverge. A few aspects must be noted when using :code:`adaptive` CFL: - The :code:`adaptive` CFL compromises solution speed and solution robustness over a wide range of cases in terms of complexity. Therefore, the :code:`adaptive` CFL will not necessarily lead to a faster solution than :code:`ramp` CFL, when the :code:`ramp` CFL settings are optimised. - If the linear residuals are low (below 0.1) when divergence occurs during :code:`ramp` CFL, switching to :code:`adaptive` CFL will not necessarily remedy the issue, as the CFL is adapted based on the linear residual values As the :code:`adaptive` CFL numerical parameters have been optimised over a range of cases in terms of complexity (from 2D aerofoil to complex 3D flows with separation and shocks), a number of optional inputs have been made available to the user to alter the :code:`adaptive` CFL settings. These include :code:`maxRelativeChange`, :code:`convergenceLimitingFactor`, :code:`min` and :code:`max`. :code:`maxRelativeChange` .......................... The :code:`maxRelativeChange` parameter controls the maximum relative change of the CFL number at each pseudo-step, with the default value set to 1.0. Increasing this parameter will therefore let the CFL change more rapidly, speeding up convergence but potentially leading to divergence for more complex cases. Conversely, reducing the value of this parameter constrains the relative change of the CFL number. An example of how the :code:`maxRelativeChange` parameter affects the convergence is shown for the :ref:`ONERA quick-start example `, with the CFL number, non-linear and linear residuals (continuity) convergence shown in :numref:`Fig1_MaxRel_CFLNS`-:numref:`Fig4_MaxRel_NonLinConv`. The :code:`maxRelativeChange` value will affect the convergence speed without affecting the thresholds put on the linear residual in the adaptive CFL algorithm at the initial stages of the run. The same final CFL values will be reached for different :code:`maxRelativeChange` entries at the end of the simulation (if the simulations are ran long enough). If the convergence is slower than expected :code:`ramp` CFL settings, it is recommended to increase the :code:`maxRelativeChange` value. .. _Fig1_MaxRel_CFLNS: .. figure:: Figures/CFL_NS_MaxRelativeChange.png :align: center :width: 80% Navier-Stokes CFL number during the simulation for a range of :code:`maxRelativeChange` values. .. _Fig2_MaxRel_CFLSA: .. figure:: Figures/CFL_SA_MaxRelativeChange.png :align: center :width: 80% Spalart-Allmaras CFL number during the simulation for a range of :code:`maxRelativeChange` values. .. _Fig3_MaxRel_LinConv: .. figure:: Figures/Cont_Linear_MaxRelativeChange.png :align: center :width: 80% Continuity linear residual convergence during the simulation for a range of :code:`maxRelativeChange` values. .. _Fig4_MaxRel_NonLinConv: .. figure:: Figures/Cont_Nonlinear_MaxRelativeChange.png :align: center :width: 80% Continuity non-linear residual convergence during the simulation for a range of :code:`maxRelativeChange` values. :code:`convergenceLimitingFactor` .................................. The :code:`convergenceLimitingFactor` modifies how conservative or aggressive the limitations on the values of CFL are. Smaller :code:`convergenceLimitingFactor` values lead to a more conservative CFL value, whereas larger :code:`convergenceLimitingFactor` values lead to a more aggressive CFL value. The default value is set to 0.25 which is a good compromise between solution speed and robustness across a wide range of cases. An example of how the :code:`convergenceLimitingFactor` parameter affects the convergence is shown for the :ref:`ONERA quick-start example `, with the CFL number, non-linear and linear residuals (continuity) convergence shown in :numref:`Fig5_ConvFactor_CFLNS`-:numref:`Fig8_ConvFactor_NonLinConv`. The :code:`convergenceLimitingFactor` does not affect the initial CFL values (under 250 pseudo-steps in this case), but has an impact on the thresholds of the linear residuals during the adaptive CFL algorithm and CFL numbers reached in the later stages of the simulation. Higher values of :code:`convergenceLimitingFactor` lead to faster convergence of the nonlinear residual but also permit higher values of the linear residual during the simulation. In the case of simulation divergence, it is recommended to reduce the value of :code:`convergenceLimitingFactor` (after checking the mesh quality at the divergence location, see :ref:`knowledge_base_debug_divergence`. .. _Fig5_ConvFactor_CFLNS: .. figure:: Figures/CFL_NS_ConvFactor.png :align: center :width: 80% Navier-Stokes CFL number during the simulation for a range of :code:`convergenceLimitingFactor` values. .. _Fig6_ConvFactor_CFLSA: .. figure:: Figures/CFL_SA_ConvFactor.png :align: center :width: 80% Spalart-Allmaras CFL number during the simulation for a range of :code:`convergenceLimitingFactor` values. .. _Fig7_ConvFactor_LinConv: .. figure:: Figures/Cont_Linear_ConvFactor.png :align: center :width: 80% Continuity linear residual convergence during the simulation for a range of :code:`convergenceLimitingFactor` values. .. _Fig8_ConvFactor_NonLinConv: .. figure:: Figures/Cont_Nonlinear_ConvFactor.png :align: center :width: 80% Continuity non-linear residual convergence during the simulation for a range of :code:`convergenceLimitingFactor` values. :code:`min` ............ The :code:`min` parameter affects the minimum values of the CFL number for the solved equations during the simulation. :code:`max` ............ The :code:`max` parameter affects the maximum values of the CFL number for the solved equations during the simulation. An example use case for when this parameter would need to be modified is when the Spalart-Allmaras solver diverges with a non-physical turbulent eddy viscosity. As the Spalart-Allmaras is a one-equation model compared to the five equations that are solved for the Navier-Stokes solver, the linear residuals for the Spalart-Allmaras solution will usually be much lower, and therefore the CFL will be driven to much higher values, which may prompt reducing the :code:`max` allowable CFL during the adaptive CFL algorithm. Comparison between :code:`ramp` and :code:`adaptive` ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A comparison of the :code:`ramp` and :code:`adaptive` CFL approaches was performed for the :ref:`ONERA quick-start example ` example for a range of settings, with the CFL number, non-linear and linear residuals (continuity) convergence shown in :numref:`Fig9_Ramp_CFLNS`-:numref:`Fig12_Ramp_NonLinConv`. .. _Fig9_Ramp_CFLNS: .. figure:: Figures/CFL_NS_RampvsAdapt.png :align: center :width: 80% Comparison of the Navier-Stokes CFL number during the simulation for adaptive and ramped CFL. .. _Fig10_Ramp_CFLSA: .. figure:: Figures/CFL_SA_RampvsAdapt.png :align: center :width: 80% Comparison of the Spalart-Allmaras CFL number during the simulation for adaptive and ramped CFL. .. _Fig11_Ramp_LinConv: .. figure:: Figures/Cont_Linear_RampvsAdapt.png :align: center :width: 80% Comparison of the continuity linear residual convergence during the simulation for adaptive and ramped CFL. .. _Fig12_Ramp_NonLinConv: .. figure:: Figures/Cont_Nonlinear_RampvsAdapt.png :align: center :width: 80% Comparison of the continuity nonlinear residual convergence during the simulation for adaptive and ramped CFL. Firstly, it must be noticed that divergence is not a key limiter in the CFL values used in this example. For an example where adaptive CFL is used to prevent divergence, see :ref:`knowledge_base_debug_divergence`. It can be seen that the CFL values at the end of the simulation and convergence speed are driven by the :code:`final` (ramp) and :code:`convergenceLimitingFactor` (adaptive) for both algorithms. The adaptive CFL algorithm allows for much higher Spalart-Allmaras CFL values. In general similar behaviour is seen between the :code:`ramp` and :code:`adaptive`, with less conservative settings leading to faster convergence and higher linear residual values. The key benefit of the :code:`adaptive` algorithm is that the CFL will automatically be reduced when the linear residuals are above a given threshold, in many cases preventing divergence. .. Once we have the debug divergence subsection done, add a link to that section I think some hand drawn schematic illustrating the residual patterns could be very helpful