ABAQUS

Finite Element Analysis software for modeling, visualization and best-in-class implicit and explicit dynamics FEA.

ABAQUS Licensing

ABAQUS is licensed using a combination of Execute Tokens (for compute jobs) and Interactive Seats (for running an ABAQUS graphical user interface). Advanced Research Computing fund 175 Execute Tokens and 16 Interactive Seats for general use on BlueBEAR. Research groups can also purchase their own licences in order to guarantee access to ABAQUS tokens or seats.

The number of Execute Tokens required is dependant on the number of cores being used. For standard tokens, this relationship is given as follows:
int(5 x N^0.422)
... where N = number of cores (equivalent to --ntasks in Slurm)

An overview of the Execute Tokens required is given in the following table:

Note that if the required number of tokens is unavailable when a job begins, ABAQUS will continue to query the licence server for 1 minute. If after this time no licences become available then the job will terminate – this is to ensure that computational resources don't sit idle.

Disk Usage

ABAQUS can create very large output files, especially the output database (.odb) and the restart files, including the .stt file. The following guidelines have been suggested by the suppliers to reduce the disk space required for typical runs:

• The default value of the max_history_requests in the environment file has been set to 100. This parameter specifies the maximum number of history requests allowed in an ABAQUS analysis. History output in ABAQUS is intended for relatively frequent output requests for small portions of a model and is displayed in X/Y plots in the Visualisation module of ABAQUS/CAE. Requesting large amounts of history output will cause performance problems in both analysis and post-processing of an ABAQUS job. For vector- or tensor-valued output variables, each component is considered to be a single request. In the case of element variables, history output will be generated at each integration point. For example, requesting history output of the tensor variable S (stress) for a C3D10M element will generate 24 history output requests: (6 components)*(4 integration points). When requesting history output of vector- and tensor-valued variables, it is recommended that individual components be selected where applicable. In cases where large amounts of history output are required, it is recommended that the data be written to the output database (.odb) as field output from which history data can be extracted using the Visualisation module of ABAQUS/CAE
• If the *RESTART parameter is used to request restart information, specify the OVERLAY parameter, to specify that only one increment should be retained per step, thus minimising the storage space needed. For example, specify *RESTART, WRITE, INC=2, OVERLAY to write the restart file every 2 increments per step but only retain the last values, in case a restart is required due to, for example, a system failure. Note that specifying a low value for the INC parameter will have an adverse effect on the performance of the job since it will entail additional input/output operations. The size of any files associated with the RESTART request is estimated by the analysis input file processor in an ABAQUS/Standard analysis.

Other Information

• ABAQUS/CAE requires Exceed3D if you are logged in from a Windows-based PC since it uses OpenGL graphics.
• Direct submission of analysis jobs from within CAE is not available; CAE must be used to generate the input files which are then submitted using the batch system as described above.
• ABAQUS requires a large amount of scratch disk space, in addition to the space needed for permanent files. If the scratch space fills up ABAQUS will issue an error, probably saying that it is unable to write to unit 2. ABAQUS has been configured to use scratch space on the local disk on the node(s) on which the job is running. If this happens, these files can be redirected to the same directory that the job is submitted from, but this may significantly increase the wall time for the job. To do this, specify: scratch=$PWD on the ABAQUS command line.
• To avoid conflict with these scratch files, user-defined subroutines should only use unit numbers 15-18 or unit numbers greater than 100.

User-defined Subroutines

To run a job using the input file myjob.inp and user-defined routine myroutine.f:

abaqus job=myjob user=myroutine

A common source of problems with user-defined subroutines is the use of uninitialised variables and/or writing outside an array bound. The command used to compile these routines can be changed to add compiler options to introduce additional checks; note, however, that this checking can greatly extend the size of the compiled file and/or the time taken to run the code and so should only be used during the development of such subroutines. To add this checking, add the following line to a file abaqus_v6.env in the same directory as the input file:

compile_fortran = ( "[compiler] -g -fpe0 -traceback -c -fPIC -auto -mP2OPT_hpo_vec_divbyzero=F -extend_source -w90 -w95 -WB -I%I")

which must all be on one line and where [compiler] is a suitable Fortran compiler.

Other compiler options may also need to be set. For example, if you had written a user-defined subroutine in Fortran which itself made use of a NAG library then you should modify the local Abaqus environment file's compile_fortran section to include the the environment variable $NAG_OPTS in order to reference the correct libraries. Remember that in order for this to work you should have already loaded the appropriate NAG module before you attempt compilation or execution.

More Information

For more information visit the ABAQUS website.

Available Versions

These versions of ABAQUS are available on the BEAR systems (BlueBEAR and BEAR Cloud VMs). These will be retained in accordance with our Applications Support and Retention Policy.