<!-- source-page: 551 -->

The following is a discussion of some additional environment file parameters that are commonly used. A complete listing of parameters can be found in the Abaqus Installation and Licensing Guide.

# ask\_delete

If this parameter is set equal to OFF, you will not be asked whether old job files of the same file name should be deleted; the files will be deleted automatically. The default value is ON.

# auto\_calculate

If this parameter is set to ANALYSIS, all output database postprocessing in Abaqus/Standard is performed as part of analysis execution. If this parameter is set to ON, output database postprocessing is performed by the postprocessing calculator at the end of an analysis if the execution procedure detects that output database postprocessing is necessary. If this parameter is set to OFF, no output database postprocessing occurs even if the execution procedure detects that it is necessary to postprocess the output database file. The default value is ANALYSIS. In Abaqus/Explicit auto\_calculate=ANALYSIS is equivalent to auto\_calculate=ON.

# auto\_convert

If this parameter is set equal to ON and an Abaqus/Explicit analysis is run in parallel with parallel=domain, the convert=select, convert=state, and convert=odb options will be run automatically at the end of the analysis. The default value is ON.

# average\_by\_section

This parameter is used only for an Abaqus/Standard analysis. If this parameter is set equal to OFF, the averaging regions for output written to the data (.dat) file and results (.fil) file are based on the structure of the elements. If this parameter is set equal to ON, the averaging regions also take into account underlying values of element properties and material constants. In problems with many section and/or material definitions the default value of OFF will, in general, give much better performance than the nondefault value of ON. See “Output to the data and results files,” Section 4.1.2, for further details on the averaging scheme.

# mp\_host\_list

List of host machine names to be used for an MPI-based parallel Abaqus analysis, including the number of processors to be used on each machine; for example,

```txt
mp_host_list=[[maple',1],['pine',1],['oak',2]] 
```

indicates that, if the number of cpus specified for the analysis is 4, the analysis will use one processor on a machine called maple, one processor on a machine called pine, and two processors on a machine called oak. The total number of processors defined in the host list has to be greater than or equal to the number of cpus specified for the analysis. If the host list is not defined, Abaqus will run on the local system. When using a supported queuing system, this parameter does not need to be defined. If it is defined, it will get overridden by the queuing environment.

<!-- source-page: 552 -->

# mp\_mode

Set this variable equal to MPI to indicate that the MPI components are available on the system. Set mp\_mode=THREADS to use the thread-based parallelization method. The default value is MPI where applicable.

# odb\_output\_by\_default

If this parameter is set equal to ON, output database output will be generated automatically. If this parameter is set equal to OFF, output database request keywords must be placed in an input file to obtain output database output. The default value is ON.

# onCaeStartup

Optional function to be executed before Abaqus/CAE begins. See “Customizing Abaqus/CAE startup,” Section 4.3.3 of the Abaqus Installation and Licensing Guide, for examples of this function.

# Co-simulation parameters

The following environment file variables provide default settings for co-simulation between solvers using the direct coupling interface. This includes Abaqus/Standard to Abaqus/Explicit co-simulation and co-simulation between Abaqus and certain third-party analysis programs.

# cosimulation\_port

Set cosimulation\_port equal to the port number used for the connection. The default value is 48000.

# cosimulation\_timeout

Set cosimulation\_timeout equal to the timeout period in seconds. Abaqus terminates if it does not receive any communication from the coupled analysis program during the time specified. The default value is 3600 seconds.

The following environment file variables provide settings that allow you to allocate CPUs for co-simulation jobs submitted using the co-simulation execution procedure. This includes Abaqus/Standard to Abaqus/Explicit, Abaqus/Standard to Abaqus/CFD, and Abaqus/CFD to Abaqus/Explicit co-simulation (see “Abaqus/Standard, Abaqus/Explicit, Abaqus/CFD, AND FMU co-simulation execution,” Section 3.2.4).

# cpus\_weight\_std

This option controls the allocation of CPUs to Abaqus/Standard analyses. The actual CPU allocation for Abaqus/Standard analyses is made in proportion to this value and considering the settings of cpus\_weight\_xpl, cpus\_weight\_cfd, and cpus.

# cpus\_weight\_xpl

This option controls the allocation of CPUs to Abaqus/Explicit analyses. The actual CPU allocation for Abaqus/Explicit analyses is made in proportion to this value and considering the settings of cpus\_weight\_std, cpus\_weight\_cfd, and cpus.

<!-- source-page: 553 -->

cpus\_weight\_cfd

This option controls the allocation of CPUs to Abaqus/CFD analyses. The actual CPU allocation for Abaqus/CFD analyses is made in proportion to this value and considering the settings of cpus\_weight\_std, cpus\_weight\_xpl, and cpus.

portpool

Set this variable equal to a colon-separated pair of TCP/UDP port numbers that represents the start and end value of port numbers to be used by the co-simulation execution procedure when establishing connections between the child processes.

# Environment file examples

Example environment files that use some of the previously discussed parameters are shown below. A sample environment file, named abaqusinc.env, is included in the site subdirectory of the release to show the options used at SIMULIA.

# Linux environment file:

```txt
ask_delete=OFF
# The following parameter causes the scratch files to
# be written to /tmp.
scratch="/tmp" 
```

# Windows environment file:

```python
ask_delete=OFF
# The following parameter causes the scratch files to
# be written to the tmp directory on c:.
scratch="c:/tmp" 
```

<!-- source-page: 554 -->

<!-- source-page: 555 -->

# 3.4 Managing memory and disk resources

• “Managing memory and disk use in Abaqus,” Section 3.4.1

<!-- source-page: 556 -->

<!-- source-page: 557 -->

# 3.4.1 MANAGING MEMORY AND DISK USE IN Abaqus

Products: Abaqus/Standard Abaqus/Explicit

# References

• “Execution procedure for Abaqus: overview,” Section 3.1.1   
• “Using the Abaqus environment settings,” Section 3.3.1

# Overview

For small analyses management of computer resources is generally of secondary concern, but with large models intelligent use of disk and memory resources is a critical part of the analysis process. For moderate to large analyses you will find it necessary to modify resource management settings.

# Understanding resource use

For Abaqus disk and memory are effectively two similar means of storing data. Data that will be required after an analysis completes must eventually be written to disk; but during an analysis, disk and memory provide functionally equivalent storage mechanisms. Typically disk is a more abundant resource, while memory provides faster access to stored data. Management of Abaqus resources hinges on this simple trade-off.

# Abaqus data

There are effectively two types of data generated by an Abaqus analysis. The first is “output” data that must persist after an analysis is complete. Output data are typically either results that you require for postprocessing or data that are necessary to restart an analysis. As mentioned above, these data must be stored on disk before an analysis completes.

In addition, an analysis generates a considerable amount of “scratch” or temporary data. These are data that are needed only while an analysis is running. The scratch data can be subdivided into two groups: performance-critical data and generic data. The performance-critical data are always stored in memory, while the generic data can be stored either in memory or on disk.

# Requirements and considerations

To run an analysis, the following requirements must be satisfied:

• There must be sufficient disk space available to hold the requested output data.   
• There must be sufficient memory available to hold all performance-critical data.   
• There must be sufficient disk space or memory resource available to hold all generic scratch data.

If the above requirements are satisfied, an analysis can be completed; however, for Abaqus/Standard you may find that allowing Abaqus to use additional memory will often improve performance. With the increased availability of computer clusters, dedicated shared memory computers, and most importantly

<!-- source-page: 558 -->

job queuing systems that allocate processors and memory for analyses, it makes most sense to be able to use all the memory resources to improve performance.

Typically Abaqus/Standard allocates a large portion of the available system memory on a machine during the analysis phase, but you can manually specify a limit for memory usage with the memory parameter (see “Resource management parameters” below). No scratch data are written to disk during the Abaqus/Explicit analysis phase, since the majority of scratch data are performance critical.

# Resource management parameters

Abaqus resource management parameters fall into two classes: memory management and disk management. Each can be adjusted through one environment file parameter. The following sections explain how to best make use of this parameter. For information about the environment file, see “Using the Abaqus environment settings,” Section 3.3.1.

# Memory management parameters

The memory parameter is used to limit the amount of memory that can be used during the analysis phase of Abaqus/Standard and during the input file processing phase, which is executed before both Abaqus/Standard and Abaqus/Explicit analyses.

If you do not define the memory parameter, Abaqus automatically detects the physical memory on the machine and allocates a percentage of this available memory. The default percentages are platform specific, but they typically represent a large portion of the available physical memory. For details on the default memory allocation settings, refer to the Dassault Systèmes Knowledge Base at www.3ds.com/support/knowledge-base.

You can override the default memory allocation by specifying the percent of physical memory or by specifying an absolute limit in units of megabytes or gigabytes. Percentages are indicated by a “%” sign following the specified limit. Units of megabytes and gigabytes are indicated by “mb” or “gb” following the specified limit. If no units are specified, megabytes are assumed. For example, with any of the following settings:

```txt
memory="2048 mb"
memory="2 gb"
memory="25 %"
```

Abaqus uses up to 2 gigabytes of memory on a machine with 8 gigabytes physical memory. The memory setting value must be surrounded by quotes. The values specified for memory must be reasonable for the machine being used. Abaqus/Standard does not check the validity of the numerical values. To be consistent with operating system memory measurement tools, a megabyte is defined by Abaqus to be 1,048,576 bytes, not 1,000,000 bytes. A similar rule applies to the unit of gigabyte.

There are no memory management parameters for the Abaqus/Explicit analysis phase, since no scratch data are written to disk during this phase.

Environment file parameters can be set for a host, for a user, or for a particular job (see “Using the Abaqus environment settings,” Section 3.3.1, for further discussion). Because a default memory setting

<!-- source-page: 559 -->

that works well for one machine with a large amount of memory may not be ideal for another machine that has less memory, it may be useful to vary the default memory settings by machine.

# Disk management parameters

Management of output data is discussed in detail in “Output,” Section 4.1.1. Output data are written to files in the directory from which you launched the job.

Abaqus/Standard scratch files are written to a separate scratch directory. You can control the directory used to hold the scratch files with the scratch environment file parameter. Due to the frequent access of the scratch data throughout the analysis phase, ensuring high I/O speed of the scratch disks is essential to the analysis performance.

As explained above, no scratch data are written to disk for Abaqus/Explicit, so you have to be concerned only with proper management of output data.

# Input file processing and data check

In general, the amount of memory required during input file processing is not large. The amount of memory and disk space needed for the analysis phase of a job is more likely to be a concern. It is not possible for Abaqus to estimate the amount of memory that will be required to complete input file processing. A data check run can be performed by using the datacheck parameter in the command for running Abaqus (see “Abaqus/Standard, Abaqus/Explicit, and Abaqus/CFD execution,” Section 3.2.2) to obtain an estimate of the required memory for completing the analysis phase. General guidelines for setting the memory parameter for performing the data check (which includes the input file processing phase) are given below.

# Guidelines for memory settings

You will usually not have to change the default memory setting. If a job fails as a result of insufficient memory with the default setting, you will need to find a machine with more memory to run the job. If you need to override the default behavior by specifying a value for the memory environment file parameter, Table 3.4.1–1 lists some typical data check memory settings for problems of various sizes. The actual values required for memory may vary considerably from problem to problem depending on the features used in a model.

Table 3.4.1–1 Typical memory settings for performing the data check analysis. 

<table><tr><td>Degrees of freedom</td><td>Memory</td></tr><tr><td>250,000</td><td>250 megabytes</td></tr><tr><td>1 million</td><td>750 megabytes</td></tr><tr><td>2.5 million</td><td>1200 megabytes</td></tr><tr><td>5 million</td><td>2000 megabytes</td></tr></table>

<!-- source-page: 560 -->

# Abaqus/Standard analysis

Depending on the execution environment and typical job sizes run on the machine, memory can be set by machine or by job. More detailed guidelines are provided in the following section. When setting memory by job is needed, you are advised to run a data check analysis and set memory based on the memory estimates. These estimates are written to the printed output (.dat) file in a table under the heading “MEMORY ESTIMATE.” Two columns in this table are relevant to memory use. The first relevant column is labeled “MINIMUM MEMORY REQUIRED” and specifies the memory setting that is needed to hold critical scratch data in memory. An attempt to run the analysis with memory set below this value will result in a warning, and the job is not likely to run to completion due to the insufficient memory. The second relevant column is labeled “MEMORY TO MINIMIZE $\mathrm { I } / \mathrm { O } ^ { \mathrm { , } \mathrm { , } }$ and specifies the memory that is required to hold all scratch data, both critical and generic, in memory. If the memory specified by memory is larger than the “MINIMUM MEMORY REQUIRED,” Abaqus/Standard automatically uses the additional memory up to the memory limit to improve speed of access to generic scratch data that would otherwise be written to disk. When the memory is not enough to hold all the generic scratch data in memory, Abaqus/Standard decides which data should be written to disk and which should be kept in memory based on their relative importance with respect to their effect on the analysis performance. Therefore, the actual disk space used by the scratch data can vary from very close to zero to the “MEMORY TO MINIMIZE $\mathrm { I } / \mathrm { O } ^ { \ ' }$ depending on the memory setting. The memory setting can be changed in an analysis continued from a data check without the need of rerunning the analysis input file processor.

# Guidelines for memory settings

The memory parameter allows you to specify the memory limit that can be used by Abaqus during the input file processing and analysis phases. You can specify the setting that should generally be available to Abaqus on a particular machine in the host environment file. Settings can be modified as necessary for individual jobs in job-specific environment files. Reasonable settings for a particular machine depend on the size of the problems being run and how the machine is being used in addition to the physical memory available on the machine. You should be aware of the difference between physical and virtual memory. When virtual memory is used, a machine’s operating system simply uses disk for additional memory. While this can be useful, memory access may require I/O operations that add a considerable performance penalty. Therefore, the guidelines below for managing memory in Abaqus/Standard are always given relative to the physical memory on a machine. Virtual memory should be used only when necessary and with awareness of the associated performance penalty.

# Setting memory on single-user machines

For a single-user machine that is dedicated to running Abaqus/Standard, using the default setting of memory is sensible. If the estimates indicate that the job requires more than this value, the job is too large to run efficiently on this machine. At this point you are urged to move the analysis to another machine with more memory resources.