Glossary

3DExperience

Dassault Systèmes’ 3DExperience Platform has apps from every Dassault Systèmes brand. These apps (which focus on different domains) all access a common database. For example, CAD (CATIA) and simulation (SIMULIA) apps access and enhance the same product, which enables collaboration and lifecycle management.

For the purposes of inpRW, 3DExperience provides a pre-processor that can generate an Abaqus input file.

Abaqus

Dassault Systèmes’ primary Finite Element Analysis product suite. It’s primary use is nonlinear structural simulations. Abaqus is composed of several products, as described here. As inpRW is focused on the Abaqus input file, this documentation will primarily use Abaqus to refer to the Abaqus solvers.

data

Can refer to the data attribute of inpKeyword, or it can just mean “information” in general. If the term is not linked to data, it is most likely used in a general term and does not have a specific meaning.

data item

One item from a dataline. See Abaqus Keyword Block Terminology for a diagram.

dataline

One line from the data of a keyword block[1]. See Abaqus Keyword Block Terminology for a diagram.

inpParser

The module for parsing Abaqus input files that is included with Abaqus Python. Details on limitations of inpParser here: inpParser Module. inpParser Documentation.

input file

A text file with the “.inp” extension. The input file defines the Abaqus simulation. This includes information like nodes, elements, sets, surfaces, contact definitions, boundary conditions, loading, and many other options.

job

An Abaqus simulation. The details of the job are determined by the input file.

keyword

A keyword is the name that starts an Abaqus keyword block. It is preceded by “*” and is separated from the parameters[2] by a comma. A keyword can be more than one word. Please see the Abaqus Keywords Guide for the list of valid Abaqus keywords.

keyword block
block
  1. A section of an Abaqus input file consisting of a keyword line and 0 or more datalines.

  2. An inpKeyword instance that was parsed from a keyword block[1] of an Abaqus input file.

Keyword Edit

Keyword Edit is a function of 3DExperience simulation scenario apps (like Mechanical Scenario Creation) that allows users to make to changes to the Abaqus input file that 3DExperience writes before the job is submitted. This can use an .xml file, or a Python script.

Keyword Edit Documentation.

keyword line

A line in the input file starting with a keyword and also containing parameters[2]. A keyword line can be continued on subsequent lines if the keyword and parameters[2] will not fit on one line. If a keyword line ends with a comma, Abaqus will continue reading parameters[2] from the next line.

See Abaqus Keyword Block Terminology for a diagram.

parameter
  1. Input to a Python function.

  2. An Abaqus keyword parameter.

  3. The parameter attribute of an inpKeyword object, which holds the parsed Abaqus parameters for a keyword block.

  4. An Abaqus keyword. See *PARAMETER.

parent block

A keyword block that hosts one or more subblock in its suboptions attribute. *MATERIAL is an example of an Abaqus keyword block that can be a parent block.

pip

pip is the package installer for Python. pip documentation.

positionl

positionl stands for position list. It is a list of integers and sequences that represent the path to the object. The format is [keyword, [suboption0, suboption1, …], [dataline, datapos]].

pre-processor

A GUI tool for generating an Abaqus input file. Two examples are Abaqus/CAE and the SIMULIA apps in 3DExperience. Pre-processors are necessary to create meshes, surfaces, and sets on complex geometry, and should be designed to write valid input files. There is no pre-processor that can write every keyword the Abaqus solvers support, though, so editing the input file through means such as inpRW is sometimes necessary or convenient.

suboption
subblock
subkeyword

A keyword block that is a child to a parent block. A *PLASTIC keyword block is a valid subblock for *MATERIAL.

user script

A Python script written by an end-user which imports functionality from inpRW to accomplish a certain task. As inpRW is merely a collection of useful classes, functions, etc., a user script will always be needed to utilize the built-in functionality of inpRW and complete the tasks required for the user’s workflow.