Requirements for Restarting

OptiStruct currently supports restart functionality for Nonlinear Analysis and Optimization. The following sections provide specific information regarding the procedure to implement restart.

Restart of Nonlinear Analysis

Typical use cases for restarting a nonlinear analysis are:
  1. Restart from the last point at which the initial run was interrupted (for example, due to a power outage).

    Example:

    If a 3-subcase model with RESTARTW was interrupted due to power outage during the solution of subcase 2, after the 13th increment, the following can be added to the model to restart it. 
    RESTARTR = originaljob_sub2_inc0013
    This will restart the model from the interruption point (end of increment 13), and the load history of Subcase 2 from increment 13 will be continued.


    Figure 1. Example: Restart after a Power Outage
  2. Restart from some point of a successful nonlinear analysis and append new nonlinear subcases in continuation.

    Example:

    If a 3-subcase model with RESTARTW completed successfully, but now you want to replace subcase 3 with a different subcase and also add a new subcase 4. Then you can revise the 3-subcase model by adding subcase 4 and make required changes to subcase 3.

    If the final increment of subcase 2 is increment 21, use:
    RESTARTR = originaljob_sub2_inc0021
    This will restart the model from the end of subcase 2 (beginning of subcase 3) and both revised subcase 3 and new subcase 4 will be run.


    Figure 2. Example: Revise an Existing Subcase and Append a New Subcase
  3. Restart from some point of a nonlinear analysis, truncate the nonlinear subcase at that point and append new nonlinear subcases in continuation. (This can be accomplished using the TERMI option on RESTARTR Bulk Data Entry).

    Example:

    If a 3-subcase model with RESTARTW was interrupted after the 13th increment of Subcase 2. If you want to restart the run, but now you want to discard the rest of the load history of subcase 2, from the restart point, then use the TERMI option.

    If the increment at which the subcase 2 was terminated is increment 13, use:
    RESTARTR = TERMI,originaljob_sub2_inc0013

    This will abandon the remaining load history from the restarting point for subcase 2, and subcase 3 will now append to the restarting point. So subcase 3 is now a different loading path.

    When TERMI is specified, OptiStruct will abandon the remaining load history from the restarting point (original run). And then append new loading history continuing from the restarting point in the restart run.


    Figure 3. Example: Abandon Remainder of Subcase 2 after a Power Outage

    For the 3-subcase example, assuming the load histories (in total time) are:

    1st Subcase → [0 – 1s], 2nd Subcase → [1 – 2s] and 3rd Subcase → [2 – 3s].

    If the run gets terminated at 1.3s of 2nd subcase, with TERMI, the remaining load history from [1.3s – 2s] for subcase 2, will be abandoned. And subcase 3 will now append to the restarting point (1.3s) and then [1.3 – 2.3s] is the range of total time for the restarted subcase 3. This subcase 3 is now essentially a different loading path (with original loading of subcase 3, but starting from nonlinear state/restarting point of 1.3s).

    If TERMI is not specified, OptiStruct will continue to finish [1.3 – 2s] of subcase 2 and then continue to [2 – 3s] of subcase 3.

    The restart analyses with and without TERMI generally lead to different loading paths and different results.

  4. Restart from some point of a successful nonlinear analysis and append new linear STATSUB(BUCKLING/PRELOAD/BRAKE) subcases. The linear STATSUB(BUCKLING/PRELOAD/BRAKE) subcases should reference the ending nonlinear subcase.

    Example:

    If a 3-subcase model with RESTARTW completed successfully, but now you want to add a new subcase 4, which is a Linear subcase with STATSUB(BUCKLING/PRELOAD/BRAKE).

    If the final increment of subcase 3 is increment 25, use:
    RESTARTR = originaljob_sub3_inc0025


    Figure 4. Example: Append a Linear Subcase with STATSUB
    This will restart the model from the end of subcase 3 (beginning of subcase 4) and the new subcase 4 (linear subcase) will be run.
    Note: In this case, the STATSUB entry in linear subcase 4 should point to the final nonlinear subcase in the chain (which is subcase 3 for this example).
Table 1. Procedure to Restart a Nonlinear Analysis Run with RESTARTW and RESTARTR Entries
Run Input Files Output Files
Run 1

(Initial run)

 Run1.fem

(With RESTARTW)

 Run1.out, Run1.h3d and so on.

Run1.rmd (model information file)

Run1_subi_incj.rnl (analysis information file)
Run 2

(Restarted from Run 1)

 Run2.fem

(With RESTARTR and RESTARTW)

Run1.rmd

Run1_subi_incj.rnl

 Run2.out, Run2.h3d and so on.

Run2.rmd (model information file)

Run2_subi_incj.rnl (analysis information file)
Run 3

(Restarted from Run 2)

 Run3.fem

(With RESTARTR and RESTARTW)

Run2.rmd

Run2_subi_incj.rnl

 Run3.out, Run3.h3d and so on.

Run3.rmd (model information file)

Run3_subi_incj.rnl (analysis information file)
To restart a nonlinear analysis, you will need model information and analysis information of the previous interrupted run. This information is stored in .rmd and .rnl files in binary format.
  • In an original job with RESTARTW command defined in the input deck, OptiStruct writes one restart model information file (*.rmd) and one or more restart analysis information files (*.rnl) for the nonlinear analysis increments.
  • In a restart job with RESTARTR command defined in the input deck, OptiStruct reads a restart model information file (*.rmd) and a restart analysis information file (*.rnl) to retrieve the data needed for restart.
For the first use case, that is, restarting from an interruption due to a power outage and so on, the input decks of the original and restart runs should be identical except for the RESTARTR and RESTARTW commands. For the other use cases, the input deck of the restart run should include all the fully/partially analyzed nonlinear subcases and all the Bulk Data Entries in the input deck of the original run, and, definitions of the inherited nonlinear subcases and Bulk cards should not change; it may include new nonlinear subcases or linear STATSUB(BUCKLING/PRELOAD/BRAKE) subcases; and it may include new Bulk Data Entries listed below:
  • SPCADD, SPC, SPC1
  • LOADADD, FORCE
  • DLOAD, TLOAD1, TLOAD2, RLOAD1, RLOAD2, DAREA
  • NLPARM, NLADAPT, NLMON, NLOUT, TSTEPNL, TSTEP, SOLVTYP
  • CNTSTB, MODCHG
  • EIGRL, EIGRA, EIGRC
  • FREQ, FREQ2
  • TABLED1, TABLED2, TABLED3, TABLED4

Restart of Optimization

It is possible to restart an OptiStruct optimization by using the command line option -restart (Run Options), by adding the I/O Options Entry RESTART to the input file, or from the OptiStruct panel in HyperMesh.

To restart an optimization, you will need information about the final iteration of the previous optimization run. This information is stored in the .sh file.

The DESMAX entry on the DOPTPRM Bulk Data Entry, in the .fem file, specifies the maximum number of additional iterations. To perform an analysis on the optimized structure, restart with DESMAX set to 0. If DESMAX is not defined, the default value of DESMAX is assumed (30 iterations is the default value for DESMAX unless topology manufacturing constraints are used, in which case the default is 80 iterations).

There are a number of conditions that must be observed when restarting an optimization:
  • The number of design variables or design elements cannot be changed.
  • It is invalid to restart with minimum member size control removed, if it was present in the original run.
  • It is invalid to restart with checkerboard control turned on, if it was not activated in the original run. It is, however, acceptable to deactivate checkerboard control in the restart, if it was activated in the original run.
  • It is invalid to restart with manufacturing constraints that differ from those of the original run.

The purpose of the restart functionality is for restarting with unconverged optimization runs or optimization runs that were terminated before completion (due to a power outage, machine crash, etc.).

Output files from a restart run are appended with the extension _rst#, where # is a 3 digit number indicating the starting iteration for the restart run. For example, filename_rst030.out is the .out file created when restarting filename.fem from iteration 30.

Iterations for the restart are numbered starting with the iteration number in the .sh file (the last iteration from the previous run).

You may manually append new .dens, .disp, and .strs files to old ones and post-process the combined files.

Advanced Restart for Topology Optimization

You may require to restart a topology optimization from the previous optimization run, but with modified model data, for example – refining mesh in design domain, modifying the design space, changing the manufacturing constraints, and so on. Restarting topology optimization with modified mesh or configuration can be accomplished via the advanced restart option.

In order to use the topology advanced restart feature, DOPTPRM,TOPDV,ALTER should be added to the original topology run. Topology design variables will be generated by an alternate method to prepare for the advanced restart. For the restart run with different mesh or configurations, DOPTPRM,TOPRST,ADVNOR/ADVRES should to be added.
  • DOPTPRM,TOPRST,ADVNOR option allows the restart run with modified mesh and/or configuration, while carrying over the penalty from the original run.
  • DOPTPRM,TOPRST,ADVRES option allows the restart run with modified mesh and/or configuration with reset penalty.