Bulk Data Input File

The input file in OptiStruct is composed of three distinct sections.

The I/O Options Entry section controls the overall running of the analysis or optimization. It controls the type, format, and frequency of the output, the type of run (check, analysis, super element generation, optimization or optimization restart), and the location and names of input, output, and scratch files.

The Subcase Information Entry section contains information for specific subcases. It identifies which loads and boundary conditions are to be used in a subcase. It can control output type and frequency, and may contain objective and constraint information for optimization problems. For more information on solution sequences, see the table included on the Solution Sequences - Data Selectors page of the online help.

The Bulk Data Entry section contains all finite element data for the finite element model, such as grids, elements, properties, materials, loads and boundary conditions, and coordinates systems. For optimization, it contains the design variables, responses, and constraint definitions. The Bulk Data Entry section begins with the BEGIN Bulk statement.


Figure 1.

These sections can be arranged in either a one-file setup or a multi-file setup (there is also an obsolete two-file setup that is no longer recommended).

String Label Based Input File

Entities can be identified by string labels in their corresponding ID field, in addition to the existing support of integer IDs. While integer-based IDs offer more flexibility when the input file is edited manually, string-based labels offer easier identification of entries in the input file, especially when many entries are defined.

There are currently two types in which string-based labels can be used:
  • Type 1:

    String labels can be used to identify entries via their corresponding ID field. For example, a string label in the MID field of MAT1 entry can uniquely identify this material entry (similar to the function of an integer-based ID).

  • Type 2:

    Entries defined with string labels as IDs can then be referenced by other entries using their unique string labels. For example, the string label identifier of a MAT1 entry can be specified on the MID field of a PSOLID entry to associate this particular MAT1 material to the PSOLID property (similar to the usage of an integer-based label).

Support for String-based labels:
  • Materials
    • Type 1 support:

      String labels can be defined in the MID field of the following material entries: MAT1, MATS1, MAT2, MAT3, MAT4, MAT5, MAT8, MAT9, MAT10.

    • Type 2 support:

      String labels defined in the MID field of these materials can be referenced in the MID field of other relevant properties.

    The following example shows usage of string labels in the context of material.
    $ EXAMPLE 1 - STRING BASED IDs WITH MAT1
.
.
MAT1, STEEL_MATERIAL, 210000.0, , 0.3 
PSOLID, 1, STEEL_MATERIAL
.
.
  • Properties
    • Type 1 support:

      String labels can be defined in the PID field of the following property entries: PSHELL, PSOLID, PBEAM, PBAR, PBEAML, PBARL, PBUSH, PCOMP, PCOMPG, PROD, PELAS, PDAMP, PMASS, PGAP and PCONT.

    • Type 2 support:

      String labels defined in the PID field of these properties can be referenced in the PID field of the relevant entries.

    The following example shows usage on string labels in the context of properties.
     $ EXAMPLE 2 - STRING BASED IDs WITH PROD
.
.
CROD, 1, _PROD_string,1,2
CROD, 2, _PROD_string,2,3
CROD, 3, _PROD_string,3,4
CROD, 4, _PROD_string,4,5
CROD, 5, _PROD_string,5,6
PROD, _PROD_string, 101, 1.0
.
.
  • Sets
    • Type 1 support:

      String labels can be defined in the ID field of element and grid based SET entries.

    • Type 2 support:

      String labels in the SET ID field of the following Bulk Data Entries are supported – SPC, SPCD, FORCE, MOMENT, PLOAD1, PLOAD2, ACCEL2, NSML1 (element set in ID field), RBODY (grid and element set in ID field), TIE (GSETID), PLOADSF (ELSET).

      String labels in the SET ID field of output requests are also supported. These output requests are limited to grid-based and element-based output.

    The following example shows usage on string labels in the context of sets.
    $ EXAMPLE 3 - STRING BASED IDs WITH SET
.
.
SPC, 1, VEHICLE_DOOR, 123456, 0.0
+, GSET
SET, VEHICLE_DOOR, GRID, LIST    
+, 26, THRU,100
.
.
  • Coordinate Systems
    • Type 1 support:

      String labels can be defined in the CID field of all the coordinate system definitions.

    • Type 2 support:

      String labels in the CID field of the following bulk entries are supported – JOINTG, RFORCE.

    The following example shows usage on string labels in the context of coordinate systems.
    $ EXAMPLE 4 - STRING BASED IDs WITH COORDINATE SYSTEMS
.
.
CORD2R, RECT_COORD, , 2.0, 0.0, 1.0, 2.0, 0.0, 101.0  
JOINTG, 1, 99, CARTES, 337, RECT_COORD, 2325
.
.
  • Surface
    • Type 1 support:

      String labels can be defined in the SRFID field of SURF entries.

    • Type 2 support:
      String labels can be defined surface field of following entries:
      • CONTACT and TIE (SSID and MSID fields)
      • PLOADSF (SURF field)
  • Tables
    • Type 1 support:

      String labels can be defined in the TID field of TABLES1 entries.

    • Type 2 support:

      String labels can be defined TID of MATS1 entry, if it references a TABLES1 entry.

Characteristics of string-based IDs:
  • They are case insensitive.
  • String labels are supported in all the Bulk Data formats namely, fixed, large fixed (long) and free formats.
  • For string labels longer than 8 characters, it is recommended to use the free format. While strings of any length are allowed in the free format, they will be truncated after 16 characters when processed within OptiStruct.
  • They follow the same guidelines as variable names in the Symbolic Substitution feature.

One-File Setup

In a one-file setup, all three data sections are included in one file. The Bulk Data Entry section must be the last section. It is recommended that the extension .fem be used for this file.

Multi-File Setup

A multi-file setup is facilitated through the use of INCLUDE I/O Options Entry. This option enables you to include information from other files without cutting and pasting. INCLUDE statements may be placed in any section of the one or two-file setup, but must include information appropriate to the section.

The following example shows how an additional subcase can be added to the Subcase Information section.
input.fem file sub2.inc 
$
Subcase 1
SPC = 1
Load = 2
$
INCLUDE sub2.inc
$
BEGIN BULK
$

Subcase 2
SPC = 1
Load = 3
The solver reads all files and positions the lines of the included file at the location of the INCLUDE statement in the input.fem file. An echo of the input.fem file as read by OptiStruct would be: 
$
Subcase 1
SPC = 1
Load = 2
$
Subcase 2
SPC = 1
Load = 3
$
BEGIN BULK
$

Two-File Setup

This setup is obsolete; the one-file or multiple-file setups are recommended.

The two-file setup separates the control data (I/O Options Entry section and Subcase Information Entry section) from the model data (Bulk Data Entry section). If the input file does not contain a BEGIN Bulk statement, the solver attempts to read the model data from another file:
  • If the INFILE card is present in the I/O Options Entry section, the argument given on this card is the name of the file that contains the model data.
  • If the INFILE card is not present in the I/O Options Entry section, and the input file does not have the extension .fem, the name of the file containing the model data will be constructed from the input file by replacing the extension with .fem.
The two-file setup allows you to perform runs using multiple control data files and a single model file and vice versa. It is recommended that the .parm extension be used for control data files and the .fem extension be used for model data files.
Note:
  • The format of the input sections in OptiStruct is similar to those of the Nastran format.
  • File names specified on INCLUDE and other cards (RESTART, EIGVNAME, LOADLIB, OUTFILE, TMPDIR, ASSIGN) can be arbitrary file names with optional paths appropriate to the operating system (Windows or Unix). They may be enclosed in quotes (double or single quotes can be used), and either forward slash (/) or back slash (\) characters can be used to separate parts of the pathname.
  • The solver uses the following rules to locate a file name on the INCLUDE cards:
    • When the argument contains the absolute path of the file (if it starts with "/" on Unix or a drive letter, such as "D:", on Windows, for example), the file at the given location is used.
    • When only the file name is given (without the path), the file has to be located in the same directory as the file containing the INCLUDE statement.
    • When the argument contains a relative path (../filename or sub/filename, for example), it is located in the directory relative to the file containing the INCLUDE statement and is NOT relative to the directory in which the solver was executed, or to the directory where the main file is located.

Compressed Input Files

An input file and referenced included files can be optionally compressed using GZIP compression. A compressed file has to have the extension .gz appended to the file name. Valid example file names are: input.fem.gz, input.gz, and input.dat.gz. Compressed files can be mixed with plain ASCII files. The INCLUDE card does not have to be modified when a file is compressed. For example, if the card INCLUDE infile.dat were present, the reader would search for infile.dat and continue on to search for the compressed file, infile.dat.gz, if not found. Other input files (such as RESTART, ASSIGN) cannot be compressed.