Moving past linear solutions and their restart capabilities as investigated in this previous post, we will today turn to Simcenter Nastran’s nonlinear solutions SOL401 and SOL402, and how their restarts function in Simcenter 3D (SC3D):
In the nonlinear solutions, restarts can be used to create checkpoints in your analysis for load cases which individually could cause nonlinear effects such as plastic deformation, or large sliding in contacts to mention a few. These restart opportunities let you save computation time by not solving the same load cases several times. Additionally, they can add redundancy for long simulations if you can restart from an intermediate step instead of beginning anew. In this post we will look at how these restarts are set up in SC3D.
SOL401 Restart Procedure
As a start we are required to create an initial run which is the solution and subcase from which we want to restart. This run can contain any dynamic, structural or preload subcase. Note however, that four types of subcases are not applicable to use in an initial run:
- Modal
- Cyclic
- Fourier
- Nonlinear buckling
An example of an initial run is to create a preload subcase which then can be used in a number of subsequent restart solutions (the solutions continuing from an initial solution) so that the preload is not required to be solved for in every solution. A restart solution will then be able to continue from any of the completed subcases in the initial run. We will see that there is also a way of restarting a non-converged subcase.
Restart File Generation
Before solving the initial run we need to have SC3D instruct Nastran to save the restart information to the .op2 file. To do this the initial solution must be edited in SC3D by active Solution → right clicking → Edit (1) → Restart Management (2), as seen in the below picture:
Modifying the Generate Restart Data=Yes will specify that restart information is saved on the .op2 file. This option is handled by the NLCNTLG bulk entry in the input file, which for the initial run should state RSTGEN YES.
Restarting from the Initial Solution
Having solved the initial case, we will have the prerequisites to create a restart solution. When creating a restart solution, one important thing to notice with SC3D is that when creating subcases, they will be numbered sequentially per solution starting from 1. This can be seen in the solver input, .dat, file created by SC3D before solving:
This must be kept in mind when wanting to restart from a solution, since we could run into the special case of wanting to restart from a subcase with the same ID as the subcase we want to execute. Take the example above: say Solution A with a subcase sc_1-PREL (ID=1) is used in an initial run and Solution B with sc_1-LOAD-3 (ID=1) is used as the execution case. This is that special case mentioned previously, which is only intended for restarting a non-converged solution.
To avoid having the same ID in the subcases, a way to handle this in SC3D is to add subcases before the subcase you want to restart from to increase the subcase ID (with no intention of solving these subcases). Following the workflow in the picture below, this can be done by active Solution → right click → New Subcase → Create Step (1); From the Solution Step window you can decide the number of steps to create and where in the subcase order to place them (2) and then these will be placed in the active solution (3).
An alternative is to edit the input file prior to solving the solution; making sure that the SUBCASE in the case control section of your restart file input deck will have matching ID with the EXEFROM parameter on the NLCNTLG bulk entry.
Now to define the restart case we once again need to edit the restart solution active Solution (1) → right click → Edit → Restart Management (2). Depending on the Execute Subcase Method and the Restart Option the Restart Parameters will look slightly different. It all comes down to deciding upon a result file to be used as initial solution (Restart File), and to decide the subcase in this file which will be used to restart from (Restart Subcase) as well as deciding upon a subcase in the restart solution to execute from (Execute Subcase): i.e. which step that is to follow the restarted subcase.
Note, that if you have a restart solution with the same name as the initial solution that produced the .op2 file, you will overwrite that restart file if it lies in the run directory… Additionally, the recommendation for SOL401 is to always execute the restart solution (EXEFROM) using a subcase with a higher ID than the initial run subcase (RSTFROM).
The Model Validation for Restart Run is a model check that the input file of the restart solution is compatible with the initial run. It concerns the topics seen in the picture below were for SOL401 in general this check will result in a fatal error if e.g. new nodes have been added or if elements have been removed from the input file. What is allowed regarding elements is the birth/death addition, or removal, of them within a subcase. If you still want to execute the analysis having performed changes not allowed by the model check, you can set it to off and run anyway. Just be sure to review your results afterwards…
Having the restart solution set up there is one final thing to consider: Just as for regular dependent subcases the end time of the subcase in the restart solution must be higher than the end time of the initial subcase used for restarting.
The procedure described above is shown in the video below where a restart from a preload subcase is made so look at plastic strain in a friction joint fastener:
Restarting a Non-Converged Subcase
Should you be in a situation where a subcase does not converge while you still retain restart files from it, a possibility is to create a new solution (e.g. cloning the solution) and restart from that subcase. As stated previously, you are then required to use the same ID in the Restart Subcase and the Execute Subcase entries.
Additionally for this type of restart you cannot change anything else but solution control parameters on the bulk entry NLCNTL (error tolerances, maximum number of bisections etc.) and the time step intervals defined in the bulk entry TSTEP1 (number of increments). The end time must still be the same in the initial and the restart run.
SOL402 Restart Procedure
Internal Restart
Exclusively for SOL402 is that you can choose to create an “internal restart”. Meaning that you combine the capability of disabling the sequential dependence between subcases with a state of the structure from a specified time, but now, in the same solution.
This reduces the need of creating several solutions if the desire is to investigate several states in parallel. Below you can see how such a restart is activated in SC3D where the restart case needs to be edited to disable the sequential dependency and to set the initial case ID (RSUB on the NLCNTL2 bulk entry).
Restart subcase → right click → Edit (1) then in the Solution Step (2) window set Sequential Dependency on Previous Subcase = No. Next to specify which subcase to restart from the RSUB parameter is set by creating Nonlinear Control Parameters → Create Modeling Object and there under Restart Options (3) set RSUB = 1, or to whatever ID the initial subcase has.
To make the workflow clearer you can review the video below showing how to setup an internal restart in SOL402.
External Restart
The so-called “external restart” for SOL402 is very similar to what is described in the SOL401 restart procedure where subcases from one solution are reused in another as initial states.
To structure a restart in this manner you would have to create an initial solution which generates restart files. A difference between SOL401 and SOL402 is that for SOL402 data is not only saved in the output OP2 file. Additionally, the Samcef .sdb and .adb files, as well as the Samcef output .u18 file are saved for restart purposes. Acquiring these files is done in the same way as for SOL401 in SC3D by editing the solution under Restart Management.
Having generated restart files, a path to the .op2 file of the initial solution is necessary and then the restart and execution subcases need to be specified.
The SOL402 restart does not allow for as many changes as the SOL401 and the Model Validation for Restart Run is in this case obsolete, it is not applicable to SOL402 restarts. Solution parameters and boundary conditions can, to some extent, have changed numerical values, but that is as far as it goes.
Final Notes
For both SOL401 and SOL402 the file in the initial run should be created in the same release of SC3D (v2412.xxxx, v2406.xxxx, v2312.xxxx etc.) as the version the restart case is to be solved in for best compatibility. Otherwise, changes may have been introduced to the .op2 file format which can make it impossible to run the restart analysis. However, DMP and parallel settings between the initial and restart run can differ.
For this post I used Simcenter 3D version 2412.6000 and I hope it was of use to you. If you find yourself stuck and in need of a restart, contact us at support@volupe.com.
Viktor Hultgren, M.Sc.
Contact: support@volupe.com
+46 704 21 06 61
