> For the complete documentation index, see [llms.txt](https://docs.openbrim.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openbrim.org/templates/custom-girder-bridge-workflow/superstructure-cg/cip-pre-post-tensioned-girders-cg/girder-slab-cg.md). # Girder (Slab) \[CG] A cast-in-place, post-tensioned solid or voided slab superstructure, modeled as a single girder. The whole slab cross-section is carried by one member, so live load from the influence surface, tendons, construction staging and the code check all see one object. No deck object is needed: the slab acts as its own deck, and barriers pick the slab as their deck. The cross-section comes from the **Slab Sections** database (Solid Slab, Voided Slab (Circular Voids), Voided Slab (Rectangular Voids)). Width, depth, edge taper, overhangs, voids and the concrete material are all defined on that section; the girder reads them from it. A voided slab is made solid over given lengths at its ends and on each side of the interior supports (solid end zones, AASHTO LRFD 5.12.2.2.3). Use **Girder (Advanced Variation)** for an arbitrary custom girder shape that carries a separate deck. ## Girder Parameters **Girder Layout:** The Girder Layout the slab is placed along. The girder line is the top of the slab at the middle of the section width: the section hangs below it and is centered on it. The layout must have at least two supports. The cantilever lengths entered on the Girder Layout (**Initial Cantilever Length of Girder** / **End Cantilever Length of Girder**) extend the slab past the end supports. A cantilever is part of the finite element model, and on a voided slab it belongs to the solid end zone (see **Solid Length Start** / **Solid Length End**). **Girder Section:** The slab cross-section, used along all spans. The list offers only the slab sections of the project, and **Import Section** opens the Slab Sections database to create one. A section from any other source is refused. The section's geometry is also checked here: if the voids touch each other or the outer faces (including where a station-dependent depth becomes too shallow for the voids), the model does not compile until the section is corrected. The slab depth may vary along the bridge: enter the section's depth **h** as station dependent in the section's own station-dependent editor (alignment stations), for example deeper over the piers. There is no built-in haunch profile. The finite element model, the 3D view and the quantities follow the profile; the slab top stays on the girder line, the soffit follows the depth, and the bearings sit on the soffit at their support. The solid end zones follow the same depth. {% hint style="info" %} Live load reaches the slab over its section width. The girder reports whether the widest roadway of the bridge fits within the slab width; a wheel placed outside the slab is not carried. {% endhint %} ### Solid End Zones These inputs apply only when the **Girder Section** is voided; a solid section is solid throughout and the inputs are not used. In a solid zone the girder uses the girder section without its voids, built from the section's own outline, so the solid zone always has the same width, depth, edge taper and overhangs as the voided span. Zone boundaries on a skewed support line are parallel to that support line. Lengths must not be negative, and a length of 0 leaves that zone voided. **Solid Length Start:** Length of the solid zone at the start of the slab, measured along the girder line from the first support line toward the first span (default: 60 in). When the length is greater than 0, a cantilever past the first support is solid as well; a length of 0 leaves the cantilever voided too. **Solid Length End:** Length of the solid zone at the end of the slab, measured along the girder line from the last support line back into the last span (default: 60 in). When the length is greater than 0, a cantilever past the last support is solid as well; a length of 0 leaves the cantilever voided too. In every span, the solid lengths at its two ends must add up to less than the span length; overlapping zones are refused. **Solid Length Pier:** Length of the solid zone on each side of every interior support, measured along the girder line from the support line (default: 60 in). Shown only when the girder layout has more than two supports. {% hint style="info" %} AASHTO LRFD 5.12.2.2.3 requires solid end sections of at least 3 ft or 5 % of the span, whichever is greater. The girder reports whether every solid length satisfies this; the check is reported, not enforced, so a model in progress still compiles. {% endhint %} ## FEA **Supports:** Pick the Insertion Points (bearings) the slab rests on. Each bearing gets its own rigid link from the slab down to the bearing on the soffit, so several bearings on one support line model point bearings across the slab width. Picking a bearing here also assigns this slab as the girder of that Insertion Point, which connects every bearing of the slab to the substructure below it. With **Transfer Forces to Substructure** set to YES on a bearing, the bearing spring of the pier cap, end bent or abutment below it connects to the slab at that bearing, in both FE models. An integral pier cap and an integral or semi-integral abutment tie into the slab only at the bearings, not along the full slab width. {% hint style="warning" %} Use at least two bearings at each end support of a voided slab (AASHTO LRFD 5.12.2.2.2); the girder reports whether this is met. On an abutment, use FEA Bearing or Steel Reinf. Elastomeric bearings: Pot, Sliding Plate, Single Roller and Disc bearings do not currently connect to an abutment. {% endhint %} **Mesh Size (Long.):** Maximum finite element length along the girder (default: 120 in). In the **Spine** model this is the element length of the frame line. In the **Shell** model the row spacing is the smaller of this value and two slab depths (the smallest depth where the depth varies), and the elements are square. Barriers on the slab are meshed with the same size. **Expansion joint end releases:** Table of end releases applied at expansion joints along the girder. Supported by the **Spine** model only; the **Shell** model refuses them. **Rigid Section:** Section used for the rigid links from the slab down to its bearings. Optional: leave it empty to use a built-in massless rigid section, which is the recommended choice. A project section made of real concrete adds the self-weight of the links to the model. **FE Model \[Spine/Shell]:** Selects how the slab is represented in the finite element model. * **Spine** (default): one line of frame elements along the girder carries the full slab section, including the solid end zones. Barriers hang on the spine nodes through rigid arms, so their weight reaches the slab as vertical load plus torsion. * **Shell**: one plate mesh over the slab outline replaces the spine. The nodes lie on the slab top and every element is offset down to its own mid-surface. The voids are smeared into the plate: along the span it has the section's area, inertia and weight; across the span its bending and membrane stiffness are reduced for the strips that cross the voids. The solid zones get the properties of the section without voids. Where the depth varies, each row of elements takes the section properties at its middle. A section with overhangs is split across the width into a core and overhang strips (at least two per side) that follow the tapered overhang. Each bearing lands on the plate node above it, on its support row. A bearing outside the slab lands on the slab edge; with overhangs, a bearing beyond the core face lands on the core face. In both cases its rigid link carries the remaining offset. The shell model shows what the spine cannot: the slab sags between point bearings (in a test with one bearing per support line, a 30 ft wide slab deflected 24 % more than the spine), and a wide plate is slightly stiffer than a beam because of Poisson's effect (about 3 %). {% hint style="warning" %} Restrictions of the **Shell** model: * Every tendon on the slab must have **Load Dist. Elem. Type** set to FENodes; the plate has no frame elements to carry a line distribution. Each tendon point is moved to the nearest plate node together with a balancing moment, so the prestress force is exact. * Expansion joint end releases are not supported. * Where the plate is lighter than solid concrete of the full slab depth (voided zones, for example), it weighs through a copy of the slab concrete with a reduced unit weight. That copy carries f\_cm as its only time-dependent input, so: * if creep, shrinkage or time-dependent E is switched on for the slab concrete, f\_cm must be its only time-dependent input (remove the others so the code defaults apply); * an Override on the slab concrete, such as a construction stage's N-3N modulus, is not supported. Use the **Spine** model in these cases. {% endhint %} **Additional Result Extraction St.:** List of alignment stations at which sectional results are extracted, in addition to the default ones. By default results are taken at 60 equal parts of the girder, at every support, and 1 in and 3 in inside the first and last supports. The stations must lie between the first and the last support. {% hint style="info" %} Two sets of sectional results are produced at these cuts. **CompositeGirder**, which the code check and the girder results read, includes the barriers on the slab, so the slab is checked for the whole sectional force. **NonCompositeGirder** is the slab alone. {% endhint %} ## IFC **Type \[IfcBridge/IfcBridgePart/IfcBeam/IfcColumn/IfcSlab/IfcFooting/IfcPile/IfcBearing/IfcReinforcingBar/IfcReinforcingMesh/IfcTendon/IfcMechanicalFastener/IfcAlignment/IfcPositioningElement/IfcKerb/IfcGuardrail/IfcSurfaceFeature/IfcElementAssembly/IfcCableSegment/IfcSensor/IfcDistributionElement/IfcPlate/IfcWall/IfcRail/IfcRoad/IfcDiscreteAccessory/IfcDistributionSystem/IfcMember/IfcBuildingElementProxy]:** IFC entity type used when the slab is exported (default: IfcBeam). **Predefined Type \[BEAM/CORNICE/DIAPHRAGM/EDGEBEAM/GIRDER\_SEGMENT/HATSTONE/HOLLOWCORE/JOIST/LINTEL/PIERCAP/SPANDREL/T\_BEAM/USERDEFINED/NOTDEFINED]:** Predefined type of the IFC entity. Defaults to HOLLOWCORE when the Girder Section is voided and to BEAM when it is solid. **Parent \[BRIDGE/SUPERSTRUCTURE/DECK/SUBSTRUCTURE/FOUNDATION/APPROACH\_STRUCTURE/RETAINING\_STRUCTURE]:** Parent element of the slab in the IFC spatial hierarchy (default: SUPERSTRUCTURE). **Properties:** Custom IFC property entries attached to the slab on export. Use the custom IFC properties editor to add rows. ## Quantities All quantities are read-only values computed from the Girder Section, segment by segment along the girder line, including the cantilevers. A solid zone counts with the full section and a voided zone with the voids deducted; where the depth varies, each value is integrated along the segment. They may take a moment to refresh on recompute. **Min Section Area:** Smallest cross-section area along the slab. (Read-only) **Max Section Area:** Largest cross-section area along the slab. (Read-only) **Total Surface Area:** Area of the outer faces of the slab plus its two end faces; the void walls are not included. A sloping soffit, depth steps and skewed end faces are accounted for. (Read-only) **Min Cross Section Perimeter:** Smallest outer perimeter of the section along the slab, void walls excluded. (Read-only) **Max Cross Section Perimeter:** Largest outer perimeter of the section along the slab, void walls excluded. (Read-only) **Volume:** Concrete volume of the slab, voids deducted. (Read-only) **Weight:** Volume multiplied by the unit weight of the section's concrete. (Read-only) **Inner Void Formwork Area:** Area of the void walls along the voided length, without end caps; 0 for a solid slab. (Read-only) **Length @COG Path:** Length of the slab measured along the girder line, cantilevers included. (Read-only) **Voids:** Number of voids in the section; 0 for a solid slab. (Read-only) **Void Length:** Total length of all void formers: the number of voids times the voided length of the slab. (Read-only) ## Referencing Objects These lists are filled automatically when other objects pick this slab; they show what refers to it. **Structure States:** Construction objects (for example **Girder Construction (Complete)**) that build or remove this slab in a Construction Stage. **Temporary Supports:** Temporary supports that reference this slab. **Decks:** Decks that reference this slab. A slab normally has none, because it acts as its own deck. **Tendons:** Girder Tendons placed on this slab. In the **Shell** model each of them must use **Load Dist. Elem. Type** = FENodes. **Strands:** Girder Strands placed on this slab. **Bracings:** Bracing objects connected to this slab. **Lateral Bracings:** Lateral bracing objects connected to this slab. (Read-only) **Barriers:** Barriers that pick this slab as their **Deck**. The barrier weight reaches the slab as vertical load plus torsion, and barriers are included in the slab's composite results (**CompositeGirder**). (Read-only) {% hint style="info" %} For wind with **WS AASHTO** or **WS Custom**, select the slab only, not its barriers: the slab's wind face already reaches the top of the tallest barrier on it. In the **Shell** model the wind acts on the windward slab edge. {% endhint %} {% hint style="warning" %} In the **Spine** model, a **Barrier Load** on a barrier of the slab reaches the slab as a vertical load without the torsion from its offset to the girder line. For a load on one side of the slab, enter that torsion in **Mx** (load × offset). {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openbrim.org/templates/custom-girder-bridge-workflow/superstructure-cg/cip-pre-post-tensioned-girders-cg/girder-slab-cg.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.