Processing an Abaqus input file (.inp) is more complicated than it seemed. The current implementation used nested dictionaries to extract data from a .inp file. For deeply nested dictionaries, it hampers the readability and it is difficult to insert a new level somewhere in the middle. Another problem is that many Abaqus commands are similar but still need slightly different inputs. The many edge cases render the current approach inflexible for extension.
The .inp files have a set of syntax rules and keywords. This makes it a domain specific language. Hence, an AST can be used to analyze it. Recognizing this gave the idea to represent the Abaqus module hierarchy as a tree. E.g. if the .inp file contains
* Material, name=mat-1
** possible comment line
* Elastic
** possible comment line
data line
* Plastic
data line 1
** possible comment
data line 2
* Material, name=mat-2
...
it could be represented as
Root
|--- ...
|--- Material (object containing the name: 'mat-1')
|--- Elastic (object containing the elastic properties)
|--- Plastic (object containing the plastic properties)
|--- Material (object containing the name: 'mat-2')
...
Being a tree data structure, including new commands or changing the hierarchy is easy. E.g. if we want the Material command to be part of the Property Abaqus module, we insert a Property object under the Root and set the Material objects to be children of the Property (singleton) object.
Once we have the tree, we can fill it in with data coming from the input file. We define parent-children relationships so that the added nodes (commands) are inserted to the correct position of the tree. For each command, create a class
which serves as a container holding the data read from the .inp file
checks for admissibility
the object of which is a node of the tree
Manipulations (modifying element connectivities, adding materials, etc.) are easy to carry out in this intermediate representation, no need to deal with the text representation. Writing the (possibly modified) state into file is straightforward by traversing the tree.
anytree, written in pure Python, is a promising package, in which custom objects can form the nodes of the tree.
Processing an Abaqus input file (.inp) is more complicated than it seemed. The current implementation used nested dictionaries to extract data from a .inp file. For deeply nested dictionaries, it hampers the readability and it is difficult to insert a new level somewhere in the middle. Another problem is that many Abaqus commands are similar but still need slightly different inputs. The many edge cases render the current approach inflexible for extension.
The .inp files have a set of syntax rules and keywords. This makes it a domain specific language. Hence, an AST can be used to analyze it. Recognizing this gave the idea to represent the Abaqus module hierarchy as a tree. E.g. if the .inp file contains
it could be represented as
Being a tree data structure, including new commands or changing the hierarchy is easy. E.g. if we want the
Materialcommand to be part of thePropertyAbaqus module, we insert aPropertyobject under theRootand set theMaterialobjects to be children of theProperty(singleton) object.Once we have the tree, we can fill it in with data coming from the input file. We define parent-children relationships so that the added nodes (commands) are inserted to the correct position of the tree. For each command, create a class
Manipulations (modifying element connectivities, adding materials, etc.) are easy to carry out in this intermediate representation, no need to deal with the text representation. Writing the (possibly modified) state into file is straightforward by traversing the tree.
anytree, written in pure Python, is a promising package, in which custom objects can form the nodes of the tree.