TIME_SEQUENCE

Specifies the time stepping and staggering strategy.

Type

AcuSolve Command

Syntax

TIME_SEQUENCE {parameters}

Qualifier

This command has no qualifier.

Parameters

min_cases >=0 [=1]: Minimum number of optimization cases allowed for the run.
max_cases >=0 [=50]: Maximum number of optimization cases allowed for the run.
optimization_convergence_tolerance >=0 [=1.e-4]: A necessary condition for the termination of an optimization run is that all convergence measures must be less than this tolerance.
final_time (real) >=0 [=0]: Final time of the run. The run will terminate when the analysis time reaches the final time. The run may terminate earlier due to other criteria. If zero, this option is ignored.
min_time_steps or min_steps (integer) >=0 [=1]: Minimum number of time steps before terminating a run due to convergence to steady state, or ending a case if multiple cases are used in a run.
max_time_steps or max_steps (integer) >=0 [=1]: Maximum number of time steps allowed for a run or a case. The run may terminate, or the case may end, earlier due to other criteria. If zero, this option is ignored.
initial_case_time_steps (integer) >=0 [=0]: Minimum number of time steps used for the initial case. This option will also override the max_time_steps parameter for the initial case. If zero, this option is ignored.
convergence_tolerance or conv_tol (real) >=0 [=1.e-4]: Steady-state convergence tolerance. The run will terminate if all convergence measures within a time step are less than this tolerance. This criteria requires that at least min_time_steps time steps are solved and that termination_delay consecutive time steps have passed while satisfying the convergence tolerance.
termination_delay or exit_delay (integer) >=0 [=0]: Minimum number of consecutive time steps in which the steady-state convergence criteria must be satisfied before terminating the run. A value of zero results in the same behavior as one.
lhs_update_initial_times or lhs_init_steps (integer) >=0 [=1]: The number of initial time steps in which the left-hand-side (LHS) matrices of all staggers are discarded at the start of every time step.
lhs_update_frequency or lhs_freq (integer) >=0 [=0]: The time step frequency at which the left-hand-side (LHS) matrices of all staggers are discarded at the start of such time steps. If zero, this option is ignored.
min_stagger_iterations or min_stg_iters (integer) >=0 [=1]: Minimum number of stagger iterations before advancing to the next time step. If zero, this option is ignored.
max_stagger_iterations or max_stg_iters (integer) >=0 [=1]: Maximum number of stagger iterations before advancing to the next time step.
stagger_convergence_tolerance or stg_conv_tol (real) >=0 [=1.e-4]: Time step convergence tolerance. The stagger iteration is terminated when all convergence measures within the stagger iteration are less than this convergence tolerance and at least min_stagger_iterations has been solved.
stagger_lhs_update_frequency or stg_lhs_freq (integer) >=0 [=0]: The stagger iteration frequency at which the left-hand-side (LHS) matrices of all staggers are discarded at the start of such staggers. If zero, this option is ignored.
staggers or stgs (list) [no default]: List of staggers to be executed. Staggers are solved in the specified sequence.
allow_stagger_reordering or stg_reorder (boolean) [=off]: Allow AcuSolve to change the stagger order to optimize solution stability.

Description

This command specifies the time stepping and stagger iteration strategy and parameters.

A time marching method is used to obtain solutions for both steady-state and transient problems. Little distinction is made between the two. For steady state problems, you may consider the time stepping algorithm as a fancy nonlinear iteration loop. A predictor multi-corrector scheme is used within each time step. The predictor is performed at the beginning of each time step and correctors are performed within the staggers. Staggers are used to solve for a subset of equations present in the problem. Within each stagger, the residual and the left-hand-side (LHS) matrix of the specified equation system is formed, the resulting linear equation system is solved and the solution is updated (corrected). These steps define a set of nested loops which are used to advance the solution. A pseudo code of the time stepping strategy is shown below:

Loop over time steps
   Predict all active solution fields
   Loop over staggers
      Stagger 1:
         Loop over nonlinear iterations
            Form stagger residual and if needed LHS matrix
            Solve linear equation system
            Update stagger solution field(s)
            Check nonlinear convergence
         End nonlinear loop
      ...
      Stagger N:
         Loop over nonlinear iterations
            Form stagger residual and if needed LHS matrix
            Solve linear equation system
            Update stagger solution field(s)
            Check nonlinear convergence
         End nonlinear loop
      Check stagger convergence
   End stagger loop
   Check time step convergence
   Optionally compute and output results
   Determine time increment of the next time step
End time step loop

The loops over the time steps and staggers and the sequence of staggers are controlled by the TIME_SEQUENCE command. The loop over each stagger's nonlinear iterations, formations, and solution of stagger equations is controlled by the STAGGER command. The selection of the time increments is controlled by the TIME_INCREMENT command. The predictor multi-corrector parameters are controlled by the TIME_INTEGRATION command. Convergence checking parameters that are common to all staggers are set in the CONVERGENCE_CHECK_PARAMETERS command. Linear solver parameters that are common to all staggers are set in the LINEAR_SOLVER_PARAMETERS command.

The loop over the time steps terminates when one of the following occurs:

Analysis time exceeds the final_time.
max_time_steps time steps are solved.
All convergence measures of the last termination_delay+1 time steps are below the convergence_tolerance and a minimum of min_time_steps time steps is solved.
User signals termination.
A fatal error occurs.

The loop over the staggers terminates when one of the following occurs:

max_stagger_iterations stagger iterations are performed.
min_stagger_iterations stagger iterations are performed and the last set of convergence measures fall below stagger_convergence_tolerance.

The staggers parameter defines the list of staggers to be solved. For example, to solve a turbulent thermal flow problem, you may specify:

TIME_SEQUENCE {
   staggers                  = { "flow", "turb", "temp" }
   ...
}
STAGGER( "flow" ) {
   equation                  = flow
   ...
}
STAGGER( "temp" ) {
   equation                  = temperature
   ...
}
STAGGER( "turb" ) {
   equation                  = turbulence
   ...
}

Here the "flow" stagger is solved first for the flow equations, then the "turb" stagger is solved for the turbulence equation and then the "temp" stagger is solved for the energy equation. A stagger may be repeated multiple times. For example,

TIME_SEQUENCE {
    staggers                 = { "flow", "turb", "flow","temp" }
    ...
}

solves the "flow" stagger before and after the "turb" stagger.

The LHS matrix of a stagger is computed only if it does not exist. Therefore, to force the formation of a LHS matrix, the solver simply discards the current one. The LHS matrices of the staggers are discarded at the beginning of the initial lhs_update_initial_times time steps. In addition, the LHS matrices of the staggers are discarded at the beginning of every lhs_update_frequency time steps and stagger_lhs_update_frequency stagger iterations. For example, given:

TIME_SEQUENCE {
    lhs_update_initial_times           = 10
    lhs_update_frequency               = 6
    stagger_lhs_update_frequency       = 3
    min_stagger_iterations             = 1
    max_stagger_iterations             = 3
}

the LHS matrices are discarded at the beginning of the first 10 time steps, plus every 6 time steps starting from time step six. In addition, a minimum of one and a maximum of three stagger iterations are performed per time step. If iteration three is required, then the LHS matrices are discarded prior to this iteration.

Convergence checks are performed on the residual and solution increments. For the residual, the norm of the residual is normalized with respect to the norm of the forces making up the residual. This ratio is the relevant measure, because it measures the ratio of the out-of-balance forces to the value of the forces. This ratio is computed separately for each solution field. For the solution increment, the norm of the solution increment is normalized with respect to the norm of the solution field prior to updating the solution. This ratio is also computed separately for each solution field. These ratios are used to check for convergence. Convergence occurs when all residual and solution increment ratios fall below the specified tolerance. The CONVERGENCE_CHECK_PARAMETERS command may be used to control the relative importance of each ratio.

For a steady-state problem, you typically use the time stepping algorithm as a nonlinear iteration strategy. Hence, a single pass through the staggers is typically used. To accelerate convergence the LHS matrix is reformed at every nonlinear iteration. Below is a typical setup:

TIME_SEQUENCE {
    final_time                         = 0
    min_time_steps                     = 0
    max_time_steps                     = 100
    convergence_tolerance              = 1.e-3
    termination_delay                  = 0
    lhs_update_initial_times           = 0
    lhs_update_frequency               = 1
    min_stagger_iterations             = 1
    max_stagger_iterations             = 1
    stagger_convergence_tolerance      = 1.0
    stagger_lhs_update_frequency       = 0
    staggers                           = { "flow", "turb", "temp", "spec1" }
}
STAGGER( "flow" ) {
    equation                           = flow
    min_stagger_iterations             =1
    max_stagger_iterations             =1
    ...
}
...

Transient problems are solved with either fixed or variable number of stagger iterations. The CPU cost of reforming the LHS matrices is typically small. Since frequent reformation of the LHS matrices enhances nonlinear convergence, you usually benefit by doing so. If very small time increments are used, one may wish to reform the LHS matrix less often. A fixed iteration count transient problem may be set up as follows:

TIME_SEQUENCE {
    final_time                         = 1800
    min_time_steps                     = 0
    max_time_steps                     = 100
    convergence_tolerance              = 0.0
    termination_delay                  = 0
    lhs_update_initial_times           = 0
    lhs_update_frequency               = 1
    min_stagger_iterations             = 2
    max_stagger_iterations             = 2
    stagger_convergence_tolerance      = 1.0
    stagger_lhs_update_frequency       = 1
    staggers                           = { "flow", "turb", "temp", "spec1" }
}
STAGGER( "flow" ) {
    equation                           = flow
    min_stagger_iterations             = 1
    max_stagger_iterations             = 1
    ...
}
...

A transient problem with convergence tolerance control may be set up as follows:

TIME_SEQUENCE {
   final_time                          = 1800
   min_time_steps                      = 0
   max_time_steps                      = 100
   convergence_tolerance               = 0.0
   termination_delay                   = 0
   lhs_update_initial_times            = 0
   lhs_update_frequency                = 1
   min_stagger_iterations              = 1
   max_stagger_iterations              = 4
   stagger_convergence_tolerance       = 1.e-3
   stagger_lhs_update_frequency        = 1
   staggers                            = { "flow", "turb", "temp","spec1" }
}
STAGGER( "flow" ) {
   equation                            = flow
   min_stagger_iterations              = 1
   max_stagger_iterations              = 2
   convergence_tolerance               = 1.e-3
   ...
}
...

In a Direct Coupling Fluid Structural Interaction (DC-FSI) problem, a stagger is added for the solution of the solid/structural part by an external code:

TIME_SEQUENCE {
   ...
   staggers                            = { "abaqus", "flow", "turb", "temp", "spec1" }
}
STAGGER( "abaqus" ) {
   equation                            = external_code
   ...
}

See the EXTERNAL_CODE command for details on DC-FSI problems.

In a coupled particle-flow problem, a stagger is added for the solution of the particle equations by AcuTrace:

TIME_SEQUENCE {
   ...
   staggers                            = { "flow", "particle" }
}
STAGGER( "particle" ) {
   equation                            = particle
}

For some applications, the order in which the staggers are solved can have a significant impact on the stability of the simulation. For example, applications involving fluid-structure interaction benefit from solving the mesh stagger first. However, for applications involving free surfaces, the flow equations should be solved first. The allow_stagger_reordering option lets AcuSolve override the stagger order that you specified to create a stagger order with optimal stability for the given application. This parameter only has an impact on the behavior of the solver when a moving mesh simulation is performed.

Consider a practical fluid-structure interaction simulation where you have given the following stagger order:

TIME_SEQUENCE {
   staggers                       = { "flow", "turb", "mesh" }
   allow_stagger_reordering       = on 
   ...
}

If allow_stagger_reordering=on, AcuSolve will first check to see if the mesh equation is active. If it is, it then checks to see if there are any free surface boundary conditions present in the simulation. If free surfaces exist, the stagger sequence is ordered such that the flow stagger is solved first. If no free surfaces are present, then the stagger sequence is ordered such that the mesh stagger is solved first. Note that the default solution strategy created by the AUTO_SOLUTION_STRATEGY command will set this option to off unless mesh=arbitrary_lagrangian_eulerian.