OpenSees Cloud
OpenSees AMI
The Fiber Content of OpenSees
Original Post - 05 Jan 2020 - Michael H. Scott
Visit Structural Analysis Is Simple on Substack.
Although fiber sections are not unique to OpenSees, where else can you choose from 23 uniaxial concrete models and 18 uniaxial steel models to define a reinforced concrete section? There’s also a handful of multiaxial material models that capture the interaction of axial and shear stresses in beam fibers, as well as fiber models for shells.
Remo De Souza developed the infrastructure for fiber sections as part of his
class project in CE 224 Computer-Aided Civil Engineering at UC Berkeley. For
his Ph.D. dissertation, Remo extended the geometrically nonlinear CBDI
force-based formulation to include material nonlinearity and developed a
three-dimensional corotational formulation. He also implemented
nonlinearBeamColumn, the initial version of the force-based frame element.
Remo is an unsung hero of OpenSees.
In his implementation of fiber sections, Remo created the FiberSectionRepres class as a container for the patches and layers of fibers defined by users. This class provides an array of Fiber objects to the constructors of the fiber section classes. Each Fiber object contains a UniaxialMaterial (or NDMaterial) and the fiber’s area and section coordinates. After a fiber section gets the material pointers, areas, and coordinates for all of its fibers, the Fiber objects are tossed out.
However, if you take a look at the Fiber class interface, you’ll see more than simple storage and retrieval functionality. There are methods to set the fiber strain from section deformations and to get the fiber stress resultant and stiffness contributions.
Those fiber state determination methods are leftover from my attempt to consolidate the different fiber section classes into one FiberSection class. Instead of multiple fiber section classes, FiberSection2d, FiberSection3d, NDFiberSection2d, NDFiberSection3d, etc., all of which do the same thing (sum section force and stiffness contributions from fibers), we could put the Fiber objects to use and have one FiberSection class.
As you might expect, the computational overhead that accumulates due to the
extra level of indirection for fiber state determination far outweighed the
improved software engineering. The FiberSection has to go through Fiber
objects to get the stress-strain response whereas, e.g., FiberSection2d, etc.
go directly to the stress-strain response. Using Fiber objects, each fiber
state determination requires two polymorphic calls instead of one. To make along story short, the FiberSection class quickly moved into the OpenSees
retirement home. Take a look, it spits out errors with the old school
g3ErrorHandler.
Additional indirection is extremely beneficial at the higher levels of the OpenSees framework where the indirection is computationally inconsequential, e.g., with the FE_Element and DOF_Group classes. But this is not the case at lower levels, and fibers are at the lowest level in the hierarchy of nonlinear finite element analysis.
It’s one of those 80-20 rules: 80% of the computations come from 20% of the code. With fiber sections, it’s more like 95-5. So you’ll want to use as few fibers as possible in each section. See Kostic and Filippou (2012) for more information on how many fibers to use.
Eventually, the SectionIntegration interface came along. Implementations of SectionIntegration encapsulate fiber areas and section coordinates in specific arrangements–wide flange steel shapes, doubly reinforced concrete sections, tube sections, etc. Users don’t have to define multiple patches and layers all the time for common section geometries and it became easy to use section dimensions as parameters for reliability, sensitivity, and optimization applications. This made me feel a lot better about my failed consolidation of the fiber section classes.