An output database generated from an ABAQUS analysis contains both model and results data as shown in Figure 8–1.
Model data
Model data describe the parts and part instances that make up the root assembly; for example, nodal coordinates, set definitions, and element types. Model data are explained in more detail in “Model data,” Section 8.3.1.
Results data
Results data describe the results of your analysis; for example, stresses, strains, and displacements. You use output requests to configure the contents of the results data. Results data can be either field output data or history output data; for a more detailed explanation, see “Results data,” Section 8.3.2.
Note: For a description of object models, see “An overview of the ABAQUS object model,” Section 6.1.1.
Model data define the model used in the analysis; for example, the parts, materials, initial and boundary conditions, and physical constants. More information about model data can be found in “The ABAQUS object model,” Section 6.1, and “Defining an assembly,” Section 2.9.1 of the ABAQUS Analysis User's Manual.
ABAQUS does not write all the model data to the output database; for example, you cannot access loads and interactions. Model data that are stored in the output database include parts, the root assembly, part instances, regions, materials, sections, section assignments, and section categories, each of which is stored as an ABAQUS Scripting Interface object. These components of model data are described below.
Parts
A part in the output database is a finite element idealization of an object. Parts are the building blocks of an assembly and can be either rigid or deformable. Parts are reusable; they can be instanced multiple times in the assembly. Parts are not analyzed directly; a part is like a blueprint for its instances. A part is stored in an output database as a collection of nodes, elements, surfaces, and sets.
The root assembly
The root assembly is a collection of positioned part instances. An analysis is conducted by defining boundary conditions, constraints, interactions, and a loading history for the root assembly. The output database object model contains only one root assembly.
Part instances
A part instance is a usage of a part within the assembly. All characteristics (such as mesh and section definitions) defined for a part become characteristics for each instance of that part—they are inherited by the part instances. Each part instance is positioned independently within the root assembly.
Materials
Materials contain material models comprised of one or more material property definitions. The same material models may be used repeatedly within a model; each component that uses the same material model shares identical material properties. Many materials may exist within a model database, but only the materials that are used in the assembly are copied to the output database.
Sections
Sections add the properties that are necessary to define completely the geometric and material properties of an element. Various element types require different section types to complete their definitions. For example, shell elements in a composite part require a section that provides a thickness, multiple material models, and an orientation for each material model; all these pieces combine to complete the composite shell element definition. Like materials, only those sections that are used in the assembly are copied to the output database.
Section assignments
Section assignments link section definitions to the regions of part instances. Section assignments in the output database maintain this association. Sections are assigned to each part in a model, and the section assignments are propagated to each instance of that part.
Section categories
You use section categories to group the regions of the model that use the same section definitions; for example, the regions that use a shell section with five section points. Within a section category, you use the section points to identify the location of results; for example, you can associate section point 1 with the top surface of a shell and section point 5 with the bottom surface.
The objects stored as model data in an output database are similar to the objects stored in an ABAQUS/CAE model database. However, the output database does not require a model name because an analysis job always refers to a single model and the resulting output database can contain only one model. For example, the following ABAQUS Scripting Interface statements refer to an Instance object in the model database:
mdb = openMdb(pathName='/users/smith/mdb/hybridVehicle') myModel = mdb.models['Transmission'] myPart = myModel.rootAssembly.instances['housing']
Similar statements refer to an Instance object in the output database.
odb = openOdb(path='/users/smith/odb/transmission.odb') myPart = odb.rootAssembly.instances['housing']
You can use the prettyPrint method to display a text representation of an output database and to view the structure of the model data in the object model. For example, the following shows the output from prettyPrint applied to the output database created by the ABAQUS/CAE cantilever beam tutorial:
from odbAccess import *
from textRepr import *
odb=openOdb('Deform.odb')
prettyPrint(odb,2)
({'analysisTitle': 'Cantilever beam tutorial',
'description': 'DDB object',
'jobData': ({'analysisCode': ABAQUS_STANDARD,
'creationTime': 'Thu Jun 20 15:06:31 Eastern
Standard Time 2002',
'machineName': '',
'modificationTime': 'Thu Jun 20 15:06:32 Eastern
Standard Time 2002',
'name': 'D:/users/user1/cae/Deform.odb',
'precision': SINGLE_PRECISION,
'productAddOns': 'tuple object',
'version': 'ABAQUS/Standard 6.3-1'}),
'name': 'D:/users/user1/cae/Deform.odb',
'parts': {'BEAM': 'Part object'},
'path': 'D:/users/user1/cae/Deform.odb',
'rootAssembly': ({'connectors': 'Repository object',
'datumCsyses': 'Repository object',
'elementSets': 'Repository object',
'instances': 'Repository object',
'name': 'ASSEMBLY',
'nodeSets': 'Repository object',
'surfaces': 'Repository object'}),
'sectionCategories': {'solid < STEEL >':
'SectionCategory object'},
'sectorDefinition': None,
'steps': {'Beamload': 'OdbStep object'},
'userData': ({'xyDataObjects': 'Repository object'})})
For more information, see “prettyPrint,” Section 46.1.4 of the ABAQUS Scripting Reference Manual.Results data describe the results of your analysis. ABAQUS organizes the analysis results in an output database into the following components:
Steps
An ABAQUS analysis contains a sequence of one or more analysis steps. Each step is associated with an analysis procedure.
Frames
Each step contains a sequence of frames, where each increment of the analysis that resulted in output to the output database is called a frame. In a frequency or buckling analysis each eigenmode is stored as a separate frame. Similarly, in a steady-state harmonic response analysis each frequency is stored as a separate frame.
Field output
Field output is intended for infrequent requests for a large portion of the model and can be used to generate contour plots, animations, symbol plots, and displaced shape plots in the Visualization module of ABAQUS/CAE. You can also use field output to generate an X–Y data plot. Only complete sets of basic variables (for example, all the stress or strain components) can be requested as field output. Field output is composed of a “cloud of data values” (e.g., stress tensors at each integration point for all elements). Each data value has a location, type, and value. You use the regions defined in the model data, such as an element set, to access subsets of the field output data. Figure 8–3 shows the field output data object model within an output database.
History output
History output is output defined for a single point or for values calculated for a portion of the model as a whole, such as energy. History output is intended for relatively frequent output requests for small portions of the model and can be displayed in the form of X–Y data plots in the Visualization module of ABAQUS/CAE. Individual variables (such as a particular stress component) can be requested.
Depending on the type of output expected, a HistoryRegion object can be defined for one of the following:
a node
an integration point
a region
the whole model
