# General Information OpenBrIM is a fully on-cloud, collaborative SaaS platform where everything is parametric—geometry, FEA, CAD, design checks, and reporting. The platform combines: * Parametric 3D modeling * Parametric finite element analysis * Parametric CAD generation * Open and transparent design-code automation * Load rating ![](https://openbrim.atlassian.net/wiki/download/attachments/2101379073/image-20230329-152026.png?api=v2) OpenBrIM Platform requires no downloads, installations, or license codes. Users can access OpenBrIM Platform's cloud-based platform with any modern web browser from Mac, PC, Chromebook, or Linux. Red Equation Corporation is the developer and sole source provider of the OpenBrIM Platform. OpenBrIM Platform is commercially available and distributed exclusively in North America through Red Equation's New York office. OpenBrIM Platform provides cloud-based, all-inclusive, collaborative information modeling software that seamlessly integrates with everyday workflow. The platform includes fully parametric detailed 3D modeling, advanced 3D finite element analysis, powerful structural design modules, 2D/3D drawing generation, mapping, inspection management, health monitoring, and document management. It is a genuinely integrated, enterprise-level Information Modeling (BIM/BrIM) platform for the AEC industry. ![](https://openbrim.atlassian.net/wiki/download/attachments/2101379073/image-20221104-121720.png?api=v2) OpenBrIM provides a fully integrated environment for bridge owners. The same model is used for design & construction and can be utilized for asset management, inspection management, health monitoring, load rating, and more. OpenBrIM Library defines all engineered components, such as signs, barriers, traffic conditions, rules, and regulations. Photos, documents, and communications can be attached to project components and tracked throughout the structure's life cycle. A dedicated dashboard is available for load rating, where you can change the strength of structural components, manage rating vehicles, and perform load ratings quickly. OpenBrIM utilizes 3D finite element analysis and influence surface-based live loading method to provide accurate load rating reports. OpenBrIM also provides oversize vehicle permitting and routing services. Having all your structures on the Platform, OpenBrIM can autonomously run load rating in real time and provide route recommendations. # Getting Started Welcome to the OpenBrIM Platform Application, Parametric Modeling, and Library Concept fundamentals. If you're an experienced bridge or structural engineer familiar with analysis and design processes, this guide will help you understand how the OpenBrIM Platform can streamline your workflows, making them faster and more reliable. Along the way, you'll develop new parametric thinking skills that complement your engineering expertise. After completing this guide, you'll be able to: * Navigate the OpenBrIM Platform Application * Understand the Parametric Markup Language and Parametric Object Development * Create parametric 3D models * Build parametric finite element models * Use cloud-based features for model revision history * Share models with colleagues * Run Finite Element Analysis * Review Staged Construction Analysis results * Review Influence Surface Based Live Load Analysis results * Design superstructure and substructure elements per AASHTO 9th Edition and DOT Amendments * Load rate superstructure elements * Use parametric customized summary reports {% hint style="info" %} **Key Concept** OpenBrIM is a parametric environment—bridge components, code checks, analysis calculations, and workflows are all defined as reusable library objects. Understanding this will help you get the most out of the platform. {% endhint %} # System Requirements ## Browser | Requirement | Details | | ----------------------- | -------------------------------------------------- | | **Supported Browsers** | Google Chrome (recommended), Edge, Mozilla Firefox | | **Not Supported** | Internet Explorer, Safari | | **Minimum RAM** | 12 GB | | **Required Technology** | WebGL enabled | {% hint style="success" %} **Recommended:** Google Chrome offers the best performance due to its faster Chromium V8 engine. Our default test environment is Chrome. {% endhint %} **Useful Links:** * [Download Google Chrome](https://www.google.com/chrome/) * [Test WebGL Support](https://get.webgl.org/) *** ## OpenBrIM Launcher Chrome throttles background tabs to save resources, which can significantly slow down analysis and result extraction when minimized. The OpenBrIM Launcher configures Chrome for optimal performance: | Feature | Benefit | | ------------------- | ------------------------------------------------------ | | Background analysis | Runs at full speed when minimized | | Result extraction | \~50% speed when minimized (vs. near-zero without) | | Isolated profile | Keeps OpenBrIM sessions separate from regular browsing | **Download:** Copy the script below and save it as `OpenBrIM-Launcher.bat`: ```batch @echo off setlocal enabledelayedexpansion title OpenBrIM Launcher set "CONFIG=%USERPROFILE%\.openbrim_config" if exist "%CONFIG%" ( set /p COMPANY=<"%CONFIG%" echo. echo Using saved company: !COMPANY! echo Opening https://!COMPANY!.openbrim.org echo. set /p "CHOICE=Press Enter to continue or type 'change' to update: " if /i "!CHOICE!"=="change" goto :ask goto :launch ) :ask echo. echo Your OpenBrIM URL looks like: https://yourcompany.openbrim.org set /p "INPUT=Enter your company name only (e.g., wsp, kiewit, atkins, jacobs): " if "!INPUT!"=="" ( echo No company name entered. Exiting. pause exit /b ) :: Remove https:// if present set "COMPANY=!INPUT:https://=!" :: Remove http:// if present set "COMPANY=!COMPANY:http://=!" :: Remove .openbrim.org if present set "COMPANY=!COMPANY:.openbrim.org=!" :: Remove trailing slash if present set "COMPANY=!COMPANY:/=!" echo !COMPANY!>"%CONFIG%" echo Company name saved: !COMPANY! :launch start "" "C:\Program Files\Google\Chrome\Application\chrome.exe" ^ --disable-background-timer-throttling ^ --disable-renderer-backgrounding ^ --disable-background-tab-freezing ^ --disable-backgrounding-occluded-windows ^ --disable-hang-monitor ^ --disable-ipc-flooding-protection ^ --disable-gpu-vsync ^ --disable-features=CalculateNativeWinOcclusion,TabFreeze,TabGroupsCollapseFreezing,BackForwardCache,BackgroundMediaSuspend,IntensiveWakeUpThrottling ^ --user-data-dir="C:\ChromeProfiles\OpenBrIMSession" ^ --profile-directory=Default ^ --new-window "https://!COMPANY!.openbrim.org/" ``` {% hint style="info" %} **Note:** The script assumes Chrome is installed at `C:\Program Files\Google\Chrome\Application\chrome.exe`. If Chrome is installed elsewhere, update the path in the script. To find your Chrome path, type `chrome://version` in Chrome's address bar and look for "Executable Path". {% endhint %} No installation or admin privileges required. On first run, enter your company name (e.g., `companyname` for `companyname.openbrim.org`). The launcher saves your preference for future use. *** ## Enhancing Platform Performance Laptops and browsers often conserve battery by limiting hardware utilization. Adjust these settings for optimal performance. ### Use Discrete GPU **Step 1:** Check which GPU Chrome is using. Open `chrome://gpu/` and find "GL Renderer".
Chrome GPU info showing Intel graphics

Default: Chrome using integrated Intel graphics

**Step 2:** Open NVIDIA Control Panel (search "Nvidia" in Windows). Select Chrome or Edge and assign "High Performance Nvidia Processor".
NVIDIA Control Panel settings

NVIDIA Control Panel GPU assignment

**Step 3 (Alternative):** Search "Graphics Settings" in Windows, select "Desktop App", browse to your browser's .exe file, click "Options", and set your preferred GPU.
Windows Graphics Settings

Windows Graphics Settings

**Step 4:** Verify by reopening `chrome://gpu/`. Intel should no longer appear under "GL Renderer".
Chrome GPU info showing NVIDIA

Success: Chrome now using discrete NVIDIA GPU

*** ### Disable Browser Efficiency Mode {% tabs %} {% tab title="Chrome" %} Go to **Settings > Performance** and disable memory and energy saver features.
Chrome performance settings

Chrome Settings > Performance

Chrome energy saver disabled

Disable energy saver

{% endtab %} {% tab title="Edge" %} Disable these features in Edge settings: * Efficiency Mode * Improve Your PC Gaming * Sleeping Tabs
Edge efficiency settings

Edge efficiency settings

Edge sleeping tabs

Disable sleeping tabs

{% endtab %} {% endtabs %} *** ### Windows Power Settings Click the battery icon on the taskbar and set the slider to maximum performance.
Windows power slider

Set power mode to Best Performance

*** ### OpenBrIM Performance Settings **Control Compilation Scope** Reduce compilation time by toggling FEM or Detailing on/off. See [Pause / FEM / Detailing Bar](https://github.com/openbrim/platform/blob/master/docs/library/getting-started/navigation-within-openbrimapp/projects/project-ui/pause-fem-detailing-bar.md). **Simplify Rendered Elements** Deactivate rendering of bolts or shear studs if they significantly impact compilation time.
Bolt rendering settings

Toggle bolt/stud rendering in the spreadsheet

**Performance Profiling** Identify which objects impact compilation time by appending `&perf=1` to your project URL.
URL with perf parameter

Add &perf=1 to the URL

After compilation, access the performance report from the settings menu:
Settings menu

Open settings menu

Performance report option

Select performance report

Performance report results

Review compilation times by operation

# Sign up / Sign In ## Create an Account {% hint style="danger" %} **Enterprise Customers** Do NOT register at openbrim.org. Use your company-specific URL: `https://yourcompany.openbrim.org` Replace `yourcompany` with your actual company name (e.g., **Acme Engineering** → `acme.openbrim.org`). Your space administrator will review and approve your account. For optimal performance, see [System Requirements](/openbrim/getting-started/system-requirements). {% endhint %} **Step 1:** Open [openbrim.org](https://openbrim.org/www/brim/) in Google Chrome.
OpenBrIM homepage

OpenBrIM homepage

**Step 2:** Click **SIGN-IN** in the menu bar.
Sign-in button location

Sign-in button in the menu bar

**Step 3:** Click **Create an Account**.
Create account link

Create an Account link

**Step 4:** Enter your information and click **Sign Up**.
Registration form

Fill in the registration form

*** ## Sign In **Step 1:** Open [openbrim.org](https://openbrim.org/www/brim/) in Google Chrome. **Step 2:** Click **SIGN-IN** in the menu bar. **Step 3:** Enter your email and password, then click **Login**.
Login form

Enter credentials and click Login

*** ## Bookmark for Quick Access Add OpenBrIM to your bookmarks bar for easy access.
Bookmarks bar

OpenBrIM in the bookmarks bar

# How to create a bridge model in OpenBrIM Platform? OpenBrIM uses **parametric modeling** to define all bridges. Instead of drawing geometry manually, you define parameters that drive the entire model. *** ## Parametric vs. Traditional Modeling | Aspect | Traditional Modeling | Parametric Modeling | | ------------------ | --------------------------------------- | ------------------------------------------------------ | | **Input** | Draw lines, surfaces, enter coordinates | Define parameters (span length, girder depth, etc.) | | **Making changes** | Manually update each affected element | Change one parameter, everything updates automatically | | **Reusability** | Start from scratch each project | Reuse components across projects | | **Error risk** | High (manual updates can be missed) | Low (automatic propagation) | {% hint style="info" %} **How it works:** When you change a parameter (e.g., span length), OpenBrIM automatically updates all related elements—3D geometry, finite element model, drawings, and reports—in real-time. {% endhint %} *** ## The OpenBrIM Library The OpenBrIM Library stores parametric components with built-in engineering relationships. This provides: * **Transparent logic** — See how components relate to each other * **Customization** — Modify components or create your own * **Reusability** — Use the same components across multiple projects * **Collaboration** — Share custom components with your team *** ## Typical Workflow | Step | Action | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | **1. Requirements** | Work with OpenBrIM engineers to identify project needs and customize library components | | **2. Alignment** | Import LandXML alignment data | | **3. Parameters** | Enter bridge parameters in the spreadsheet | | **4. Review** | Check the model in 3D, FEA, and CAD views | | **5. Analysis** | Run finite element analysis and review results | | **6. Design** | Run specification checks and generate reports | | **7. Quantity Takeoff** | Generate quantities with pay items for cost estimation | | **8. Export** | Export to other FEA software to verify analysis results, or export 3D/2D models with pay items to meet agency submission requirements |
OpenBrIM workflow overview

OpenBrIM Platform workflow overview

*** ## Customization Need a parameter that doesn't exist? You have two options: 1. **Customize the library yourself** — Modify existing components or create new ones 2. **Work with our team** — OpenBrIM engineers can add parameters to meet your requirements Custom components become part of your library and can be reused across all future projects. # Navigation within OpenBrIM.App This guide covers navigating the OpenBrIM platform and accessing its key features. If you're new to OpenBrIM, we recommend starting with the video tutorial below. ## Video Tutorial {% embed url="" %} *** The Navigation Bar is located in the top-right corner and remains visible throughout the platform.
Navigation bar

Navigation bar location

*** ## Main Tabs | Tab | Description | | ------------ | ----------------------------------------------------------------------------------------- | | **Projects** | Your bridge projects. Open existing projects, access shared projects, or create new ones. | | **Library** | Standard library components available in your workspace. | | **Authors** | Library components developed by users in your workspace. Create new components here. | | **Test** | Test projects for verifying platform and library components with new releases. |
Navigation demo

Switching between tabs

*** ### Projects This is the default view when you launch OpenBrIM. The Projects tab is where you manage all your bridge models. * **Open existing projects** you've created * **Access shared projects** from colleagues in your workspace * **Create new projects** from library templates *** ### Library The Library tab contains standard parametric components that define bridge elements, analysis methods, and design checks. * Browse available components by category * View component parameters and documentation * Components here are maintained and updated by OpenBrIM *** ### Authors The Authors tab shows library components developed by users in your workspace. * **Fork standard components** to create customized versions for your projects * **View custom components** created by your team * **Create new components** to extend the standard library * **Share components** with other users in your workspace {% hint style="info" %} Use the Authors tab when you need to customize existing components or build new ones for project-specific requirements. {% endhint %} *** ### Test The Test tab contains projects specifically for testing the platform and library components. * Add your own projects as test cases * Automatically verify projects work correctly with new OpenBrIM releases * Catch issues early when library components are updated # Projects The Projects tab is the default view when you launch OpenBrIM. Here you can create new projects, open existing ones, or access projects shared by colleagues.
Projects tab overview

Projects tab interface

*** ## Main Actions | Button | Description | | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | **NEW** | Create a new project using predefined templates tailored to different bridge types or specific tasks | | **OPEN** | Access your previously created projects and projects shared with you by others | | **HELP** | Open documentation and help resources. Enterprise users can also reach support via Slack. Community users can contact | | **User Name** | Access your account settings, teams, and profile information | # Create New Project ## Ways to Start a New Project | Method | Description | | ---------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | **Use a template** | Start from standard templates tailored to specific bridge types | | **Duplicate existing** | [Copy an existing project](/openbrim/getting-started/navigation-within-openbrimapp/projects/open-project) as a starting point | | **From snapshot** | Create from a saved project revision | {% hint style="info" %} You can also import additional bridge templates into an existing project after it's created. This allows you to combine multiple bridge types or add components from different templates. {% endhint %} *** ## Templates ### OpenBrIM Templates Standard templates developed by OpenBrIM engineers and selected community contributions. These are production-ready and maintained. ### Templates From Authors Community-created templates that haven't been added to the standard collection yet. {% hint style="info" %} **What is a template?** A template is a pre-configured collection of library components organized for a specific bridge type or task. It streamlines project creation by including only relevant components and organizing them in a logical workflow. {% endhint %} *** ## Template Differences Different templates show different components in the tree view based on the bridge type. | Steel I Girder | Tub Girder | | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | ![I Girder tree](https://openbrim.atlassian.net/wiki/download/attachments/2101641268/image-20231020-152743.png?api=v2) | ![Tub Girder tree](https://openbrim.atlassian.net/wiki/download/attachments/2101641268/image-20231020-153207.png?api=v2) | For example, Tub Girder templates include cross-frames and bottom flange stiffeners that aren't in I Girder templates. *** ## Customization **Can I customize a template?** Yes. Enterprise clients work with OpenBrIM engineers to customize library objects at no extra cost. Community users can add library components using the search icon above the tree view. **How do templates become standard?** When OpenBrIM engineers create custom components for enterprise projects, they evaluate whether these could benefit all similar projects. If yes, the components become part of the standard template. Private or agency-restricted components remain in the client's workspace only. *** ## Organizing Projects Use **categories** to group related projects (e.g., bridges from the same physical project) into folders.
Category field

Enter a category to organize projects

You can then [share each project with team members](/openbrim/getting-started/navigation-within-openbrimapp/projects/projects-users). *** ## Create a Project **Step 1:** Click **New** on the left sidebar.
New button

Click New to start

**Step 2:** Select a template category (e.g., PennDOT Refined Analysis Submissions).
Template category

Select template category

**Step 3:** Select the specific template (e.g., PennDOT LRFD Curved).
Template selection

Select template

**Step 4:** Enter the project name and category.
Project name

Enter project name

**Step 5:** Click **Create**. # Open Project The Open view displays your projects and projects shared with you. Each project has action icons for common operations. *** ## Project Actions | Icon | Action | Description | | ------------- | --------------- | ----------------------------------------------------------------------------------------------------- | | **Duplicate** | Create copy | Creates a new project from an existing one. Useful for starting similar projects or creating backups. | | **Folder** | Change category | Moves the project to a different category folder for better organization. | | **Share** | Copy link | Copies a shareable link to your clipboard. | {% hint style="warning" %} **About Sharing:** Sharing a project link does NOT grant write access. It only allows users with an account in your workspace to view the project. {% endhint %} *** ## Organizing with Folders Use categories to group related projects together.
Folder organization demo

Creating and organizing project folders

*** ## Duplicating a Project Create a new project based on an existing one. This copies all project data as a starting point.
Duplicate project demo

Duplicating a project

*** ## Sharing a Project Share a link to allow other workspace users to view your project.
Share project demo

Sharing a project link

*** ## Bulk Sharing: Multiple Projects with Multiple Users Use the **Manage User Project Access** feature to share multiple projects or entire folders with multiple users at once. | Field | Description | | ------------------------------ | ------------------------------------------------------- | | **Select Folders** | Choose entire folders to share all projects within them | | **Select Individual Projects** | Pick specific projects to share | | **User Emails** | Enter email addresses of users to grant access | | **Permission Level** | Choose access level: Read Only or Write | | **Action** | Add Users or Remove Users | **Steps:** 1. Click the **team icon** in the Open Projects toolbar 2. Select folders or individual projects on the left 3. Enter user email addresses on the right 4. Choose the permission level 5. Click **Apply Changes** {% hint style="success" %} This is the fastest way to onboard new team members or grant access to an entire project category at once. {% endhint %} # Project UI The Project UI is your workspace for viewing, editing, and analyzing bridge models. It consists of several key areas: the top bar, left sidebar, graphics window, and data window.
Project UI overview

Project UI layout

*** ## Top Bar The top bar provides quick access to project actions and settings.
Top bar

Project top bar

### Project Actions | Action | Description | | ------------------------------- | ---------------------------------------------------------------------------------------------- | | **New Project** | Create a new project from templates | | **Open Project** | Access existing projects or shared projects | | **Import** | Import LandXML (terrain/alignment), LARSA 4D (.lar), CSI SAP2000 (.s2k), or Midas (.mct) files | | **Export** | Export project data to various file formats | | **Share** | Copy project link for sharing (view-only access) | | **View FEA Logs** | View logs from the last analysis run and see if anything changed since then | | **Clear FEA Results** | Delete local analysis results from your browser to free up disk space | | **Manage Local FEA Results** | View all analysis results stored on your machine | | **Add to Verification Profile** | Include project in automated testing that runs with each OpenBrIM release |
New and Open Project demo

Creating and opening projects

### Library Updates When library updates are available, a notification button appears automatically. Click it to update your template objects. {% hint style="warning" %} **Before updating:** Library updates may change 3D, FEM, and Spec Check behavior. They might add inputs or modify existing ones. Do not update if your project has been submitted to an agency unless you need new features. Enterprise customers should consult release notes in Slack and contact OpenBrIM support first. {% endhint %} *** ## Left Sidebar The left sidebar provides access to all project views and settings. | Option | Description | | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | **Model** | 3D parametric model visualization | | **FEA** | Finite element analysis model | | **CAD** | 2D CAD drawings | | **Docs** | Documents and reports | | **Project Site** | Set project local origin on the map and view alignments. The local origin defines the reference point for computing X-Y-Z coordinates. | | **Users** | Manage project access permissions | | **Revisions** | Access revision history and snapshots | | **Source Code** | Edit ParamML source (advanced users) | | **Help** | Open documentation site |
View switching demo

Switching between views

### Documents View The Documents view displays: * **Parametric reports** - Dynamic reports that update based on project inputs (available after compilation) * **Uploaded files** - PDFs, images, and other files with options to view, download, share, and digitally sign
Documents view

Documents view

Upload files by dragging and dropping or using the Upload File button. Create folders for organization. *** ## Performance Controls Control compilation behavior for large models using the toolbar at the top center of the graphics window.
Performance controls

Pause/FEM/Detailing controls

### Save and Compile Timers Click the clock icon to customize save and compile timers. | Timer | Default | Description | | ----------- | ---------- | -------------------------------------------------------------------------------------------------------- | | **Save** | 10 seconds | Waits after last change before saving to cloud. Resets if you make another change. | | **Compile** | 5 seconds | Waits after last modification before starting parametric computation. Resets if you make another change. |
Timer settings

Timer configuration

### Save Status Indicators | Icon | Status | | ------- | ----------------------------------- | | Cloud | All data saved | | Spinner | Unsaved data - do not close browser | {% hint style="info" %} OpenBrIM automatically saves every 2 minutes regardless of timer settings to prevent data loss. {% endhint %} ### Toggle Controls | Control | Function | | ------------- | ------------------------------------------------------------------------------------------------------------- | | **Pause** | Disable auto-refresh. Data saves but model doesn't update. Click Play when ready to recalculate. | | **FEM** | Toggle finite element calculations (mesh, etc.). 3D view remains active when disabled. | | **Detailing** | Toggle detailed elements (reinforcement, bolts, holes). Keep disabled during analysis for faster compilation. |
Pause demo

Using Pause mode

*** ## Data Window The data window is where you enter project parameters. It consists of the tree view and spreadsheet. ### Tree View Each tree item represents a library object. Templates organize objects following the bridge engineering workflow: alignment → geometry → analysis → design → reports. {% hint style="info" %} Different templates show different tree structures based on bridge type. For example, Tub Girder templates include cross-frames and bottom flange stiffeners not found in I Girder templates. {% endhint %} ### Spreadsheet OpenBrIM uses familiar Excel-style spreadsheets for data entry. | Feature | Description | | ------------------ | -------------------------------------------------------------------- | | **Info icon** | Opens documentation for the selected object | | **Cell actions** | Right-click or use three-dot menu for copy, paste, parametric values | | **Fill handle** | Drag cell corner to copy values to adjacent cells | | **Arrow keys/Tab** | Navigate between cells | | **Header actions** | Filter, sort, and adjust decimal places | | **Undo** | Reverse last entry |
Cell copy demo

Copying cell values

Resize the data window by dragging the Data bar. Resize the tree view by dragging its border.
Data window resize demo

Adjusting data window layout

*** ## 3D Model View The 3D view displays your parametric bridge model with interactive controls.
3D Model view

3D Model view

### Mouse Controls | Action | Control | | ------------------ | ------------------------------------- | | **Zoom** | Scroll wheel | | **Rotate** | Hold left mouse button and drag | | **Pan** | Hold scroll wheel and drag | | **Zoom to object** | Click object, then click Zoom Extents |
Rotate demo

Rotating the model

{% hint style="info" %} After zooming to a specific object, rotation will center around that object. {% endhint %} ### View Tools | Tool | Function | | ---------------- | -------------------------------- | | **Zoom Extents** | Fit all objects in view | | **Objects list** | Show/hide individual objects | | **View cube** | Set camera to specific direction | | **Settings** | Access 3D view options | ### 3D View Settings | Setting | Description | | -------------------- | ---------------------------------------------------------- | | **Clipping Plane** | Create section cuts through the model | | **Roadway Surface** | Show/hide roadway (displays alignment as line when hidden) | | **Measure Distance** | Measure between selected objects |
Clipping plane

Section cut using clipping plane

### Object Actions Click on any 3D object to access: | Icon | Action | | ----------- | ----------------------------- | | Eye | Isolate, hide, or show object | | Opacity | Adjust transparency | | Spreadsheet | Open related parameters | | Delete | Remove from project |
Isolate and hide demo

Isolating and hiding objects

*** ## Finite Element Model View The FEA view displays the analytical model used for structural analysis.
FEA view

Finite Element Model view

This view shows: * Nodes and elements * Boundary conditions * Applied loads * Analysis results (displacements, forces, stresses) *** ## CAD View The CAD view displays 2D parametric drawings generated from your model.
CAD view

CAD drawing view

CAD drawings update automatically when model parameters change. # Projects Revisions OpenBrIM automatically saves project revisions to the cloud, creating a complete history of all changes made by any user. *** ## Viewing Revisions Click **Revisions** in the left sidebar to view all saved revisions organized by date.
Revisions list

Revision history by date

*** ## Revision Actions | Action | Description | | ---------------- | ----------------------------------------------------------------------------- | | **Share** | Copy a shareable link to a specific revision | | **View Changes** | See modification history including date, time, user, and step-by-step changes | | **Revert** | Restore the project to a previous revision | | **Copy Project** | Duplicate the project from a specific snapshot |
Revision actions demo

Working with revisions

*** ## Work Log Add notes to revisions using the work log in the bottom left corner of the graphics window. These notes appear in the revision details.
Work log

Work log entry

{% hint style="info" %} Work log entries help team members understand what changes were made and why. {% endhint %} # Projects Users By default, projects are only visible to the user who created them. Grant access to other users as needed. *** ## Managing Access Click **Users** in the left sidebar to view and manage project access.
Users panel

Project users panel

### User Actions | Action | How | | ------------------- | ------------------------------------------------------ | | **Add user** | Click the plus icon and enter the user's email address | | **Set permissions** | Choose Read Only, Write, or Admin access | | **Remove user** | Click the delete icon next to the user |
Managing users demo

Adding and managing project users

*** ## Permission Levels | Level | Can View | Can Edit | Can Manage Users | | ------------- | -------- | -------- | ---------------- | | **Read Only** | Yes | No | No | | **Write** | Yes | Yes | No | | **Admin** | Yes | Yes | Yes | *** ## Real-Time Collaboration OpenBrIM supports simultaneous collaboration using WebSocket technology. When one user makes changes, all other users with access see updates automatically. Changes are recorded in the revision history. {% hint style="info" %} **Working on different scenarios:** If you want to explore different options without affecting your colleague's work, duplicate the project. Each copy has its own independent revision history. {% endhint %} *** ## Sharing Options {% hint style="warning" %} **Understanding share types:** * **Project link:** Recipients with workspace access see the current project state (view-only unless given write access) * **Revision link:** Recipients see only that specific snapshot, not subsequent changes * **User access:** Added users can view full revision history regardless of their permission level {% endhint %} # Library ![](https://openbrim.atlassian.net/wiki/download/attachments/2101739561/image-20230329-152229.png?api=v2) The effectiveness of the OpenBrIM Platform mostly comes out of the OpenBrIM Library. OpenBrIM Library provides parametric definitions for all things engineering customizable to be used with many structures. All structural and non-structural components are created in this central repository. For example, bridge structures can be envisioned as a collection of components such as the deck, traffic barriers, girders and cross-frames, bearings, piers, and abutments. Components like piers and abutments comprise smaller components like piles, footings, columns, walls, caps, and steel reinforcing. These individual components can be defined with a relatively small number of parameters. Any component can be developed into a standard bridge component by identifying the minimum data parameters necessary to define it completely. A simple example is a rectangular concrete footing, where three variables – width, length, and thickness – can be used to define the outline shape. All similar rectangular footings for a bridge can use the exact geometric definition by defining different width, length, and thickness variables for each footing. All needed is to locate their position in the overall structure by defining a reference point on the component, its station, offset, and elevation along the bridge alignment. Other non-geometric data can also be associated with the component, such as material type or date constructed. All of these parameters form the standard data required to define the component. A complete bridge model is developed by combining all standard components into an assembly. Components are designed to work with each other to be connected and stacked up, just like Lego pieces. OpenBrIM App allows users to put these components together to easily create even the most complex models by setting a few parameters. The OpenBrIM Library provides a home where these components can be developed, organized, and hosted in an open and collaborative environment. The bridge model shown in the figure above is assembled using the individual components defined in the OpenBrIM Library. Individual components that were used to make the bridge model are shown below. ![](https://openbrim.atlassian.net/wiki/download/attachments/2101739561/image-20221104-122010.png?api=v2) Below is a YouTube video demonstrating various types of library components that include 3D representations, analytical representations, rebars, AASHTO chapters, code check components, and load rating components. # Authors **Authors:** The Authors tab in OpenBrIM displays the library components that have been developed by other users in your workspace. If you wish to create new library components, you may also use this tab. ![](https://openbrim.atlassian.net/wiki/download/attachments/2195161314/image-20230407-114639.png?api=v2) # Test OpenBrIM.Test is an on-cloud real-time verification and testing system through which applications can be tested and verified on-demand through easy-to-set-up test models. There are already hundreds of test cases available in OpenBrIM.Verify through OpenBrIM.Library. Users can add their verification problems through OpenBrIM.Incubator or add their project files to the verification system within the OpenBrIM Platform app. ![](https://openbrim.atlassian.net/wiki/download/attachments/2195980289/image-20231023-124835.png?api=v2) ![](https://openbrim.atlassian.net/wiki/download/attachments/2195980289/image-20231023-124928.png?api=v2) # CADD This section describes the CAD primitives used to draft 2D drawings inside an OpenBrIM project — plan views, elevations, cross sections, deck plans, foundation plans, details, and the dimensions and annotations that go on top of them. Each primitive has its own page covering what it's for, the parameters that control it, and how to edit it in the CAD viewer. The "i" button in the property panel for each shape opens its page directly. The same pages are linked from the FEA / CAD trees in the spreadsheet view. ## Document and layers * [CAD Document](/templates/cadd/cadd-document) — the top-level container for a 2D drawing (a sheet's worth of geometry). * [Level (CAD Layer)](/templates/cadd/level-cadd) — the layer system that controls per-shape color, line weight, and dash style. ## Geometric primitives * [Line](/templates/cadd/line-cadd) — open polyline of two or more points; for centerlines, leaders, breaklines, working lines. * [Circle](/templates/cadd/circle-cadd) — circle by center and radius; for piles, dowels, anchor bolts, drilled-shaft outlines. * [Rectangle](/templates/cadd/rect-cadd) — rectangle by center, width, and height; for pier outlines, footings, plates, panels. * [Arc](/templates/cadd/arc-cadd) — arc of a circle; for fillets, return arcs, curved abutment outlines. * [Ellipse](/templates/cadd/ellipse-cadd) — ellipse by two radii; for elliptical foundations and aesthetic curves. * [Bezier Curve](/templates/cadd/bezier-cadd) — smooth curve shaped by control points; for transitions and aesthetic boundaries. * [Curve](/templates/cadd/curve-cadd) — smooth curve passing through every control point; for surveyed traces and splines. * [Container](/templates/cadd/container-cadd) — group of shapes that move, rotate, and style together. ## Background and 3D-derived * [Background Image](/templates/cadd/backgroundimage-cadd) — raster or PDF reference underlay for tracing. * [CADD From 3D](/templates/cadd/caddfrom3d-cadd) — auto-generated 2D projection from a specific 3D object. * [CADD From Section](/templates/cadd/caddfromsection-cadd) — auto-generated 2D section view driven by an alignment (cross sections, profile elevations, deck plans). ## Dimensions * [Linear / Aligned Dimension](/templates/cadd/dimensionline-cadd) — distance between two points (horizontal, vertical, or aligned). * [Angular Dimension](/templates/cadd/dimensionangular-cadd) — angle between two lines (skew angles, turning angles). * [Radius Dimension](/templates/cadd/dimensionradius-cadd) — radius of an arc or circle. * [Diameter Dimension](/templates/cadd/dimensiondiameter-cadd) — diameter of a circle (piles, drilled shafts, anchors). * [Arc Length Dimension](/templates/cadd/dimensionarclength-cadd) — length along a curved edge. * [Elevation Dimension](/templates/cadd/dimensionelevation-cadd) — elevation above datum (top of pier, top of deck, etc.). * [Ordinate Dimension](/templates/cadd/dimensionordinate-cadd) — coordinates of a point relative to an origin. * [Slope Dimension](/templates/cadd/dimensionslope-cadd) — grade between two points (percent, ratio, or rise per run). ## Annotations * [Station Offset](/templates/cadd/stationoffset-cadd) — alignment-relative point callout (Station + Offset). * [Text](/templates/cadd/text-cadd) — free-form text block. * [Leader Note](/templates/cadd/note-cadd) — text with a leader arrow pointing at a feature. * [Pin](/templates/cadd/pin-cadd) — fixed-size symbol marker for highlighting a point. * [Revision Cloud](/templates/cadd/cloud-cadd) — scalloped boundary marking a revised region. * [Section Callout](/templates/cadd/sectioncallout-cadd) — section reference bubble (`A` / `A`, `B` / `B`). ## Common concepts **Levels (layers).** Every shape belongs to a Level, which controls color, line weight, and dash style. Routing styling through Levels rather than per-shape is what gives bridge drawings their conventional look — heavy black for cut concrete, light gray for working lines, dashed for hidden, red for revisions. **Alignment-driven drawings.** When the parent CAD Document is bound to an alignment, shapes drawn in flat coordinates are automatically bent to follow the bridge geometry — straight lines become curved over horizontal curves, rectangles become trapezoidal in plan, etc. Useful for working lines, footprints, and overlays that should track the alignment without being redrawn on every revision. **Drawings that update with the model.** Section views (CADD From Section), 3D-derived views (CADD From 3D), and dimensions all rebuild automatically when the underlying 3D model or alignment changes. You author the drawing once and the geometry stays correct across revisions. # CAD Document A **CAD Document** is the top-level container for a 2D drawing — a sheet's worth of geometry: shapes, dimensions, annotations, layers, and any auto-generated section views the drawing pulls from the 3D model. Every shape in OpenBrIM CAD lives inside one CAD Document; you typically have one per sheet (one for the General Plan, one per Cross Section sheet, one for the Pier Elevation sheet, and so on). The CAD Document is also where alignment drives the drawing. When the document is bound to an alignment, every shape drawn in flat coordinates is automatically bent to follow the bridge geometry — useful when you want a working line, plan footprint, or layout shape that tracks the alignment without redrawing it on every revision. ## Geometry **Origin X / Origin Y / Origin Z:** Where the document's local origin sits in world space. Use to place the drawing's `(0, 0)` at a meaningful project location — for example, the alignment start, a working point at a pier centerline, or a survey monument. **Translate X / Translate Y:** Translation applied to all shapes within the document. Use to nudge the drawing's content as a whole without moving the origin. **Flip X:** Mirror the drawing about its vertical axis. Useful for drawing the left-side abutment as a mirror of the right when both abutments share geometry. ## Alignment binding **Align Long Direction:** Which CAD axis maps to "along the alignment." Default `CADDX` — the document's horizontal axis runs along the alignment. Switch to `CADDY` for drawings where the alignment runs up the page (north-up orientation). **Align Trans Direction:** Which CAD axis maps to "across the alignment" (perpendicular). Default `CADDY`. **Align Refine Distance:** When alignment-bending is on, this controls how often intermediate points are inserted to keep curves smooth. Smaller values produce smoother curves at the cost of heavier files. Default 120 (project length units) is right for typical highway bridges; reduce to 30 or 60 for tight horizontal-curve detail sheets. When the document has no alignment bound, all alignment-related parameters are inert and shapes are drawn in flat coordinates. ## Display **Thickness:** Default line weight applied to shapes that don't override it. **Line Style:** Default dash pattern. These document-level defaults are convenient for quickly setting "this whole sheet is heavy line weight" without having to set every shape — but for production drawings, prefer routing styling through Levels (layers) so it's per-layer, not per-document. ## Notes A CAD Document doesn't have its own scale or sheet size; those are sheet-layout concerns handled outside the drawing. Inside the document, geometry is in real units (feet, meters) — the same units as the rest of the project. Levels (layers) created inside a CAD Document are local to that document. To share a level set across multiple documents, define the levels at the project level and reference them from each document. # Level (CAD Layer) A **Level** is the CAD equivalent of a layer (in DWG/DXF terminology). Every shape, dimension, and annotation in a CAD document is assigned to a Level, and the Level controls how that shape is drawn — color, line weight, dash style. Routing styling through Levels rather than setting it shape-by-shape is what gives bridge drawings their conventional look (heavy dark lines for cut concrete, light gray for centerlines, dashed for hidden, red for hot work) without manually styling every shape. Every CAD document has at least a "Default" level, created automatically. Add more for the conventions your sheets need: Centerlines, Hidden, Working, Concrete, Steel, Hardware, Bearings, Foundations, etc. ## Properties **Name:** Identifier of the level. Used when assigning shapes to levels — set the shape's Level field to this name. Conventions: capitalize and avoid spaces (e.g., `Concrete`, `WorkingLines`). **Color:** Color used for shapes assigned to this level. Hex (`#000000`) or RGB (`rgb(0, 0, 0)`) format. Black for cut lines on plotted sheets, red for hot work / revision callouts, gray (`#888888`) for projection and reference lines. **Thickness:** Line weight in plot units. Heavy weights (3.0–4.0) for cut concrete on a section, medium (1.5) for projection, light (0.5–1.0) for centerlines and working lines. **Line Style:** Dash pattern for the level. Choices include solid, dashed, dotted, dashdot, center, hidden, phantom. Match to drafting conventions: solid for visible cut and outline lines, hidden for occluded edges, center for centerlines. ## Typical level set A practical starting set of levels for bridge drawings: | Level | Color | Weight | Style | Use | | -------------- | --------- | ------ | ------ | ------------------------------------ | | **Default** | Black | 1.0 | Solid | Catch-all for unassigned shapes. | | **Cut** | Black | 3.0 | Solid | Heavy cut lines on sections. | | **Projection** | Dark gray | 1.5 | Solid | Visible silhouette behind cut. | | **Hidden** | Gray | 1.0 | Hidden | Hidden / occluded silhouette. | | **Centerline** | Red | 1.0 | Center | Centerlines, axis symbols. | | **Working** | Gray | 0.5 | Dashed | Construction working lines. | | **Concrete** | Black | 2.0 | Solid | Cut concrete, hatched concrete fill. | | **Steel** | Black | 2.0 | Solid | Cut/visible steel members. | | **Bearings** | Dark gray | 1.5 | Solid | Bearing devices and pads. | | **Hardware** | Dark gray | 1.0 | Solid | Anchor bolts, dowels, connectors. | | **Dimension** | Black | 0.5 | Solid | Dimension lines and text. | | **Notes** | Black | 0.7 | Solid | Text annotations, leader lines. | ## Notes Levels are local to their CAD document — defining "Concrete" in one document doesn't automatically share it with another. For consistent conventions across many sheets, define levels in a shared project-level location and reference them. Shapes always show with their level's color/weight/style unless the shape itself explicitly overrides those values. The override path exists for one-off shapes that need to look different from their level — but for production drawings the conventional approach is "shape gets a level, level dictates style." # Line A **Line** is a polyline of two or more points used for drafted linework that doesn't need to enclose a region. In bridge drawings you'll reach for it for centerlines, leader lines, breaklines, finish-grade traces, working lines, and any free-form 2D path that traces along but doesn't bound an area. To draw a closed shape that gets filled, use a Rectangle, Circle, or Container instead. To draw: pick the first point, pick subsequent points, and either double-click or press **Enter** to finish. Right-click during drawing for the in-progress menu (cancel, undo last point, finish). With **Single Segment** mode enabled, drawing ends automatically after the second point — useful for laying out single-segment grid lines and reference lines. ## Geometry **Name:** Identifier of the line within its parent CAD document. Must be unique within the document. **Level:** The layer the line is drawn on. The layer controls color, line weight, and dash style. Useful for routing all centerlines to a "Centerlines" layer, all working lines to a "Working" layer, and so on. **Offset X:** Horizontal offset of the line's origin from the parent CAD document's origin. All vertices are drawn relative to this origin. **Offset Y:** Vertical offset of the line's origin from the parent CAD document's origin. **Points (readonly):** The number of vertices currently in the polyline. A valid line has at least two. **Total Length (readonly):** The end-to-end length of the polyline (sum of segment distances), shown in the project's preferred length unit. Reflects any alignment-driven bending if the parent CAD document is alignment-based. ## Editing **Add a vertex:** click on the line in edit mode to insert a vertex on the closest segment. **Move a vertex:** drag the vertex handle to reposition. The two adjacent segments stretch to follow. **Remove a vertex:** right-click a vertex and choose Remove. The line must keep at least two vertices. **Offset:** move the cursor to one side of the line and drop to create a parallel offset. For 2-point lines the offset is a true parallel translation; for multi-vertex polylines each segment offsets perpendicularly and corners are intersected. ## Notes A Line does not close on itself regardless of how many vertices it has, so it can't be filled as a region. If you need a closed path through arbitrary points (e.g., to hatch a non-rectangular footing footprint), use a Container with a closed polyline instead. When the parent CAD document is driven by an alignment, the line's vertices are bent to follow the alignment — a horizontal line drawn flat becomes an arc over a horizontal curve. This is what produces working lines that follow the bridge geometry without redrawing them on every revision. # Circle A **Circle** is defined by a center point and a radius. In bridge drawings you'll use it for piles in foundation plans, dowels and anchor bolts in details, drilled-shaft centerlines, hole layouts, plan-view circular columns, and any feature that's truly circular rather than a polygonal approximation. To draw: click once to place the center, then click again to set the radius. The radius is the distance between the two click points. A dashed preview line during drawing shows the current radius. ## Geometry **Name:** Identifier within the parent CAD document. Must be unique. **Level:** The layer controlling color, line weight, and dash style. Common assignments: "Piles" for foundation plans, "Hardware" for dowel and anchor bolt symbols. **Center X:** Horizontal coordinate of the circle's center. **Center Y:** Vertical coordinate of the circle's center. **Radius:** Distance from the center to the circle. Must be positive. **Diameter (readonly):** Twice the radius. Shown for convenience when dimensioning by diameter. **Circumference (readonly):** Length around the circle. Useful for rebar length take-offs on circular columns. **Area (readonly):** Plan area enclosed. ## Editing **Move the center:** drag the center handle to translate the circle. **Resize:** drag any of the four quadrant handles (top, bottom, left, right) to change the radius. The center stays fixed; the radius updates symmetrically. **Snap:** other shapes can snap to the center and to the four quadrant points (cardinal points on the circle). **Offset:** create a concentric copy at a fixed distance — useful for showing pile-cap clearances around piles. ## Notes When the parent CAD document is driven by an alignment, the circle's center is bent onto the alignment, but the circle stays a circle (it does not warp into an ellipse over a horizontal curve). This is the right behavior for piles and anchor bolts — they should remain round in plan even when the bridge is curved. If you need a circular shape that does warp with the alignment (e.g., a circular hatch pattern that follows the bridge curvature), use a Container with a closed polyline approximating the circle. # Rectangle A **Rectangle** is a four-sided closed shape defined by a center point, width, and height — with optional rotation about the center. In bridge drawings you'll use it for pier outlines in plan, abutment footprints, footing plans, deck panels, plate steel, bearing pads, anchor pockets, and any rectangular region that should be parameterized by Width × Height rather than four corner points. To draw: click once to place the first corner, then click again at the opposite corner. The center, width, and height are computed from those two clicks. ## Geometry **Name:** Identifier within the parent CAD document. Must be unique. **Level:** The layer controlling color, line weight, and dash style. Typical: "Substructure" for pier outlines, "Foundation" for footings, "Hardware" for plates and bearings. **Center X:** Horizontal coordinate of the rectangle's center. **Center Y:** Vertical coordinate of the rectangle's center. **Width:** Length along the horizontal direction (before rotation). The rectangle extends `Width / 2` to either side of the center. **Height:** Length along the vertical direction (before rotation). The rectangle extends `Height / 2` above and below the center. **Rotation:** Rotation about the rectangle's center, applied after Width × Height layout. Positive is counter-clockwise. Use this to draw skewed pier footprints in plan, or to lay out plates that aren't axis-aligned. **Perimeter (readonly):** `2 × (Width + Height)`. Useful for formwork take-offs. **Area (readonly):** `Width × Height`. **Diagonal (readonly):** Diagonal length, computed for spreadsheet display. ## Editing **Move the rectangle:** drag any edge (away from a corner) to translate as a whole. **Resize from a corner:** drag a corner handle to change Width and Height simultaneously. The opposite corner stays fixed. **Resize from a midpoint:** drag a side midpoint to change only Width or only Height. The opposite side stays fixed. **Rotate:** drag the rotation handle (outside the bounding box) to set the rotation. The center stays fixed. **Snap:** the four corners and the four side midpoints are exposed as snap points. ## Notes When the parent CAD document is driven by an alignment, a rectangle drawn in flat coordinates is bent so each side follows the alignment — straight horizontal sides become arcs over horizontal curves, and corners shift to keep the shape closed. For pier footprints in plan, this gives you a footprint that actually follows the bridge geometry without redrawing it when the alignment changes. For details that should stay axis-aligned regardless of alignment curvature (a steel plate elevation, for example), put the rectangle in a CAD document that is **not** alignment-driven. If you need explicit corner control instead of Width × Height (a four-point trapezoidal shape, a skewed-quadrilateral footprint), use a Container with four points instead — that bypasses the Width × Height parameterization and lets you place each corner directly. # Arc An **Arc** is a portion of a circle defined by a center, radius, start angle, and sweep angle. In bridge drawings you'll use it for fillets between intersecting members, return arcs on parapet ends, curved abutment wingwall outlines, drilled-shaft outlines, and any place where you need a true circular sweep rather than a polyline approximation. To draw: pick the center, then the start point (which sets the radius and start angle), then a final point (which sets the sweep angle). ## Geometry **Name:** Identifier within the parent CAD document. Must be unique. **Level:** The layer controlling color, line weight, and dash style. **Center X / Center Y:** Coordinates of the arc's center. **Radius:** Distance from the center to the arc. **Start Angle:** Angle (in degrees) where the arc begins, measured counter-clockwise from the horizontal axis. **Arc Angle:** Sweep — total angle the arc covers from start to end. Positive values sweep counter-clockwise, negative clockwise. **Start X / Start Y / End X / End Y:** Endpoint coordinates (read-only — derived from center, radius, and angles). ## Editing **Move the center:** drag the center handle to translate. **Resize:** drag any of the four quadrant handles to change the radius. Center stays fixed. **Adjust the sweep:** drag either endpoint handle to change the start angle or sweep angle while keeping the radius fixed. **Snap:** other shapes can snap to the center, the start, the end, and the midpoint of the arc. ## Notes For full circles use a Circle, not an Arc with sweep 360°. For very flat arcs (sweep angle below \~5°) the result is nearly indistinguishable from a straight line at typical drawing scales — use a Line instead unless the arc is drawn at large scale and the curvature matters visually. When the parent CAD document is alignment-driven, the arc's center is placed onto the alignment, but the arc itself stays a true circular arc (it does not warp into an elliptical curve over a horizontal curve). # Ellipse An **Ellipse** is defined by a center point and two radii (semi-major and semi-minor axes). In bridge drawings it's a less common primitive than Circle or Rectangle but useful for elliptical foundation outlines, eccentric pad layouts, drainage pickup boundaries, and aesthetically curved features. ## Geometry **Name:** Identifier within the parent CAD document. Must be unique. **Level:** The layer controlling color, line weight, and dash style. **Center X / Center Y:** Coordinates of the ellipse's center. **Radius 1:** Semi-major axis length — the longer of the two radii. **Radius 2:** Semi-minor axis length — the shorter of the two radii. **Rotation:** Rotation about the ellipse's center. By default, Radius 1 is horizontal; rotate to align the major axis with a different direction. ## Editing **Move:** drag the center handle to translate. **Resize:** drag the four axis-end handles to change Radius 1 or Radius 2 independently. The center stays fixed. **Rotate:** drag the rotation handle to align the major axis with the desired direction. ## Notes For a true circle (Radius 1 = Radius 2), use a Circle — circles take a single radius and have purpose-built quadrant snap points that ellipses don't expose in the same way. When the parent CAD document is alignment-driven, the ellipse's center is placed onto the alignment, but the ellipse itself stays a true ellipse (it does not warp further over horizontal curves). # Bezier Curve A **Bezier Curve** is a smooth curve defined by control points. The curve passes through the first and last control points and is shaped (without passing through) by the intermediate ones. In bridge drawings it's used for transitions, aesthetic boundaries, and any place where you need a continuous, smoothly curved path that's easier to control than a polyline approximation. To draw: pick the start point, then intermediate control points that pull the curve, then the end point. Press Enter or double-click to finish. ## Geometry **Name:** Identifier within the parent CAD document. Must be unique. **Level:** The layer controlling color, line weight, and dash style. The curve's shape is controlled by its child Point objects (the control points). The first and last points are anchors (the curve passes through them); the middle points pull the curve toward them without the curve actually touching them. ## Editing **Move a control point:** drag the handle to reshape the curve. The curve updates continuously. **Add a control point:** insert a new control point on the curve to gain finer control over a region. **Remove a control point:** right-click and remove if you want to simplify the curve. ## Notes For polyline shapes through a known set of vertices, use a Line — it's simpler and the result is exact at every vertex. For interpolating curves that should pass through every input point (rather than be pulled by intermediate ones), use a Curve instead. Beziers are best for curves with two or three control points; longer chains become harder to control intuitively. For complex aesthetic shapes it's often easier to stitch several short Beziers together end-to-end. # Curve A **Curve** is a smooth interpolating curve that passes through every control point — unlike a Bezier, which is shaped by intermediate points without passing through them. In bridge drawings it's used for splines through known stations, profile traces sampled from a survey, and any path that should hit a specific set of points exactly while flowing smoothly between them. To draw: pick each interpolation point in turn. Press Enter or double-click to finish. ## Geometry **Name:** Identifier within the parent CAD document. Must be unique. **Level:** The layer controlling color, line weight, and dash style. The curve's shape is controlled by its child Point objects, which are the points the curve passes through (in order). ## Editing **Move a point:** drag the handle to relocate one of the points the curve passes through. The curve reshapes to remain smooth and continue passing through every point. **Add a point:** insert a new point at the desired location and the curve will route through it. **Remove a point:** the curve simplifies between the two adjacent points. ## Notes For straight-segment polylines (where corners are sharp, not smoothed), use a Line. For smooth curves where you want intermediate control without the curve passing through specific points, use a Bezier. Curves are useful for tracing irregular surveyed profiles or for drafting a soft curve through a known set of locations on a drawing — for example, a finish-grade trace that has to hit specific elevations at specific stations. # Container A **Container** groups several CAD shapes together so they can be moved, rotated, scaled, and styled as a unit. Inside the container the shapes keep their individual properties; the container adds an outer layer of position, rotation, and visibility on top of all of them. Use a Container when: * You're drawing a repeated detail (a typical bearing pad assembly, a typical anchor bolt arrangement, a typical drainage pickup) and want to place several copies — you draw it once inside a Container, then place container instances at each location. * You need a closed shape through arbitrary points that can't be expressed as a Rectangle, Circle, or other primitive — put the points inside a Container and set IsClosed = true. * A logical group of shapes (everything that makes up "Pier 3 footprint", everything that makes up "Wingwall A elevation outline") should travel together as you re-layout the sheet. ## Geometry **Name:** Identifier within the parent CAD document. Must be unique. **Level:** Default level applied to shapes inside the container that don't override it. Setting a level on the container is a quick way to assign a whole detail to one layer without setting it on every child. **Center X / Center Y:** Position of the container's local origin in the parent document's coordinate system. All children are drawn relative to this origin. **Rotation:** Rotation applied to all children about the container's origin. **Scale:** Uniform scale factor applied to all children. **Is Closed:** When true, the container is treated as a closed region. Children that form a continuous polyline are connected end-to-end, allowing the region to be filled or hatched. ## Editing **Move the group:** drag the container's origin handle to translate every child together. **Rotate the group:** drag the rotation handle to rotate every child about the container origin. **Edit a child shape:** double-click a child to enter the container and edit individual shapes inside; press Escape to return to the parent context. **Add a shape to the container:** drop a new shape while inside the container's edit context. Shapes added at the parent level can also be moved into a container after the fact. ## Notes Containers can nest — a Container can contain other Containers. Use sparingly; deeply nested containers can be hard to navigate when you need to edit a deeply nested shape. When the parent CAD document is alignment-driven, every shape inside the container is bent by the alignment as if it were drawn directly in the parent. The container itself doesn't change the alignment behavior — it just lets you transform a group of shapes as one. If you find yourself copying the same group of shapes across many CAD documents (a typical bearing detail, a typical drainage detail), consider promoting the group to a project-level reusable detail rather than recreating it as a Container each time. # Background Image A **Background Image** places a raster image or PDF page as a reference underlay in a CAD document. Use it for: * Tracing geometry from a scanned existing-conditions drawing or as-built sheet. * Overlaying a survey site plan or aerial ortho beneath the proposed bridge layout. * Showing a reference detail from another sheet without duplicating it as native geometry. * Comparing a proposed alignment against a topographic map. The background image is purely visual — it doesn't snap, dimension, or participate in 3D model geometry. It exists to give you something to draw against. ## Source **Document:** Path or reference to the image file (PNG, JPG, TIFF) or PDF. **Image Type:** `image` for raster images, `pdf` for PDF pages. **Page:** PDF page number (PDF source only). Page 1 is the first page. **Max Render Size:** Maximum pixel resolution at which the image is rendered. Default 3000 is right for most uses; reduce for faster screen drawing on slower machines, increase only if you need to zoom in to fine detail in the image. ## Placement **Center X / Center Y:** Where the image's center sits in the CAD document's coordinate system. **Width / Height:** Display size of the image in real units. Set to match the image's true scale — if the image is a sheet that printed at 1"=20', set Width and Height to the real-world dimensions of what's shown. **Rotation:** Rotation about the center. **Scale:** Additional scale factor on top of Width / Height. Use to fine-tune the size against a known dimension on the image (for example, set the width approximately, then scale until a known distance on the image matches a known distance in the drawing). ## Aligning a background to your drawing The most common task with a background image is getting it positioned correctly: 1. Drop the image into the CAD document. 2. Set Width and Height to approximate real-world dimensions of what's pictured (a survey sheet that's 22" × 34" at 1"=50' would be roughly 1100' × 1700'). 3. Use Rotation to orient north-up if needed. 4. Move the image until a known feature (a survey monument, a property corner, a pier location) lines up with the same feature in your drawing. 5. Adjust Scale and Rotation iteratively until two or three reference points all match. 6. Lock the image's level (if your project supports level locking) so it doesn't move accidentally as you draft over it. ## Notes Background images don't participate in section views — CADD From Section won't pick up an image as if it were geometry, and dimensions can't measure pixels. The image is a visual reference only. For PDFs, only one page renders at a time; if the source PDF has multiple sheets, drop in multiple Background Image objects with different Page numbers. Very large or high-resolution images can slow down redraw. Set Max Render Size below 3000 if you find scrolling sluggish. # CADD From 3D **CADD From 3D** generates a 2D drawing from any 3D object in the project — a pier, a girder, a bearing assembly, a foundation block — by projecting it onto a plane. Use it when you want a 2D view of a specific 3D component (an isolated pier elevation, a bearing detail, a wingwall outline) without going through the alignment-based CADD From Section workflow. CADD From Section is the right tool when the cut should follow an alignment (cross sections, profile elevations, deck plans). CADD From 3D is the right tool when the view should be aligned to a specific 3D object's local axes — useful for component-level details that don't reference the bridge alignment. ## What gets drawn **Object:** The 3D object to project. Pick any 3D component in the project (pier, girder, bearing, abutment, footing, etc.). The resulting 2D drawing is the projection of that object's outline onto the view plane. ## View orientation **Rotation X / Y / Z:** The view plane's orientation. Default `(0, 0, 0)` produces a top-down view (looking down the world Z axis). Common settings: * Plan view: `(0, 0, 0)` — looking straight down. * Front elevation: `(90, 0, 0)` — looking horizontally along Y. * Side elevation: `(90, 0, 90)` — looking horizontally along X. For an arbitrary view, set the rotation angles to align the view normal with the direction you want to look from. **Anchor X / Y / Z:** The point about which the view rotation is applied. Set to a meaningful point on the 3D object (its centroid, or a specific corner) so the view stays centered as you adjust rotations. ## Clipping **Clip X1 / X2:** Horizontal extent of the view (in the view plane's local coordinates). Limits the drawing to a window — useful when the 3D object extends beyond what you want to draw. **Clip Y1 / Y2:** Vertical extent of the view. **Clip Z1 / Z2:** Depth extent (perpendicular to the view plane). Geometry outside this depth range is excluded from the drawing. Set the clipping ranges generously by default (large positive and negative numbers); tighten them only when you need to exclude specific parts of the 3D object. ## Notes CADD From 3D produces a single projection of the 3D object onto a plane. It doesn't classify lines as Cut vs Projection (CADD From Section does); every line in the result is a visible silhouette/outline edge of the 3D object as seen from the view direction. For an isolated component drawing — a single bearing assembly detail, a single pier elevation independent of the alignment — CADD From 3D is the simplest way to get a 2D outline without manually tracing. For drawings that should follow the alignment (cross sections at any station, profile views along the bridge, deck plans), use CADD From Section instead — the alignment-based workflow handles station-relative positioning, skew, and superelevation that CADD From 3D doesn't. # CADD From Section **CADD From Section** generates a 2D drawing automatically by cutting through your 3D bridge model along an alignment. It is how you produce the cross-sections, elevations, and deck plans on your drawing sheets without redrawing them by hand. Every time the bridge geometry changes — span lengths, pier locations, deck thickness, bearing offsets — the section drawing rebuilds from the latest model. You decide: * **Where the cut goes** (a station along the alignment for a cross section, an offset from centerline for a profile, an elevation for a plan). * **Which view** (cross section perpendicular to alignment, longitudinal profile parallel to alignment, or top-down plan). * **What's shown and how it's drawn** (which objects appear, which don't, which line weights and colors, how each line is offset for theoretical-position dimensions). Everything else — finding the right intersection of every face with the cut plane, sorting cut from projection from hidden, following horizontal curves and superelevation — happens automatically. ## Choosing the alignment **Alignment:** The bridge alignment that drives the cut. The section's position is expressed *relative to* this alignment — by station, by offset from centerline, or by elevation — so when the alignment changes (bridge geometry revised, station equation added, profile updated), every section view that references it updates with the new geometry. If the project has multiple alignments (e.g., centerline, ramp, ground), pick the one the section is naturally referenced against — usually the bridge centerline for cross sections and elevations, the ramp/centerline for ramp sections. If you change which alignment a section uses, the cut location is interpreted in the new alignment's stationing, not converted from the old one. ## What kind of view The **Clip Mode** parameter selects between three cuts. Each is appropriate for different drawing types. ### Cross — for cross-section drawings A vertical plane perpendicular to the alignment at one station. Use this for: * Pier elevation / pier section drawings (one section per pier) * Bent and bent-cap details * Deck cross sections at any reference station * Skewed pier cuts (combine with Skew Angle below) The view's horizontal axis runs left-to-right along the bridge cross direction; the vertical axis runs up. Looking at the drawing, you're standing up-station looking down-station (toward higher stations), unless **Flipped** is on. **Station:** Distance along the alignment where the cut is taken. A station of zero is the alignment's start. **Skew Angle:** Additional rotation of the cut plane about vertical, in degrees. Use to draw skewed pier cuts on bridges where piers cross the alignment at an angle (for example, a 30° skew on a pier crossing a curved alignment). ### Profile — for elevation drawings A vertical plane parallel to the alignment, offset to one side by a perpendicular distance. The cut runs the full length of the alignment and the result is unrolled onto a flat sheet, so even on a curved bridge, the elevation reads straight: stations along the bottom, elevations along the side. Use this mode for: * Bridge elevation sheets (the headline drawing) * Girder profile views with bearings, joints, and pier locations marked * Long-span profile sheets where you want to see the full alignment in one view **Offset:** Perpendicular distance from the alignment to the cut. Positive offset is to the right of the alignment when looking up-station; negative is to the left. Offset zero cuts on centerline. Offset to one side for a girder line; offset further for a parapet or fascia line. ### Plan — for plan-view drawings A horizontal cut producing a top-down view. **Plan Sub-Mode** picks between three flavors: * **Flat** — A single horizontal cut at one elevation across the whole project. Use this for foundation plans, footing layouts, and any plan where you want a true horizontal slice at one elevation. Set **Elevation** to the cut elevation. * **Vertical Profile** — The cut follows the alignment's profile grade — the cut elevation rises and falls with the bridge. Use this for top-of-deck plans and any plan that should track the bridge grade rather than sit at a fixed elevation. Set **Profile Offset** to the vertical distance above (positive) or below (negative) the alignment's centerline elevation. For a top-of-deck plan, this is roughly half the deck thickness. * **Profile w Cross Slope** — Same as Vertical Profile, but the cut also tilts to follow the cross slope (superelevation). Use this for top-of-deck plans where superelevation matters — bearing seat layouts, drainage details, anything where the deck surface isn't flat in cross section. **Elevation** — The cut elevation (Flat sub-mode only). **Profile Offset** — Vertical offset from the alignment profile (Vertical Profile and Profile w Cross Slope sub-modes). **Flipped:** Reverses the view normal. Use when the cut puts you on the opposite side of the structure from where you want to see it. ## Projection depth A section drawing usually shows two kinds of lines: the **cut** (what the plane sliced through) and the **projection** (what's behind, drawn as silhouette). Projection depth controls how much of "behind" gets drawn. **Near Depth:** Distance in front of the cut plane (toward the viewer) within which projection edges are still drawn. Default zero — clips strictly at the cut plane. Increase if you want to see geometry that sits in front of the cut, useful for stepped sections. **Far Depth:** Distance behind the cut plane (away from the viewer) within which projection edges are drawn. Set to a small value for a clean section with no clutter behind the cut, or to the full pier width / span length to see the complete silhouette. For a clean pier elevation sheet, set Far Depth to the pier's full thickness so the back face of the pier shows as a projection line behind the section line — without including the next pier's projection. **Tolerance:** Distance band within which a face is treated as exactly on the cut plane. Default `0.001` (in your project's length units) is right for most projects. Increase to `0.005` or `0.01` if a coplanar face — typically a deck top, top of footing, or top of pier cap — isn't being picked up as a cut line. ## Showing and hiding objects Section drawings often show too much. Bridge sections especially: girder cross-frames, miscellaneous metal, drainage hardware, future reservations. The Objects panel lets you remove these without modifying the model. **Hide an object:** uncheck the box next to its name in the Objects panel. The object's cut, projection, and centerlines all disappear. Right-click for "Hide all of this type" (e.g. hide every cross-frame at once), "Show only this object" (isolate), or "Show all" to reset. **Hide a category for a type:** the per-row checkboxes (Cut / Projection / Hidden / Centerline) let you keep an object but suppress one of its line classes. Common uses: turn off projection for parapets in a pier section so they don't clutter the view; turn off centerlines for bearings in an elevation drawing. **Hide a single edge:** in the Edges panel, the eye icon next to a chain hides only that edge. Use for visually distracting edges that aren't structurally meaningful (back-of-fillet duplicates, etc.). ## Edge offsets — drawing to theoretical positions Bridge details often dimension to theoretical positions rather than to as-modeled geometry. A bearing seat top is dimensioned to its theoretical seat elevation (not to the modeled-thickness top), a pier face is dimensioned to its theoretical face (not to the as-modeled formliner inset). The **Edge Offsets** dialog lets you push individual edges parallel to themselves by a specified distance. Click "Edges" on an object's row, pick the chain (top, bottom, left, right — labels are auto-generated based on each chain's orientation), and type a distance. Positive offsets push the edge outward (away from the object centroid), negative inward. Corners adjust automatically so the offset rectangle stays a rectangle. This is for drawing presentation only — the underlying 3D model is unchanged. ## Levels and line styling By default the section uses four line categories: * **Cut** — heavy black, solid. The "section line" — bold so it dominates. * **Projection** — medium gray, solid. Visible silhouette behind the cut. * **Hidden** — light gray, dashed. Hidden silhouette (off by default). * **Centerline** — red, center-line dash. Beam centerlines, axis symbols. You can route any object type's edges to a CAD level instead, so the level's color, weight, and dash style apply. This is the right way to set conventions like "all cut concrete on a Concrete level" or "all girder lines on a Steel level" — assign once in the Level Mappings and any new girder added to the model picks up the correct styling automatically. ## Showing the alignment on the drawing The alignment(s) that the cut intersects can be drawn as centerlines on top of the section, with station ticks. Per-alignment settings in the Alignment Display dialog: * **Visible** — Show or hide the alignment line. * **Show Stations** — Whether to label every interval-th station with text. * **Color** — Hex color for the alignment line and ticks. * **Station Interval** — Distance between station ticks (50 for elevation drawings, 10 for detail sections). * **Tick Size** — Tick mark length on screen. For a typical pier section, hide the alignment display (no centerline overlays the structure). For an elevation drawing, show the alignment with station ticks every 50 ft (or 10 m) and station labels on. ## Common workflows ### Pier section sheet 1. Drop a CADD From Section into a CAD document. 2. Set **Alignment** to the project centerline. 3. Set **Clip Mode** to **Cross** and **Station** to the pier's station. 4. If the pier is skewed to the alignment, set **Skew Angle** to match. 5. In the Objects panel, hide deck-only items (parapets, barrier rails, lighting standards) so the pier dominates. 6. Map cut concrete to a "Concrete" level so cut-line styling matches your sheet conventions. ### Bridge elevation 1. CADD From Section → **Clip Mode = Profile**, **Offset = 0** (alignment centerline). 2. **Far Depth** = the half-width of the widest pier so the full pier silhouette projects. 3. **Near Depth** = 0 so geometry in front of the cut is clipped. 4. In Per-Type Visibility, turn off Projection for the parapets (they crowd the elevation). 5. In Alignment Display, show the alignment with station ticks every 50 ft. 6. Add station offsets and elevation dimensions on top of the section. ### Top-of-deck plan with superelevation 1. CADD From Section → **Clip Mode = Plan**, **Plan Sub-Mode = Profile w Cross Slope**. 2. Set **Profile Offset** = +half the deck thickness so the cut sits at top of deck. 3. In Per-Type Visibility, turn off Projection per type (you only want what's at the deck surface). 4. Map bearing edges to a "Bearings" level so they show with bearing-line conventions. 5. Add station-offset annotations at the bearing centerlines. ### Foundation plan 1. CADD From Section → **Clip Mode = Plan**, **Plan Sub-Mode = Flat**. 2. Set **Elevation** to your foundation working elevation (top of footing). 3. Hide everything except substructure objects in the Objects panel. 4. Add ordinate dimensions for footing corners. ## Troubleshooting **Nothing draws.** The cut plane is missing the model. For Cross mode, check Station against the alignment range. For Profile, check Offset against the model's transverse extent. For Plan / Flat, check Elevation against the model's vertical extent. If only projection is missing, Far Depth is at the default zero — increase it. **A flat surface (e.g. deck top, top of footing) isn't being picked up as a cut line.** Raise Tolerance from `0.001` to `0.005` or `0.01` and refresh. The face is just outside the band the cut considers "on plane." **Hidden objects come back after a model rebuild.** They were renamed by the rebuild — re-hide under the new name. Hidden state is keyed to object name. **Section is correct but mirrored.** Toggle **Flipped**. The default view direction may be putting you behind the structure. **Profile section has angular polylines where you expect smooth curves.** The alignment's resolution is too coarse. Refine the alignment. **Sections don't update after a model change.** They should — open and close the CAD document, or use Refresh. If they still don't update, the objects in the cut were deleted and re-added with new names; re-open the section's Objects panel to verify. **Edge offsets don't stick after editing geometry upstream.** Edge identification is based on the object's edge order, which can change if the underlying 3D mesh is regenerated. Re-pick the edge in the Edge Offsets dialog and the offset reapplies. # Linear / Aligned Dimension A **Linear / Aligned Dimension** measures and labels the distance between two points. The value updates automatically when the model geometry changes, so dimensions on a pier section stay correct as the pier resizes, span lengths change, or bearing offsets are revised. Three dimensioning directions: * **Horizontal** — measures the horizontal projection of the distance (typical for plan-view widths and elevation-view spans). * **Vertical** — measures the vertical projection (typical for heights, depths, profile elevations). * **Aligned** — measures the true distance along the line connecting the two points (typical for skewed dimensions and slope lengths). ## Pick points Pick the first point, then the second, then a leader position offset from the dimensioned line. The dimension's value is the distance between the two points. For section drawings, snap to corners, midpoints, or centers of the cut shapes (piers, footings, deck edges, bearings). For plan drawings, snap to pile centers, pier corners, abutment faces. ## Text and units **Label:** Override text. Leave blank to use the auto-computed value (the default). **Prefix:** Text shown before the value (e.g., `~` for approximate, `±` for tolerance). **Suffix:** Text shown after the value (e.g., a unit symbol if not using auto-units). **Unit Style:** How the value is formatted. Fractional (`6'-3 1/4"`), Decimal with symbol (`6.27'`), or Decimal with name (`6.27 ft`). **Length Unit:** Override the project's length unit. Default uses the project's preferred unit. Set to a specific unit (in, ft, yd, mm, cm, m, km) to show one dimension differently from the rest. **Precision:** Number of decimal places (or fractional precision for fractional unit style). ## Direction and placement **Aligned:** When yes, the dimension follows the line between the two points (true distance). When no, the dimension is constrained to a horizontal or vertical projection per the Axis setting. **Axis:** For non-aligned dimensions, sets the projection direction: Horizontal, Vertical, or Auto (picks based on the leader location). **Text Fit:** What to do when the value's text doesn't fit between the two extension lines. Shrink (auto-shrink the text), Move Outside (place text outside the lines), or Always Outside (always place outside). **Flip Text:** Mirror the text to read from the other side. **Offset X / Offset Y:** Fine-tune the leader's position relative to the dimensioned line. ## Typography **Text Height:** Text size in real units (e.g. 0.1 m or 0.3 ft for typical bridge sheet text at 1"=10' scale). **Font Family:** Font face. Default a standard sans-serif font. **Font Weight:** Bold or normal. **Font Style:** Italic or normal. ## Notes Dimensions live on a Level like any other shape — assign to a "Dimensions" level so all dimensions on a sheet pick up consistent styling. When the underlying geometry changes (a pier widens, a span lengthens), the dimension value updates automatically. If a dimension's leader becomes badly placed after a geometry change, drag the leader handle to a better location — the value follows the geometry. # Angular Dimension An **Angular Dimension** measures and labels the angle between two lines, two rays, or three points. In bridge drawings you'll use it for skew angles at piers and abutments, turning angles at intersection bridges, beam orientation angles, and any angular relationship that needs to be called out. Pick two lines (or three points defining two rays from a common vertex), and the dimension shows the angle between them. ## Text and units **Label:** Override text. Leave blank to use the auto-computed angle. **Prefix:** Text before the value. **Suffix:** Text after the value. Default `°`. **Precision:** Number of decimal places. 0 for whole degrees (typical for skew angles), 1–2 for finer angles. ## Placement **Offset X / Offset Y:** Position the arc's distance from the vertex. Larger offset draws the arc farther out from the vertex (useful when the angle is in a tight corner with other geometry nearby). ## Typography **Text Height:** Text size in real units. **Font Family / Font Weight / Font Style:** Font controls (default sans-serif, normal weight, normal style). ## Notes For skew dimensions on pier outlines, the angle is typically called out as the angle from a perpendicular reference (the alignment normal) — pick the alignment direction and the pier face direction as the two rays. For very small angles (under \~3°), the rendered arc can be tiny and hard to read; either increase Offset to push the arc out where the curvature shows, or call the angle out as a slope dimension instead. # Radius Dimension A **Radius Dimension** labels the radius of a circular arc — fillet returns, parapet ends, drilled-shaft outlines, curved deck edges, anything where a radius callout is the right way to communicate the curvature. Pick the arc or circle, and the dimension shows its radius with a leader from the curve to a label. ## Text and units **Label:** Override text. Leave blank to use the auto-computed radius. **Prefix:** Text before the value. Default `R` (the conventional radius callout prefix). **Suffix:** Text after the value (e.g., a unit symbol). **Precision:** Number of decimal places. **Unit Style / Length Unit:** Units for the radius value. Same options as Linear Dimension. ## Typography **Text Height:** Text size in real units. **Font Family / Font Weight / Font Style:** Font controls. ## Notes Use a Radius Dimension when the curvature itself is the key feature being communicated — fillet returns, parapet end radii, transition curve radii. For circular openings (piles, drilled shafts) where the diameter is the more natural callout, use a Diameter Dimension instead. The radius arrow conventionally points from the label to the arc. Drag the leader handle to position the label. # Diameter Dimension A **Diameter Dimension** labels the diameter of a circular feature — piles, drilled shafts, anchor bolts, dowels, casings, circular openings, round columns. Use diameter for closed circular features; use Radius Dimension for arcs and curved edges. Pick the circle, and the dimension shows the diameter with a leader. ## Text and units **Label:** Override text. Leave blank to use the auto-computed diameter. **Prefix:** Text before the value. Default `⌀` (the conventional diameter symbol). **Suffix:** Text after the value. **Precision:** Number of decimal places. **Unit Style / Length Unit:** Units for the diameter value. ## Placement **Center X / Center Y:** Override the leader's pivot point. Default uses the dimensioned circle's center. ## Typography **Text Height:** Text size in real units. **Font Family / Font Weight / Font Style:** Font controls. ## Notes For piles and drilled shafts, the standard convention is `⌀ ` (e.g., `⌀ 24"`). For anchor bolts and dowels, the standard is also diameter, often combined with a length and quantity in a separate note (e.g., `(4) ⌀ 1" × 18" anchor bolts`). When dimensioning many identical circles (a pile group, a bolt pattern), call out one and add a note describing the rest, rather than placing one diameter dimension per circle. # Arc Length Dimension An **Arc Length Dimension** measures the length along a curved edge — the actual curved distance, not the chord between endpoints. In bridge drawings it's used for the arc length of curved parapets, curved deck edges over horizontal curves, transition arcs, and any place where the curved distance is what matters (for take-offs of curved railings, curb runs along curves, etc.). Pick the arc, and the dimension shows the length along the curve. ## Text and units **Label:** Override text. Leave blank to use the auto-computed arc length. **Prefix:** Text before the value. Default `⌢` (arc-length symbol). **Suffix:** Text after the value. **Precision:** Number of decimal places. **Unit Style / Length Unit:** Units. ## Typography **Text Height:** Text size in real units. **Font Family / Font Weight / Font Style:** Font controls. ## Notes If the arc is shallow enough that the chord and the arc length are nearly equal, a Linear Dimension across the chord is often clearer than an Arc Length Dimension along the curve. Reserve arc-length callouts for curves where the difference between chord and arc matters (long, sharp curves; transition spirals; curved railing runs at small radii). # Elevation Dimension An **Elevation Dimension** labels the elevation (height above a datum) of a point. In bridge drawings it's the standard callout for top of pier, top of footing, top of deck, top of girder, top of bearing, and any reference elevation on a profile or section drawing. Pick a point, and the dimension shows its elevation. The label is typically placed with a leader pointing to the elevated feature, and the format follows drafting conventions like `EL. 234.50` or `EL. 234.50 m`. ## Text and units **Datum Elevation:** Reference datum for the elevation value. Default zero (true world elevation). Set to a non-zero datum to label elevations relative to a project benchmark — for example, a project where all elevations are referenced to a survey datum 100 ft below world zero. **Label:** Override text. **Prefix:** Text before the value. Default `EL.` (the conventional elevation prefix). **Suffix:** Text after the value (e.g., the unit symbol). **Precision:** Number of decimal places. 2 is typical (e.g., `EL. 234.50`). **Unit Style / Length Unit:** Units. ## Placement **Offset X / Offset Y:** Leader offsets — fine-tune label position. ## Typography **Text Height:** Text size in real units. **Font Family / Font Weight / Font Style:** Font controls. ## Notes For profile views, place elevation dimensions at every key point: top of pier, top of footing, finish grade at abutment, top of deck at bearings, top of parapet. Each elevation is automatically computed from the snapped point's world Z coordinate (adjusted by Datum Elevation). If you change a pier's height, the elevation dimensions on top of pier and top of footing update automatically — no need to edit the labels. # Ordinate Dimension An **Ordinate Dimension** labels a point's coordinates relative to a reference origin — typically Northing/Easting or X/Y from a project datum. Use it for footing corner coordinates, pile coordinates, control points, and anywhere a coordinate callout (rather than a chained dimension) is the cleanest way to communicate position. Pick a point, and the dimension shows its coordinates as `(X, Y)` or `(N, E)` depending on local convention, relative to the document's origin (or a separately set datum). ## Text and units **Label:** Override text. **Prefix:** Text before the value. **Suffix:** Text after the value. **Precision:** Number of decimal places. 2 is typical for foot-units, 3 for meters. **Unit Style / Length Unit:** Units. ## Placement **Offset X / Offset Y:** Leader offsets — fine-tune label position. ## Typography **Text Height:** Text size in real units. **Font Family / Font Weight / Font Style:** Font controls. ## Notes Ordinate dimensions are most useful on plans where many points share a common reference origin and chained dimensions would clutter the drawing — pile coordinate schedules, footing corner schedules, working-point lists. Often paired with a points table that has the same coordinates in tabular form. For simple two-point distances, prefer a Linear Dimension. For coordinate schedules with many points, consider a Point and a separate coordinate table rather than per-point ordinate dimensions on the drawing. # Slope Dimension A **Slope Dimension** labels the grade between two points. Use it for profile-grade callouts (the longitudinal grade of a bridge), cross-slope callouts on deck plans, slope of approach roadway, and ramp grades. Pick two points, and the dimension shows the slope between them in your chosen format. ## Format **Slope Format:** How the slope is shown: * **Percentage** — `2.5%` (typical for highway profile grades). * **Ratio** — `1:50` (typical for embankment slopes, drainage slopes). * **Rise per Run** — `1/4" per 12"` or `2 mm per m` (typical for cross slope on bridge decks). **Show Direction:** Whether to draw a small arrow indicating the direction of fall. Default on. Useful for cross-slope callouts where the direction (toward gutter, toward median) needs to be visually clear. ## Text and units **Label:** Override text. **Prefix:** Text before the value. **Suffix:** Text after the value. **Precision:** Number of decimal places. 2 is typical for percentage; 0–1 for ratios. ## Typography **Text Height:** Text size in real units. **Font Family / Font Weight / Font Style:** Font controls. ## Notes For profile grade callouts on bridge elevation drawings, percentage format is conventional (`+2.5%`, `-1.8%`). For cross slope on deck plans, rise-per-run format is more readable (`1/4" per 12"`, `0.02 m/m`). For embankment and drainage slopes, ratio format is conventional (`1:50`, `1:3`). The slope is computed from the two snapped points' coordinates — vertical rise over horizontal run. If you change the profile grade by moving a pier or adjusting vertical curve parameters, the slope dimension updates. # Station Offset A **Station Offset** labels a point's location relative to an alignment as a Station + Offset pair: how far along the alignment the point sits, and how far perpendicular to it. This is the standard way to call out the location of bridge features in plan — pier centerlines, abutment back walls, bearing centerlines, expansion joints, drainage pickups, sign foundations. Pick a point, and the label shows its `Station` (distance along the alignment from the alignment start) and `Offset` (perpendicular distance from centerline; positive = right of stationing, negative = left). ## Text **Label:** Override text. Leave blank for the auto-computed `STA , OFF ` format. **Precision:** Number of decimal places. ## Placement **Offset X / Offset Y:** Leader offsets — fine-tune label position relative to the dimensioned point. ## Typography **Text Height:** Text size in real units. **Font Family / Font Weight / Font Style:** Font controls. ## Notes Station Offset annotations are essential on plan-view bridge drawings — every bearing centerline, pier centerline, joint location, and drainage pickup typically gets one. The label updates automatically when the alignment is revised, when piers are repositioned, or when bearings are moved. Station format follows highway conventions (e.g., `STA 12+34.50` for stations using the `+` separator), or the project's preferred format. The exact format depends on the alignment's stationing setup. For features that share a station but sit at multiple offsets (e.g., a row of bearings on one pier line), call out the station once and use Linear Dimensions for the offset spacing — cleaner than a Station Offset on every bearing. # Measure Length A **Measure Length** annotation reports the straight-line distance between two picked points. It is the quick "how far is that?" tool — unlike a Linear Dimension it draws no extension lines or arrowheads, just the measured line with its value written along it. Pick two points and the distance appears rotated to follow the line, flipped as needed so it never reads upside down. Because the points snap like any other CAD geometry, measuring to an endpoint, midpoint, center or intersection is exact rather than eyeballed. Use it for checking work — confirming a girder spacing, a clearance, a skew offset — where you want the number on screen but not a formal dimension in the drawing. ## Text and units **Label:** Override text, replacing the measured value. **Prefix / Suffix:** Text before and after the value (e.g., a unit symbol). **Precision:** Number of decimal places. **Unit Style / Length Unit:** Units. Unit Style selects fractional (`12' - 7" 3/4`), decimal with symbol (`26.87'`), or decimal with name (`26.87 feet`). Length Unit overrides the project geometry unit for this annotation only. ## Typography **Text Height:** Text size in real units. **Font Family / Font Weight / Font Style:** Font controls. ## Notes The clickable area covers the text band along the line, not just the thin line itself, so the annotation is easy to select and move. For a dimension that belongs in the issued drawing — with extension lines, arrowheads and drafting conventions — use [Linear / Aligned Dimension](/templates/cadd/dimensionline-cadd) instead. Measure Length is the working tool; the dimension objects are the deliverable. # Measure Area A **Measure Area** annotation reports the enclosed area *and* the perimeter of a picked polygon, written as a single label at the centroid — for example `Area: 412.500 sq ft, Perimeter: 84.250 ft`. Pick the boundary points and the shape closes automatically; the area comes from the closed polygon regardless of the order you picked, so a re-entrant or non-convex outline still measures correctly. Because the points snap like any other CAD geometry, tracing an existing deck outline or a hatched region is exact rather than eyeballed. Use it for quantity checks — deck surface, parapet elevation area, a patch of overlay, a plan footprint — where you want the number on screen but not a formal dimension in the drawing. ## Text and units **Label:** Override text, replacing the measured values. **Prefix / Suffix:** Text before and after the value. **Precision:** Number of decimal places. **Unit Style / Length Unit:** Units. Length Unit overrides the project geometry unit for this annotation only; the area is reported in the corresponding squared unit. ## Typography **Text Height:** Text size in real units. **Font Family / Font Weight / Font Style:** Font controls. ## Notes Both numbers are recomputed from the polygon whenever a boundary point moves, so editing the outline updates the quantity — there is no stale value to remember to refresh. For a measurement that belongs in the issued drawing, use the dimension objects instead; Measure Area is the working tool. Related: [Measure Length](/templates/cadd/measurelength-cadd). # Text A **Text** annotation places a free-form text block in a CAD document — labels, notes, callouts, sheet titles, view titles, anything that isn't a dimension or a leader note. For text with a leader arrow pointing at a feature, use a Note instead. ## Content **Text:** The text content. Multi-line is supported. ## Sizing and alignment **Size:** Text size in real units (e.g., `0.1 m` or `0.3 ft` for \~3 mm or 1/8" plotted text at 1=10 scale). **Width / Height:** Bounding box dimensions. Text wraps to fit the bounding box width if needed. **Text Align (horizontal):** Left, Center, or Right. Center is typical for view titles; Left for body text and labels. **Text Align V (vertical):** Top, Middle, or Bottom alignment within the bounding box. ## Styling **Level:** Layer assignment. Route to a "Notes" or "Text" level so all text on a sheet picks up consistent styling. **Color / Thickness / Line Style:** Override the level's styling for this specific text. ## Notes For sheet titles and view titles, use a larger Size and bold weight (set on the level). For dense body text (general notes, construction notes), keep size at the project's standard text height for readability at print scale. Text doesn't snap to underlying geometry — it's a free placement. Position by clicking. Drag to move. # Leader Note A **Leader Note** is a text annotation with a leader arrow pointing from the text to the feature being annotated. Use it for callouts that need to attach to specific geometry — material callouts on a section, dimension references, construction notes pointing to specific locations, revision callouts. For free-floating text without an arrow, use Text instead. ## Content **Text:** The note content. Multi-line is supported for longer callouts. **Size:** Font size in real units. **Arrow Size:** Size of the leader arrow head. Larger arrows for top-of-sheet callouts; smaller for dense detail areas. **Text Align V:** Vertical alignment of the text relative to its anchor point: Top, Middle, or Bottom. ## Placement A leader note has two anchor points — the text position and the leader's tip (where the arrow points). Drag either to reposition. For multi-segment leaders (where the arrow needs to bend around other geometry), drag the leader's intermediate handle to add a kink. ## Styling **Color / Thickness:** Color and weight of the leader line and arrow. **Level:** Layer assignment. ## Notes For material callouts (e.g., `Class A Concrete`, `ASTM A572 Gr. 50`), keep the text concise — long material specs belong in a notes block, not on a leader. For revision callouts referencing a Revision Cloud, use a small Note inside the cloud or with its leader pointing at the revised area, plus a revision-block reference somewhere on the sheet. # Pin A **Pin** is a fixed-size symbol marker that highlights a point on a drawing. Pins always render at a consistent screen size regardless of zoom, so they stay readable at any scale — useful for marking pile locations on a foundation plan that needs to print at multiple scales, sensor locations on an instrumentation plan, control points on a survey overlay, or any feature that needs a clear visual marker rather than a dimensioned callout. ## Style **W:** Pin width in screen pixels. Default 30. The pin renders at this fixed pixel size regardless of zoom level. **H:** Pin height in screen pixels. Default 30. **Image Type:** Pin shape: * **Pin** (default) — Map-pin style symbol with a teardrop head and a point. * **Arrow** — Arrow symbol pointing at the marked location. **Color:** Pin color. **Thickness:** Outline thickness. **Level:** Layer assignment. ## Placement A pin has a single anchor point — the location it marks. Click to place. Drag to move. ## Notes Use Pins sparingly. They're effective when there's exactly one or two important points to highlight; on a drawing with many pinned features, the pins crowd the drawing. For dense point markers (a pile group, a bolt pattern), use small Circles or filled symbols at real-world size instead. Because pins render at a fixed pixel size, they always remain readable when the drawing is plotted — but they don't scale with the rest of the geometry. If the drawing is shown at very small print scale, a pin can look disproportionately large; tune W and H accordingly for your sheet size. # Revision Cloud A **Revision Cloud** is a closed scalloped boundary used to mark a region of a drawing that has been revised. Standard drafting convention: when you issue a revised drawing, every change since the last issue is enclosed in a cloud and labeled with a triangle revision marker matching an entry in the title block's revision table. ## Drawing the cloud To draw, sketch the boundary of the revised region — the cloud follows the boundary as a series of small connected arcs. The cloud is closed automatically when you finish. ## Style **Thickness:** Cloud line weight. Match to your project's revision-cloud convention (typically heavier than dimension lines, lighter than cut lines). **Color:** Cloud color. Often red on screen for visibility, then plotted as black or as the project's revision color. **Level:** Layer assignment. Route to a "Revisions" level that matches your project's revision conventions. ## Placement After drawing, drag the cloud's outline handles to refine the boundary. Add a Pin or Note inside or beside the cloud with the revision number to complete the marker — clouds without revision numbers are ambiguous. ## Notes Each issued revision typically gets its own Revision Cloud level (or its own assigned color), so revisions from issue 1 vs issue 2 can be visually distinguished. After a revision is issued, it's standard practice to leave the previous issue's clouds visible (so reviewers can see the revision history) and add new clouds only for changes since. Revision clouds aren't dimensioned — they're a visual marker only. Don't try to use them for region boundaries that need precise definition; for that, draw a Container or a Line with the right vertices. # Section Callout A **Section Callout** is the symbol that marks where a section is taken on one drawing and refers to where the section view is shown on another drawing — the conventional `A` / `A` pair, `B` / `B`, etc. Place it on a plan or elevation drawing at the location of the cut, with text identifying the section and the sheet where it's drawn. ## Content **Text Top:** The text shown in the upper half of the callout circle. Conventionally the section letter (`A`, `B`, `C`, ...). **Text Bottom:** The text shown in the lower half. Conventionally the sheet number where the section is drawn (`S-3`, `12`, etc.). **Text Size:** Font size in real units. ## Geometry **Diameter:** Diameter of the callout circle in real units. Default 0.625" (a typical bridge-sheet section bubble size at 1"=10' scale). **Tail Type:** Whether the callout's tail points one direction (`Single`) or two (`Double` — typical when a section line crosses a complex feature with cuts taken on both sides). **Opposite Direction:** When true, the callout's arrow points opposite to its tail — useful when the cut direction is opposite to the natural reading direction of the bubble's text. ## Style **Color / Thickness / Level:** Standard styling. ## Notes A complete section callout pair consists of two bubbles connected by a line (the cut line, with arrows at each end indicating the view direction), or two separate bubbles at each end of a section line. Most projects standardize on one convention. For sections taken at fixed alignment stations, place the callout on the plan at the station, label as `` over ``, and add a Station Offset annotation nearby if the station number itself needs to be on the plan. # Parametric FEA Template OpenBrIM.Analysis is the world's first and only parametric, cross-platform, high-performance 3D finite element that runs in a browser. OpenBrIM supports all core finite element features specified in the OpenBrIM standard. Supported Element Types: * Spring Stiffness Element (Linear/Nonlinear) * 6x6 Stiffness Element (Linear) * Line Element (Linear/Nonlinear) (Elastic/Inelastic) * Surface Element (Linear/Nonlinear) * Volume Element All finite elements support local/global end offsets, global end releases, and overrides. Pre-stressing tendons also support pre-tension/post-tension, internal/external, and bonded/unbonded configurations and include elastic shortening and short- and long-term loss effects.\ OpenBrIM.The analysis provides immense customization options for loading cases allowing users to simulate the most complex loading conditions with ease: * Each loading case can be set to run in linear or nonlinear mode. * Element properties can be overridden for each loading case. * Finite elements can be activated, deactivated, or set as weight/stiffness for each load case. OpenBrIM.Analysis supports a wide range of loading capabilities: * Nodal loads and nodal displacement loads * Element loads * Temperature loads (uniform, linear, nonlinear gradient) * Prestressing loads * Vehicular and pedestrian live loads * Wind loading OpenBrIM.Analysis can perform: * Linear/Nonlinear Static Analysis * Pushover/Buckling Analysis * Influence-Surface Based Live Load Analysis * Eigenvalue/Ritz/Response Spectra Analysis * Staged Construction Analysis ![](https://openbrim.atlassian.net/wiki/download/attachments/2192048941/image-20230707-004637.png?api=v2) # Parameters \[FEA] A Parameter is a named global value that other objects' parameters can reference by name. Changing it updates everything derived from it, which is what makes a model **parametric** rather than a fixed set of coordinates. This is the mechanism that replaces manual coordinate editing: define `SpanLength` once, express the support positions as `SpanLength` and `2*SpanLength`, and changing the span moves the supports, the girders and everything positioned from them together. Parameters are **definitions**. They add no stiffness, mass or load — but because other parameters resolve through them, a change here propagates into geometry, properties and loads throughout the model. ## Parameter **Parameter Name:** The name used to reference this parameter from other cells and equations. *Engineering influence.* The name is the **reference**, so it is effectively an identifier in a small programming language. Any cell in any spreadsheet can use it in an expression, and OpenBrIM propagates renames to references automatically — but a name that collides with something else in scope, or that is too generic to be unambiguous (`L`, `W`, `Length`), makes expressions hard to read and easy to get wrong months later. Give parameters names that say what they are (`SpanLength`, `GirderSpacing`, `DeckThickness`). The readability of every expression that uses them depends on it. **Parameter Value:** The value the name resolves to. *Engineering influence.* Everything referencing the parameter recomputes when this changes, which is the point — and also the risk. A single edit can move a large part of the model, so the consequences extend well beyond the cell being edited. Before changing a parameter, it is worth knowing what depends on it. Values participate in expressions, so a parameter can be defined in terms of others (`DeckWidth = GirderSpacing * (NumGirders - 1) + 2*Overhang`). Chains like this are powerful and should stay shallow enough to follow; deep chains make it hard to predict what a change will do, and circular references cannot resolve at all. The value carries a **unit**, taken from where it is used. A parameter used as a length in one place and a dimensionless factor in another is a source of confusion that no error message will flag. **Unit Label (readonly):** Displays the unit associated with the parameter. *Engineering influence.* Output, and the quickest way to confirm a parameter is being interpreted as the quantity you intend. A parameter you think of as a length that reports no unit is not being used the way you expect, and its value may be entering expressions in the wrong scale. ## Verification * Change a parameter and confirm everything that should move does, in the 3D view. Anything that stays put is not actually referencing it. * Check the **Unit Label** matches the quantity you intend. * After a parametric change, re-run the analysis and confirm the model is still valid — parametric updates can produce degenerate geometry (zero-length members, inverted elements) at extreme values. * Confirm no circular references exist by checking the model compiles. * Search the model for the parameter name to establish what depends on it before changing it. * Sanity-check derived parameters by evaluating their expressions by hand for one set of inputs. ## Common mistakes * **Generic names** (`L`, `X`, `Value`) that make expressions unreadable and encourage the wrong reference being used. * **Changing a parameter without knowing what depends on it**, moving parts of the model unnoticed. * **Deep or circular dependency chains**, which are hard to predict and, when circular, cannot resolve. * **Reusing one parameter for two physically different quantities** that happen to share a value — they will diverge eventually, and the model will be wrong in one of the two places. * **Assuming a parametric change is safe** without re-running the analysis; extreme values can produce degenerate geometry. * **Hard-coding a value in one place** that should have referenced the parameter, so it silently fails to update with everything else. # Coordinate Systems \[FEA] Coordinate Systems holds the reference frames the model is built and reported against. **Alignments** define the roadway geometry - horizontal path, vertical profile and cross-slopes - so objects can be positioned by station and offset rather than by absolute coordinates, and so the model follows the roadway when it changes. **Coor. Sys.** defines a local frame with its own origin and rotation. Its main structural purpose is skewed and inclined boundary conditions: a bearing on a skewed abutment is fixed along the bearing line and free across it, which cannot be expressed in global axes at all. Assigning a coordinate system to a node reinterprets its coordinates **and** its restraint directions, and reports its displacements and reactions in that frame - so a result that appears to disagree with a global hand-check is often correct and simply expressed locally. # Alignments \[FEA] An Alignment is the roadway geometry the bridge is built to: a horizontal path, a vertical profile, and a cross-slope definition. Objects assigned to it are positioned by **station and offset** rather than by absolute coordinates, so the whole model follows the alignment and updates when it changes. Alignments can be imported (see the LandXML import page) or built from OpenBrIM objects. An Alignment is a **geometry reference**. It adds no stiffness, mass or load — but because it positions elements, it determines every length, orientation and lever arm in the parts of the model driven by it. {% hint style="info" %} The horizontal path, vertical profile and cross-slopes are held in the alignment's child objects; the fields on this sheet set the alignment's **starting reference**, its display, and report what the geometry resolved to. {% endhint %} ## Alignment **Start Station:** The station value at the alignment's start point. *Engineering influence.* This sets the origin of the stationing, so every station in the model — pier locations, tendon start and end stations, live-load surface extents — is measured from it. Changing it **shifts the entire station reference**, which moves every station-positioned object at once. Matching it to the design drawings is what allows model stations to be checked directly against the drawings; a mismatch means every station in the model is offset by a constant, which is easy to overlook precisely because the structure still looks right. **Start Azimuth:** The bearing of the alignment at its start point. *Engineering influence.* Sets the direction the alignment initially runs, and therefore the orientation of everything positioned along it — including the skew of piers and abutments relative to the global axes. The default is π/2 (due east in the usual convention). An incorrect azimuth rotates the whole structure in plan, which is obvious in a site view and invisible in a local one. **Latitude / Longitude:** The geographic position of the alignment origin, used to place the model on a map and to relate it to survey and GIS data. They do not affect the analysis. ## Offset **Transverse Offset / Elevation Offset:** Offsets applied to the alignment as a whole. *Engineering influence.* These shift the reference laterally and vertically, which is how a girder line or a parallel structure is defined from a single roadway centreline rather than by duplicating the alignment. Because every object referencing the alignment moves with the offset, a change here relocates a whole family of elements together. {% hint style="warning" %} Neither of these parameters is declared in the object type. They remain writable from the agent API and `set_parameter` — those resolve any field the object exposes in its sheet — but they carry no unit category and cannot be authored from a library template. {% endhint %} ## Display **Major Station Interval:** The spacing of major station labels in the 3D annotation. **Minor Ticks per Major:** How many minor ticks appear between major stations. **Annotation Tick Size:** The drawn size of the annotation ticks and text. **Show Geometry Points / Show Curve Data / Show Bearings / Show Cross Slopes / Show Elevations:** Toggles for the annotation layers. **Cross Slope Vertical Exaggeration:** Vertical exaggeration applied when displaying cross-slopes. *Engineering influence, all of these.* They are **visualization only** and change nothing in the analysis. They matter for review rather than for results: cross-slopes and vertical curves are small relative to a bridge's length and are effectively invisible at true scale, so the exaggeration is what makes a profile error visible at all. Turning the annotation layers on is the practical way to check an imported alignment against the drawings. ## Alignment Info **Horz. Station Range / Horz. Segment Count:** The extent and number of segments of the horizontal geometry. **Vert. Station Range / Vert. Min Elevation / Vert. Max Elevation / Vert. Point Count:** The extent, elevation range and number of points of the vertical profile. **Cross Station Range / Cross Max Left Offset / Cross Max Right Offset / Cross Section Count:** The extent and limits of the cross-slope definition. *Engineering influence, all ten.* These are **read-only output** summarising what the alignment actually resolved to, and together they are the most efficient way to validate an import. The characteristic failure of an imported alignment is that one of the three components is missing or truncated — a horizontal path imported without its vertical profile, or a cross-slope definition covering only part of the station range. That shows up immediately as a station range that does not match between the three, or a count of zero. An elevation range that is implausible, or a station range that does not match the drawings, points to a unit mismatch in the import. {% hint style="warning" %} All ten of these columns are derived and cannot be edited, but they are not flagged read-only, so typing into them appears to work and the value is discarded on redraw. {% endhint %} ## Verification * Compare **Horz., Vert. and Cross station ranges** against each other and against the drawings. They should cover the same extent; a mismatch means a component is missing or truncated. * Check the elevation range is plausible for the site — an implausible one usually indicates a unit error on import. * Confirm the segment and point counts are non-zero for all three components. * Turn on the annotation layers and compare stations, bearings, curve data and elevations against the alignment drawing. * Use cross-slope exaggeration to check superelevation transitions, which are invisible at true scale. * Confirm a known station in the model lands where the drawing says it should — this validates the start station and azimuth together. * After changing the start station or an offset, re-check the positions of station-driven objects. ## Common mistakes * **A start station that does not match the drawings**, offsetting every station in the model by a constant while the structure still looks correct. * **Importing horizontal geometry without the vertical profile**, leaving the model flat — visible in the Alignment Info station ranges and almost nowhere else. * **Unit mismatch on import**, giving an implausible elevation or station range. * **Wrong start azimuth**, rotating the structure in plan. * **Changing a transverse or elevation offset** without realising it moves every object referencing the alignment. * **Reviewing cross-slopes at true scale**, where superelevation errors are invisible. * **Assuming the display settings affect the analysis.** They do not. # Coor. Sys. \[FEA] A Coordinate System defines a local reference frame — an origin and an orientation — that can be assigned to nodes and loads. Positions, restraint directions, applied load components and reported results are then expressed in that frame instead of the global one. Its main structural purpose is **skewed and inclined boundary conditions**. A bearing on a skewed abutment is fixed along the bearing line and free across it; expressing that in global axes is impossible, because "global X" is neither of those directions. Assigning a rotated coordinate system makes the restraint directions match the physical ones. A Coordinate System is a **reference definition**. It adds no stiffness, mass or load — but by reorienting restraints and loads it changes the analysis substantially. {% hint style="warning" %} Assigning a coordinate system to a node reinterprets **both** its coordinates and its restraint directions, and reports its displacements and reactions in that frame. A reaction that appears not to match a global hand-check is often correct but expressed in the local frame. {% endhint %} ## Properties **Origin X / Y / Z:** The position of the local frame's origin in global coordinates. *Engineering influence.* Coordinates of anything assigned to this system are measured **from this point**. Moving the origin moves everything referenced to it, so an origin that is wrong shifts a whole family of nodes together — which is easy to miss because the structure keeps its shape while sitting in the wrong place. The origin does **not** affect restraint directions; only the rotation does. For a skewed support where you only need the directions rotated, the origin can stay at the global origin. ## Euler **Rotation Z / Rotation Y / Rotation X (ZYX order):** The orientation expressed as three sequential Euler rotations, applied in **Z, then Y, then X** order. *Engineering influence.* This is the usual way to define orientation, and for the common case it is simple: a skewed abutment needs only **Rotation Z**, by the skew angle, so that the local X axis runs along the bearing line. The **order matters**. Euler rotations do not commute — applying 30° about Z then 20° about Y gives a different frame from 20° about Y then 30° about Z. When more than one angle is non-zero, the resulting orientation is rarely what you would guess from the individual numbers, and it should be confirmed by displaying the axes rather than reasoned about. The **sign convention** follows the right-hand rule about each axis. A skew entered with the wrong sign rotates the support the wrong way, which on a skewed bridge produces restraint across the bearing line where it should be along it — a plausible-looking model with the wrong load path. Getting the rotation wrong does not produce an error. It produces reactions in directions the real bearing cannot deliver, and a structure that is restrained against thermal movement it should accommodate. ## Quaternion **Quaternion x / y / z / w:** The orientation expressed as a quaternion. *Engineering influence.* An alternative, order-independent representation of the same rotation, used mainly when the orientation comes from another system — a CAD package or an alignment computation — rather than being typed by hand. Quaternions avoid the gimbal-lock degeneracy that Euler angles suffer when the middle rotation approaches 90°, which is why they are preferred for programmatic definition. A quaternion must be **normalized** (`x² + y² + z² + w² = 1`) to represent a pure rotation. An unnormalized quaternion — including the all-zero default — does not define a valid orientation, and a system left with all four at zero has no meaningful rotation. Use either the Euler fields or the quaternion fields, not both. ## Verification * **Display the local axes** at a node assigned to the system and confirm they point along and across the bearing line. This is the only reliable check; the numbers alone are not interpretable, especially with multiple rotations. * Apply a unit load along a local axis and confirm the structure moves in the expected physical direction. * Check reactions at a skewed support: the restrained direction should carry reaction and the free direction should carry essentially none. * Confirm a bridge with skewed supports is free to expand along its length under a temperature rise — if it is not, the restraint directions are probably wrong. * Compare a node's global position against its local coordinates and the origin by hand. * If using quaternions, confirm the four components are normalized. ## Common mistakes * **Sign error on the skew angle**, restraining across the bearing line instead of along it. * **Assuming Euler rotations commute** when more than one is non-zero. * **Leaving the quaternion at all zeros** while expecting a rotation, or filling in both Euler and quaternion fields. * **Forgetting that results are reported in the local frame**, and treating a correct reaction as an error because it does not match a global hand-check. * **A wrong origin**, shifting a whole set of nodes while preserving their shape. * **Restraining a skewed support in global axes anyway**, which is what the coordinate system exists to avoid, and which over-restrains the structure against thermal movement. # Properties \[FEA] The Properties branch holds the material and section definitions that turn geometry into stiffness. **Materials** supply modulus, Poisson's ratio, density and thermal expansion - the properties that drive the analysis - plus the strength values and time-dependent behaviour used by design and staged construction. **Sections** supply the cross-sectional properties: area, moments of inertia, torsion constant and shear areas. **Rebars** and **Strands** are property library entries describing bar and strand sizes. They are used by design and section analysis; they do not create elements of their own. These objects are referenced by name from elements, so one definition serves many members - and a change to a material or section propagates to every element that uses it. # Materials \[FEA] A Material supplies the constitutive properties every element needs to turn geometry into stiffness: elastic modulus, Poisson's ratio, density and thermal expansion, plus the strength values used by design checks and the time-dependent behaviour used by staged construction. Materials can be imported from OpenBrIM's database or defined by hand. For importing, see [this example](https://docs.openbrim.org/examples/steel-bridge-examples/example-steel-i-girder-bridge-ex1-sig/properties-ex1-sig/materials-ex1-sig). A Material contributes to the **stiffness matrix** (through modulus and Poisson's ratio), to **mass** (through unit weight), and **generates load** (self-weight, and thermal load in combination with the thermal coefficient). Its strength values are used for **design only** and do not affect analysis. ## Basic **Modulus of Elasticity:** Young's modulus. *Engineering influence.* This scales essentially every stiffness in the model: axial as `EA`, flexural as `EI`, shell membrane and bending both linearly in `E`. Under load control, displacements are inversely proportional to it — halving `E` doubles deflections. In a **statically determinate** structure it does not change internal forces at all, only displacements; in a **redundant** structure it changes the distribution, because stiffness attracts load. That distinction is why an incorrect modulus can be invisible in a simple span and decisive in a continuous one. Periods scale with `1/√E`, so modulus errors propagate into every dynamic result. For concrete the value is strength-dependent and time-dependent; see the Time Dependent tab. Direct impact on analysis; indirect impact on design through the analysis results. **Poisson's Ratio:** The ratio of transverse to axial strain. *Engineering influence.* It couples the two in-plane directions of a shell and the three directions of a solid, so it matters most for plate and solid models and hardly at all for a beam-only frame. It also ties the three elastic constants together — see Shear Modulus below. Typical values are about 0.2 for concrete and 0.3 for steel. Values approaching 0.5 describe an incompressible material and cause volumetric locking in solid elements, making them artificially stiff. **Shear Modulus:** The shear modulus `G`. *Engineering influence.* Governs shear deformation and torsional stiffness. For an isotropic material the three constants satisfy `G = E / (2(1+ν))`, and **entering 0 for any one of the three lets the program compute it from the other two** — which is the recommended way to keep them consistent. Entering all three independently allows a physically impossible combination that will not be flagged. Shear deformation is negligible for slender members and significant for deep beams, thick plates and short columns; torsional stiffness matters wherever a curved or skewed structure carries load in torsion. **Unit Weight \[10⁻³]:** Weight per unit volume. **The value is entered in units of 10⁻³**, so a density of 0.15×10⁻³ is entered as **0.15**. *Engineering influence.* This is the source of self-weight load and of the mass matrix in a dynamic analysis. Increasing it increases both the applied gravity load and the inertia, which lengthens periods; the two effects do not cancel, because self-weight is a load while mass is a property. A value of zero makes the element weightless — no self-weight and no contribution to mass, which silently removes the dominant load case from most bridge models. For reinforced concrete the value normally already includes the reinforcement, which is why rebar and strand weights are reporting-only quantities elsewhere. Direct impact on analysis; indirect on design. **Thermal Coeff. \[10⁻⁶]:** Coefficient of thermal expansion. **Entered in units of 10⁻⁶**, so 6.5×10⁻⁶ is entered as **6.5**. *Engineering influence.* Converts a temperature change into strain. It only has an effect when a temperature load is present, and only produces **force** when the resulting movement is restrained — an unrestrained member simply changes length. In a restrained or redundant structure it can generate very large forces, which is why thermal effects often govern bearing and joint design. Zero means the model ignores temperature entirely, which is optional only if there are no thermal load cases. Note that steel and concrete coefficients are similar, which is what makes composite construction practical; a large mismatch entered by mistake produces spurious interface forces. **Type:** Steel, Concrete, Reinforcement Bar or Prestressing Tendon. *Engineering influence.* Selects the default stress–strain model and the code rules applied in design and section analysis. It has **no effect on finite element analysis** — a linear analysis uses `E`, `ν` and density regardless — but a direct effect on design, capacity and any nonlinear fibre-based section work. Choosing the wrong type gives a member the wrong constitutive curve at ultimate. **Stress Strain Model (readonly):** Reports the stress–strain curve implied by the Type — bilinear for steel, Menegotto–Pinto for rebar, Mander for concrete, and a prestressing curve for tendons. Read-only output; use it to confirm the Type selection produced the curve you expected. ## Orthotropic **Orthotropic Ex / Ey:** Direction-dependent moduli in the material's local x and y directions. **Orthotropic Nuxy:** In-plane Poisson's ratio for the orthotropic definition. **Orthotropic Gxy / G13 / G23:** In-plane and transverse shear moduli. *Engineering influence.* These describe a material that is stiffer in one direction than another — an orthotropic steel deck, a one-way ribbed slab smeared into a plate, timber, or a concrete deck idealized with reduced transverse stiffness. They apply to shell elements and are interpreted in the element's **local** axes, so their meaning depends on shell orientation; a mesh with inconsistent local axes will have its stiff direction pointing different ways on different elements. Increasing `Ex` relative to `Ey` attracts load into the x direction, which is exactly the intent for a deck that spans one way. Leaving these blank uses the isotropic properties from the Basic tab. The transverse shear moduli `G13` and `G23` only matter where transverse shear deformation is significant — thick plates and Mindlin (Thick) shell formulations. {% hint style="warning" %} None of the six Orthotropic parameters are declared in the object type, so they can only be set by hand in this sheet — not through the agent API, `set_parameter`, or ParamML authoring. {% endhint %} ## Steel **Steel Yield Stress:** The yield strength `Fy`. **Steel Ultimate Stress:** The ultimate strength `Fu`. *Engineering influence, both.* These are **design** quantities. They set the capacity a steel member is checked against and the plateau of its stress–strain curve, so they determine utilisation ratios, plastic hinge capacities in a pushover analysis, and the yield point in any nonlinear material model. They have **no effect on a linear elastic analysis** — a steel member with the wrong `Fy` deflects exactly the same and simply reports a wrong utilisation. Increasing them increases capacity and reduces reported demand-to-capacity ratios, without changing the demand itself. ## Concrete **Concrete Strength at 28 Days:** The characteristic compressive strength `f'c` at 28 days. *Engineering influence.* A **design** quantity for capacity, and also the anchor for the time-dependent calculations: the CEB-FIP creep, shrinkage and modulus-development relationships are all expressed relative to the 28-day strength, so it governs long-term behaviour in a staged model. It does not change a linear elastic analysis directly — the analysis uses the modulus from the Basic tab — but if time-dependent modulus is enabled, the computed modulus is derived from this value and the Basic modulus is overridden. ## Time Dependent These five switches enable the long-term effects used by staged-construction analysis. All are **Include/Ignore** switches. {% hint style="info" %} Each of these must be enabled in **two** places to take effect: here on the material, **and** on the construction stage. Enabling it on only one is the usual reason a staged model shows no creep or shrinkage at all. Environmental inputs such as relative humidity are properties of the **stage**, not of the material. {% endhint %} **Time Dependent Elastic Modulus:** When included, the modulus is computed as a function of concrete age rather than taken from the Basic tab, following CEB-FIP 1990. The computation uses the 28-day strength, cement hardening type, curing humidity and temperature, and the age at loading. *Engineering influence.* Young concrete is substantially less stiff than mature concrete, so including this softens early stages and changes how load locks in as the structure is built — generally increasing the long-term deflection and shifting force toward members cast later. OpenBrIM works in secant modulus while CEB-FIP computes a tangent modulus, so the CEB-FIP value is divided by 1.05 before use. Overrides the Basic modulus when enabled. **Concrete Creep Effect:** Long-term deformation under sustained load. *Engineering influence.* Creep increases deflections over time and, in a redundant or staged structure, **redistributes** force toward members that creep less — which is why a segmentally-built bridge ends up with a different moment diagram than the same geometry built on falsework. It depends on the age at loading, the sustained stress level, member size, humidity and cement type. Ignoring it understates long-term deflection and misstates the final force distribution. **Concrete Shrinkage Effect:** Volume reduction as the concrete dries. *Engineering influence.* Shrinkage is a strain that occurs whether or not load is applied, so in a **restrained** member it produces tension and can cause cracking; in a composite member it produces differential strain between deck and girder. Its magnitude depends on humidity, member size, mix and age at the start of drying. Ignoring it understates cracking and deck tension. **Steel Relaxation Effect:** Loss of stress in prestressing steel held at constant strain. *Engineering influence.* Reduces the effective prestress over time, and therefore the balancing load and the compression in the concrete. Ignoring it overstates the prestress remaining at long term, which is unconservative for a serviceability tension check. **PT Losses from Structure:** Elastic shortening losses — the prestress lost because the member itself shortens as it is compressed, and as subsequent tendons are stressed. *Engineering influence.* Reduces the prestress delivered by tendons stressed earlier in a sequence. The effect grows with the number of tendons and with how much the member shortens, so it is most significant in heavily prestressed members with many stressing operations. ## Dynamics **Rayleigh Damping Mass:** The mass-proportional damping coefficient `α` in `C = αM + βK`. **Rayleigh Damping Stiffness:** The stiffness-proportional coefficient `β`. *Engineering influence.* Rayleigh damping produces a damping ratio that **varies with frequency**: the `α` term damps low frequencies and the `β` term damps high ones, matching the target ratio at exactly two frequencies and over-damping outside that band. Choose the two frequencies to bracket the modes that carry the response, then compute `α` and `β` from them; entering round numbers without that calculation is the usual cause of an analysis that is inexplicably over- or under-damped. Both default to 0, giving **undamped** behaviour. Increasing damping reduces peak dynamic response, sharply near resonance and mildly away from it. These coefficients are used by direct-integration time-history analysis; modal and FNA cases use the modal damping ratio on the case instead, and ignore these values. ## Verification * Check a simple span's deflection against `5wL⁴/384EI` to confirm modulus and density are being applied. * Confirm total model weight matches a hand take-off; a zero or wrong unit weight shows up immediately. * Verify the 10⁻³ and 10⁻⁶ scaling on unit weight and thermal coefficient by checking a computed self-weight reaction and a computed thermal expansion against hand values. These two fields are the most common unit-slip on this object. * Enter 0 for shear modulus and confirm the program computes it from `E` and `ν`. * For a time-dependent model, run with the effects on and off and compare long-term deflection; no difference means the switches are not enabled on the stage as well. * Check that the Stress Strain Model shown matches the Type you selected. * For an orthotropic deck, apply a unit load and confirm it spans in the intended direction. ## Common mistakes * **Missing the 10⁻³ / 10⁻⁶ scaling** on unit weight or thermal coefficient, producing self-weight or thermal forces wrong by a factor of a thousand. * **Zero unit weight**, silently removing self-weight and mass. * **Entering all three of `E`, `ν` and `G`** with an inconsistent combination instead of leaving one at zero to be computed. * **Enabling time-dependent effects on the material only** and not on the construction stage, so nothing happens. * **Assuming `Fy` affects analysis.** It does not; a wrong yield strength changes only the reported utilisation. * **Wrong material Type**, giving a member the wrong stress–strain curve in section analysis and pushover. * **Leaving Rayleigh coefficients at zero** and running an undamped direct-integration time history. * **Using orthotropic properties on a mesh with inconsistent local axes**, so the stiff direction varies element by element. # Rebars \[FEA] A Rebar defines a reinforcing bar size — its diameter, cross-sectional area and weight per unit length. It is a **property library** entry: it describes a bar, it does not place one. Bars are placed by section definitions and reinforcement layouts that reference this entry by name. Rebars can be imported from the built-in database (which carries standard bar designations) or defined by hand for a size the database does not cover. Rebar entries are used for **design and section analysis** — capacity checks, cracked-section properties, and reinforcement reporting. They do not create finite elements and, on their own, add nothing to the global stiffness or mass matrices. ## Properties **Diameter:** The nominal bar diameter. *Engineering influence.* Diameter drives cover and spacing checks, development and lap lengths, and the bend radii used in detailing. It also determines whether a given bar arrangement physically fits within the section — a layout that clears on paper with an understated diameter may be unbuildable. It does not by itself set the bar's contribution to capacity; that comes from the area below. Diameter and area should be **consistent** with one another. Because both are entered independently, nothing forces `A ≈ πD²/4`, and an inconsistent pair produces a section whose reported steel area does not match the bar sizes shown in the detailing. **Area:** The cross-sectional area of one bar. *Engineering influence.* This is the value that actually reaches the analysis. Flexural and axial capacity scale essentially linearly with total steel area, so an error here propagates directly into every capacity check that uses the bar. It also feeds cracked-section and section-analysis calculations, where the steel area governs the neutral-axis position and the stiffness after cracking. For standard designations, use the published nominal area rather than the geometric area computed from the nominal diameter — for deformed bars the two differ slightly and codes are written against the nominal area. Increasing the area increases capacity and, in a section analysis, moves the neutral axis toward the steel. A value of zero means the bar contributes nothing, which will show up as an unreinforced section rather than as an error. **Weight:** Weight per unit length of the bar. *Engineering influence.* This is used for **quantity reporting** — reinforcement schedules and material take-offs — not for structural behaviour. The self-weight of reinforcement is normally already inside the reinforced-concrete unit weight assigned to the concrete material, so this value does not add mass or load to the analysis. Setting it wrong affects quantities and cost, not forces. ## Verification * Cross-check diameter against area: for a standard bar, `A` should be close to `πD²/4`. A large discrepancy means one of the two was entered in the wrong unit or from the wrong row. * Compare the entry against the published table for the designation you intend to use. * Open a section that references the bar and confirm the reported total steel area equals bar area × bar count. * Check that the reinforcement is drawn at the expected size in the section view — a diameter error is usually visible immediately. * Confirm a capacity check moves in proportion when the bar count is changed, which validates that the area is being picked up. ## Common mistakes * **Inconsistent diameter and area**, most often from editing one and not the other after copying an existing entry. * **Entering the area of a bar group** rather than of a single bar, multiplying the reinforcement by the bar count. * **Mixing unit systems** — a metric bar diameter with an imperial area — which produces capacities wrong by a large factor while still looking like a plausible number. * **Defining a duplicate entry** for a bar that already exists in the database, then editing only one of the two and wondering why some sections changed and others did not. * **Expecting the Weight value to add load to the model.** It is for reporting only. # Strands \[FEA] A Strand defines a prestressing strand size — its diameter, cross-sectional area and weight per unit length. Like Rebars, it is a **property library** entry: it describes a strand, it does not place one. Strands are referenced by Tendon definitions and by section reinforcement layouts. Strand entries feed **prestress force calculations and section analysis**. They do not create finite elements and add nothing directly to the global stiffness or mass matrices. ## Properties **Diameter:** The nominal strand diameter. *Engineering influence.* Diameter governs whether the strand pattern fits within the duct or the section, the minimum duct and deviator radii, and the spacing rules that apply. In a pre-tensioned member it also relates to transfer and development length, over which the prestress force builds up from zero at the member end. As with rebars, diameter and area are entered independently, so nothing enforces consistency between them. Prestressing strand is stranded wire rather than solid bar, so its area is genuinely **less** than `πD²/4` — typically around 70–75% of it. That is expected and correct; do not "fix" the area to match the geometric circle. **Area:** The cross-sectional area of one strand. *Engineering influence.* This is the value that governs prestress. Together with the number of strands it gives the tendon's steel area, which converts jacking force into strand stress — and code limits on jacking are expressed as a fraction of ultimate **stress**, so an understated area makes the model report a stress that exceeds the limit for a force that is actually acceptable, or hides an over-stressed tendon behind an overstated area. It also sets the axial stiffness the tendon contributes in a bonded section analysis, which affects the neutral-axis position and the cracked-section properties, and it drives the ultimate-strength contribution of the prestressing steel. Increasing the area increases the force available at a given stress and increases the tendon's contribution to flexural capacity. A value of zero means the strand contributes nothing. Use the published nominal area for the designation rather than a computed value. **Weight:** Weight per unit length of the strand. *Engineering influence.* Used for **quantity reporting** — take-offs and schedules — not for structural behaviour. Prestressing steel weight is normally already inside the concrete's unit weight, so this value does not add mass or load to the analysis. ## Verification * Compare diameter and area against the published table for the designation. Expect area to be roughly 70–75% of `πD²/4` for stranded product. * Open a Tendon that references the strand and confirm the reported steel area equals strand area × strand count. * Check the stress at jacking: `force / (count × area)` should land within the code limit as a fraction of ultimate strength. A value far outside that range usually means the area or the count is wrong. * Confirm the tendon force reported in **Prestressing Details…** is consistent with the stress you expect. * Check that a change in strand count moves computed capacity proportionally. ## Common mistakes * **"Correcting" the area to `πD²/4`.** Strand is stranded, not solid, and its true area is substantially lower. This inflates the steel area by around a third. * **Entering the area of the whole tendon** rather than of one strand, then also setting the strand count — multiplying the prestressing steel by the count. * **Confusing strand and rebar entries**, which have identical fields but very different material behaviour and code treatment. * **Mixing unit systems** between diameter and area. * **Expecting the Weight value to add load** to the model. It is for reporting only. # Sections \[FEA] A Section supplies the cross-sectional properties an FE Line needs to become a stiff member: area, moments of inertia, torsion constant and shear areas, together with the material and the geometric information used by design checks. Sections can be imported from the database, drawn as a shape and have their properties computed automatically, or entered numerically. A Section contributes to the **stiffness matrix** and, through its area and the material density, to **mass** and **self-weight**. {% hint style="info" %} **Compute Properties From Shape** decides whether the numbers below are inputs or outputs. When it is on, the properties are derived from the drawn geometry and anything you type is recalculated away; when it is off, the values you enter are used directly. Decide which mode you are in before editing anything on this page. {% endhint %} ## Properties **Material:** The material assigned to the section. Supplies modulus (turning `I` into `EI`), Poisson's ratio, density for self-weight, and the strength values used by design. *Engineering influence.* A section with no material has no stiffness and no weight — a common cause of a model that is far too flexible or that reports zero dead load. It also governs which design code rules apply to members using the section. **Area:** The axial cross-sectional area `Ax`. *Engineering influence.* Sets axial stiffness `EA` and, with the material density, the member's self-weight. It governs axial shortening in columns and cable stretch, and it is the dominant property for truss and cable members, which have no bending stiffness to fall back on. Errors show up as wrong dead load before they show up as wrong deflection. **Shear Area Y / Shear Area Z:** The effective areas resisting shear in each local direction. *Engineering influence.* These control shear deformation, which is negligible for slender members and significant for deep beams and short columns — the classic case being a squat pier where ignoring shear deformation overstates stiffness and attracts too much load to it. They are always **less** than the gross area (roughly the web area for an I-section, about 5/6 of the area for a rectangle). Entering **zero** is the switch that means "ignore shear deformation" — it does not mean zero stiffness. That is a reasonable simplification for slender members and a real error for stubby ones. **Torsion Constant:** The St. Venant torsion constant `J`. *Engineering influence.* Governs torsional stiffness `GJ`. Its magnitude depends enormously on whether the section is open or closed: a closed box has a torsion constant orders of magnitude larger than an open I-section of similar size. Because stiffness attracts load in a redundant structure, an overstated `J` pulls load into the torsional path and away from bending — which is why curved and skewed bridges are sensitive to it. For concrete members the uncracked `J` substantially overstates the torsional stiffness actually available once the member cracks; codes commonly require a large reduction, applied through the torsion-constant factor on the FE Line rather than by editing the section. **Inertia Y / Inertia Z:** The second moments of area about the local y and z axes. *Engineering influence.* These are the flexural stiffnesses, `EIy` and `EIz`. Deflection is inversely proportional to them, and in a redundant structure they set how moment distributes between members. The two are almost always very different for a bridge girder — which is why **Beta Angle** on the FE Line matters so much: assigning the section correctly but orienting it wrongly puts the weak axis where the strong one was intended, producing deflections an order of magnitude too large. **Inertia ZY:** The product of inertia `Izy`. *Engineering influence.* Non-zero for a section whose principal axes are not aligned with its local axes — an unequal angle, a singly-symmetric section rotated relative to the frame. It couples bending about the two axes, so a load applied in one plane produces deflection in the other. For doubly symmetric sections it is zero, and leaving it zero for an unsymmetric section misses biaxial coupling the real member has. **Compute Properties From Shape?:** Whether the properties above are computed from the drawn geometry. *Engineering influence.* This is a **mode switch**, not a physical quantity. With it on, the section is driven by its shape and stays consistent as the shape changes — the right choice for parametric work. With it off, the typed values govern, which is what you need to match a reference model, a handbook section, or a built-up member whose geometry is not drawn. Switching it on after entering values by hand discards them silently. **Has Geometry? (readonly):** Reports whether a shape has been defined. A section with no geometry cannot compute properties and cannot be used for section-level design checks or fibre analysis. **Assigned to FELine? (readonly):** Reports whether any element uses the section. Useful for finding orphaned library entries, and for confirming a newly created section is actually in use. **Is Composite? (readonly):** Reports whether the section combines more than one material. {% hint style="warning" %} These three read-only columns are derived and cannot be edited, but they are not flagged read-only, so typing into them appears to work and the value is discarded on redraw. {% endhint %} ## More Properties **Gross Area:** The gross cross-sectional area, before deductions for holes or transformation. *Engineering influence.* Used by design checks that are written against gross rather than effective properties. It does not replace **Area** in the stiffness calculation. **Radius of Gyration Y / Z (readonly):** `√(I/A)` about each axis. *Engineering influence.* Derived values reported for design use. They drive slenderness ratios (`KL/r`) and therefore buckling and compression capacity checks. A small radius of gyration about one axis identifies the direction a compression member will buckle in. **Centroid Location Y / Z:** The position of the section centroid in local coordinates. *Engineering influence.* The centroid is the reference the element's axis passes through, so it defines the eccentricity of everything measured from it — prestressing tendons, composite deck offsets, and the lever arm of any end offset. An incorrect centroid shifts every eccentricity in the member, which changes prestress moment directly. **Shear Center Y / Z:** The position of the shear centre. *Engineering influence.* Load applied away from the shear centre produces torsion. For a doubly symmetric section the shear centre coincides with the centroid and this does not arise; for a channel or an unsymmetric girder they differ, and the offset is what makes such members twist under load applied at the centroid. It also matters for lateral-torsional buckling checks. **Perimeter:** The section perimeter. Used for surface-area-dependent quantities — painting take-offs, and the notional-size terms in creep and shrinkage calculations, where the volume-to-surface ratio governs the drying rate. **Warping Constant:** The warping torsion constant `Cw`. *Engineering influence.* Open sections resist torsion partly by warping, which St. Venant torsion alone does not capture. `Cw` is significant for open sections such as I-girders — especially in lateral-torsional buckling — and effectively negligible for closed boxes. It is used by design checks rather than by the basic beam element stiffness. **Non-prismatic Variation Direction:** For a member whose section varies along its length, the direction in which the variation is measured. Only meaningful for non-prismatic definitions; leave at the default for a constant section. ## Extent **Pos. of Neg. Edge Y / Pos. of Pos. Edge Y** and **Pos. of Neg. Edge Z / Pos. of Pos. Edge Z:** The extreme fibre positions of the section in each local direction. *Engineering influence.* These give the distances from the centroid to the extreme fibres, which convert a moment into an extreme-fibre stress (`σ = M·c/I`). They therefore drive every stress check and every serviceability tension or compression limit. They are also what the model uses to know the physical envelope of the section, for clash and cover purposes. An asymmetric section has different distances to the two edges, and using the wrong one understates stress at the critical fibre — most consequentially at the tension face of a prestressed member. ## Verification * Check a simple span deflection against `5wL⁴/384EI` to confirm the inertia and material are being applied. * Compare the reported self-weight of a member against area × length × unit weight. * For an imported or drawn section, compare the computed properties against the published values for that designation. * Display the section in the section viewer and confirm the shape, centroid and extreme fibres look right. * Check **Assigned to FELine?** to confirm the section you edited is the one actually in use. * Confirm the strong axis is oriented as intended by checking member deflections under a known load, and by displaying local axes on the FE Lines that use the section. * Compare a torsion-sensitive result computed with open-section and closed-section `J` values to see how much the answer depends on it. ## Common mistakes * **Editing numeric properties with Compute From Shape still on**, so the values are silently recalculated away. * **Wrong axis orientation.** The section is right, but Beta Angle on the FE Line puts the weak axis vertical. Deflections come out an order of magnitude too large. * **Entering the gross area as the shear area**, removing shear deformation from members where it matters — or entering a shear area for slender members where zero was intended. * **Using an uncracked concrete torsion constant** without the code-required reduction, attracting load into a torsional path the real structure cannot deliver. * **No material assigned**, giving a section with no stiffness and no weight. * **Leaving `Izy` at zero for an unsymmetric section**, missing biaxial bending coupling. * **Mixing unit systems** between area and inertia, which is easy to miss because both are large numbers. * **Assuming the shear centre coincides with the centroid** on a channel or unsymmetric girder. # Geometry \[FEA] The Geometry branch holds the objects that make up the analytical model: the joints, the elements that connect them, and the constraints and groups that organise them. **Nodes** carry the degrees of freedom and the support conditions. **Lines** are the one-dimensional elements - girders, columns, braces, cables. **Surfaces** are shell elements for decks, slabs and webs. **Volumes** are solid elements for regions where a full three-dimensional stress state matters. **Springs** connect two joints with a defined stiffness, which is how bearings and isolators are modelled. **Equal Constraints** and **Rigid Diaphragms** tie degrees of freedom together without adding stiffness - the first as a strict same-DOF tie, the second as an in-plane rigid body with lever arms. **Tendons** define prestressing geometry, and **FE Groups** collect objects into named sets used for staging, constraints, loads and result extraction. One convention runs through this branch and is worth learning once: for supports and end releases, **0 is free/released, a negative value is fixed/rigid, and a positive value is a spring stiffness.** # Nodes \[FEA] A node is a point in the model where degrees of freedom exist. Elements connect to nodes, loads and masses are applied at nodes, and the solver's unknowns are nodal displacements and rotations. A node also carries its own **support conditions** — restraints and springs — so in OpenBrIM the node object is both the geometric point and the boundary condition at that point. Every node has six degrees of freedom: three translations (Tx, Ty, Tz) and three rotations (Rx, Ry, Rz), expressed in global axes unless a Coordinate System is assigned. {% hint style="danger" %} **Support convention — read this before entering any restraint:** Entering **1** does **not** fix a degree of freedom. It creates a spring with a stiffness of 1 force unit per length unit, which for any real structure is indistinguishable from free. Use **−1** for a fixed support. {% endhint %} | Value | Meaning | | --------------------- | ----------------------------------------------------- | | **0** | **Free** — no restraint, no spring (the default) | | **negative** (use −1) | **Fixed** — the degree of freedom is fully restrained | | **positive** | **Spring** — an elastic support of that stiffness | ## Geometry **X / Y / Z:** The node's location in **global** coordinates. These are **connectivity and geometry** parameters: they place the point, and thereby set every element length, orientation and lever arm that depends on it. {% hint style="warning" %} Assigning a **Coordinate System** does **not** reinterpret these values. X, Y and Z are always the global analysis coordinates — the coordinate system rotates the node's local *axes* (its restraint and load directions), not its position. Entering coordinates believing they will be transformed by an assigned system places the node somewhere other than intended, which changes element lengths and stiffness. To position a node relative to the roadway, use the **Alignment** fields instead. {% endhint %} *Engineering influence.* Moving a node changes the length and direction of every element attached to it, which changes those elements' stiffness — a beam's bending stiffness varies with `1/L³`, so apparently small coordinate errors have a disproportionate effect on flexible members. Coordinates also set the lever arms used by rigid diaphragms and by offset/rigid-end members. They do not by themselves create or remove restraint. Two nodes at the same location are not automatically the same node — see the merge settings below. **Coordinate System:** An optional local frame for this node. When assigned, the node's **restraint and load directions** are interpreted in that frame rather than in global axes, and its displacements and reactions are reported there. It does **not** change where the node sits — X/Y/Z stay global. *Engineering influence.* This is the mechanism for a skewed or radial support: a bearing that is fixed along the bearing line and free transverse to it, on an abutment that is not square to the global axes, is modelled by assigning a rotated coordinate system and restraining in the local direction. Without it, restraining "X" restrains the global direction, which on a skewed abutment restrains a combination of the along- and across-bearing directions and produces reactions the real bearing cannot deliver. Leave empty to work in global axes. Displacements and reactions at the node are reported in the assigned system — which is also why a skewed node's output appears to disagree with a global hand-check. **Alignment:** Associates the node with a roadway alignment, so its position can be driven by station and offset rather than by fixed coordinates. Use it when the geometry should follow the roadway; changes to the alignment then move the node automatically. Leave empty for a node placed by explicit coordinates. **Group:** The FE Group the node belongs to, used for construction-stage activation and for selecting sets of nodes elsewhere (diaphragm slaves, result extraction, load filters). This is a **selection** parameter with no mechanical effect of its own. A node whose group is inactive in a stage does not participate in that stage. ## DOF These six define the support condition, following the sign convention above: 0 free, negative fixed, positive an elastic spring stiffness. Right-click any DOF cell for the **6x6 Stiffness Matrix…** action, which opens the coupled-stiffness editor described below. **Tx / Ty / Tz:** Translational restraint or spring stiffness along each axis, in force per unit length. **Rx / Ry / Rz:** Rotational restraint or spring stiffness about each axis, in moment per unit angle. *Engineering influence, common to all six.* Restraining a degree of freedom removes it from the system, so the structure becomes **stiffer or equally stiff — never softer** — and a reaction appears there. A positive spring value gives partial fixity: increasing the stiffness moves the behaviour toward fully fixed, increasing the reaction and the moment attracted to that support, while decreasing it toward zero approaches free and sheds load to other supports. The transition is not linear in any useful sense — what matters is the spring stiffness *relative to* the stiffness of the structure it supports, so a value that behaves as nearly-fixed under one superstructure is nearly-free under a much stiffer one. Very large positive values are a poor substitute for a fixed restraint: they add a term orders of magnitude larger than the rest of the matrix, degrading conditioning and producing noisy reactions and spurious high-frequency modes. Use a negative value to mean fixed. Results sensitive to these: reactions, the distribution of moment between spans and supports, and — because restraint removes degrees of freedom — the natural periods and mode shapes. A model with too few restraints is singular; one with too many carries load paths that do not exist. These parameters are interpreted in the node's Coordinate System when one is assigned. ## Stiffness Matrix **6x6 Stiffness Matrix:** A full 6×6 nodal stiffness matrix, edited through its own sub-sheet, for supports whose behaviour is **coupled** between degrees of freedom. *Engineering influence.* The six DOF values above are only the diagonal of a support stiffness; they cannot express coupling — that a horizontal translation also produces a moment reaction, as a real spread footing or pile group does. The 6×6 form carries the off-diagonal terms, which is why a foundation stiffness handed over from a geotechnical analysis, or produced by an **Equivalent Stiffness** point, is normally a full matrix. Supplying it makes the support response direction-dependent in a way the diagonal form cannot reproduce, typically reducing the rotation that accompanies a lateral load. The matrix should be symmetric and positive-definite to represent a real elastic support; one that is not can make the global system indefinite and cause the solve to fail or return meaningless results. Leave it empty when the diagonal DOF values are sufficient. ## Gap **Tx Gap / Ty Gap / Tz Gap:** A translational gap, in length units, that must close before the node's spring in that direction engages. **Rx Gap / Ry Gap / Rz Gap:** A rotational gap, in angle units, before the rotational spring engages. *Engineering influence.* A gap makes the support **nonlinear and one-sided**: the node moves freely until the gap closes, then the spring stiffness applies. This is how a bearing with a physical clearance, a shear key with a construction gap, or a joint that must close before bearing is modelled. Zero (the default) means the spring engages immediately. Because the behaviour is nonlinear, gaps are only honoured in a **nonlinear** analysis. In a linear static, modal or response-spectrum case the model is linearized and the gap is ignored — the support behaves according to the linearization chosen under Stiffness Option. This is the most common misunderstanding with gaps: they are entered, the analysis is linear, and nothing in the result reflects them. Increasing a gap delays engagement, increases the displacement at which load transfers, and sheds load to other supports at low load levels; below the gap-closing load the support contributes nothing at all. Results sensitive to it: displacements at low load, the order in which supports engage, and any envelope built from load levels that straddle gap closure. ## Links **Tx Link / Ty Link / Tz Link / Rx Link / Ry Link / Rz Link:** For each degree of freedom, another node whose corresponding degree of freedom this node is tied to. *Engineering influence.* This is a per-DOF tie expressed directly on the node — a compact alternative to an **Equal Constraint** object when only one or two directions need joining. The tied degrees of freedom share a single equation, so the two nodes move together in that direction; the tie is exact and adds no stiffness of its own. Leave empty for no tie. Use it for coincident nodes that must share some directions and stay independent in others: the two sides of a pin, a shear-only connection, or stitching two meshes along a line without welding rotations. Prefer explicit Equal Constraint objects when many directions or many node pairs are involved — they appear in one reviewable list, whereas ties buried on individual nodes are easy to lose track of. Do not tie a degree of freedom that is also restrained on this node, and do not chain ties through a node that is itself a slave; overlapping ties resolve in processing order and the result becomes order-dependent. ## Settings **Merge Nearest:** When YES, this node is merged with the nearest node found during model assembly. Used to stitch geometry generated separately that does not share exact coordinates. *Engineering influence.* Merging joins two sets of degrees of freedom into one, which **connects** parts of the model that were previously independent — a structural change, not a cosmetic one. Enabling it where two members were meant to stay separate silently welds them; failing to merge where they were meant to connect leaves an invisible discontinuity whose usual symptom is a mechanism, a singular matrix, or members carrying no load. Defaults to NO. **Merge Nearest ID / Merge Nearest Target:** Identify the specific node this one should merge with, rather than relying on proximity alone. {% hint style="warning" %} These two columns do **not currently appear** in the Nodes sheet: their parameters are not declared in the object type, so the columns are dropped when the table is built. The class supports them, but they cannot be set from this table today. {% endhint %} **Merge w/Same Loc Node:** When YES (the **default**), nodes at identical locations are merged automatically. *Engineering influence.* This default is why coincident geometry usually just works. It is also why two members that happen to share a coordinate become connected when they were meant to be separate — an expansion joint modelled as two nodes at the same point is welded shut unless this is turned off. Setting it to NO keeps coincident nodes independent, which is what a joint, a gap, or a link element between coincident points requires. **Merge w/Spring:** Controls whether a node carrying a spring participates in merging. Defaults to NO, which protects support conditions from being absorbed into a neighbouring node during assembly. Enabling it can silently relocate or duplicate a restraint. **Use Nonlinear Penalty:** Whether the nonlinear penalty formulation is used for this node's nonlinear conditions (gaps and one-sided behaviour). Defaults to YES. It affects **how** the condition is enforced numerically, not what the condition is. Turning it off changes convergence behaviour and is a troubleshooting measure for a nonlinear case that will not converge, not a modelling decision. **Disp Based Force Scaling NL:** Enables displacement-dependent scaling of this node's forces in a nonlinear analysis. Defaults to NO. Use only where the support force genuinely varies with the displacement of a reference set of nodes; enabling it without a coherent node group and factor list produces support forces that correspond to no simple stiffness. **Force Scaling Node Group:** The FE Group whose displacements drive the scaling above. Only meaningful when Disp Based Force Scaling NL is YES. **Force Scaling Factors:** The factors applied. Only meaningful when Disp Based Force Scaling NL is YES, and must be consistent in length with the node group it accompanies. ## Stiffness Option These twelve columns decide what stiffness a **nonlinear** support contributes when the analysis being run is **linear**. A linear static, modal, response-spectrum or non-FNA time-history case cannot use a gap or a one-sided spring, so it must substitute something. **Tx / Ty / Tz / Rx / Ry / Rz Linear Mode:** How the linear stiffness is obtained for that degree of freedom: | Mode | Meaning | | ----------------------- | -------------------------------------------------------------- | | **Nonlinear** (default) | tangent/initial stiffness taken from the current state | | **Initial Stiffness** | always the slope of the nonlinear curve at zero displacement | | **Effective Stiffness** | the constant value typed in the matching Eff. Stiffness column | **Tx / Ty / Tz Eff. Stiffness** and **Rx / Ry / Rz Eff. Stiffness:** The constant stiffness used when that direction's Linear Mode is Effective Stiffness. Ignored in the other two modes. *Engineering influence.* This is the standard initial-versus-secant stiffness question for dynamic analysis. **Initial Stiffness** gives the small-amplitude stiffness — appropriate for a serviceability or low-level vibration check — and produces shorter periods and generally higher spectral accelerations. **Effective Stiffness** lets you enter a secant stiffness representative of the expected response amplitude, which is what seismic codes normally require for isolators and other devices whose stiffness falls with displacement; it produces longer periods, usually lower forces, and larger displacements. The choice can change base shear by a factor of two or more, and neither option is universally conservative — a longer period reduces force demand while increasing displacement demand. An Effective Stiffness of zero means the support contributes **nothing** in that direction in a linear analysis, which can leave the model unstable. This is a common reason a linear case fails on a model whose nonlinear case solves without complaint. {% hint style="warning" %} The twelve Stiffness Option columns and the 6×6 Stiffness Matrix are **not declared in the object type**. They are still writable from the agent API and `set_parameter` — those resolve any field the object exposes in its sheet — but they lack the metadata a declared parameter carries: no unit category, no dropdown option list, and no authorability from a library template. Scripted writes also bypass the sheet's own conversion, so a Linear Mode must be given as its raw number (0 Nonlinear, 1 Initial Stiffness, 2 Effective Stiffness) rather than by name. {% endhint %} ## Verification * Display support symbols in the 3D view and confirm every intended restraint appears, in the right direction. This catches the free-versus-fixed sign error faster than reading the table. * Check reactions: they must equilibrate the applied load, and no reaction should appear at a degree of freedom you intended to be free. * Run a self-weight case and inspect the deflected shape for rigid-body motion (a missing restraint) or for a support that does not deflect where a spring was intended. * For a spring support, divide the reaction by the displacement at that degree of freedom; the result must return the stiffness you entered. This is the quickest way to detect a support entered as 1 when −1 was meant. * For a skewed support, display the node's local axes and confirm the restrained direction lies along the bearing line. * Compare the assembled model's node count against what you expect, to confirm coincident nodes merged (or did not) as intended. * For a gap, run the nonlinear case at load levels either side of closure and confirm the support engages at the right displacement. * Compare a simple support's reaction against statics by hand. ## Common mistakes * **Entering 1 to mean "fixed".** It creates a spring of stiffness 1, effectively an unrestrained support. Use −1. Older documentation stated this convention incorrectly, so models built from it should be re-checked. * **Leaving a support at 0 believing it is fixed.** Zero is free, and the result is either a singular matrix or a structure that visibly floats. * **Using a very large positive stiffness to mean fixed**, degrading matrix conditioning instead of using a negative value. * **Restraining in global axes at a skewed support**, generating reactions in directions the real bearing cannot resist. * **Relying on Merge w/Same Loc Node at an expansion joint**, silently welding a joint that should open. * **Entering gaps and then running a linear analysis**, where they are ignored entirely. * **Leaving Linear Mode at Nonlinear for an isolator**, then reading modal periods that correspond to the small-amplitude stiffness rather than the design displacement. * **Setting an Effective Stiffness of zero**, removing the support from every linear analysis. * **Restraining a degree of freedom that is also tied by a Link or an Equal Constraint**, where the restraint may belong to an equation that has been eliminated. * **Over-restraining** — fixing all six degrees of freedom at several supports on a structure that must expand — producing large spurious thermal and shrinkage forces. # Springs \[FEA] A Spring (also called a link) is a two-node connector element with a defined stiffness in each of six directions, independent of any material or section. Where a node's own DOF values describe a support to ground, a Spring describes a connection **between two points in the model**. Use it for bearings, isolators, shear keys, expansion-joint restrainers, soil springs alongside a pile, and any connection whose stiffness is known directly as force per unit displacement rather than derived from geometry. A Spring contributes to the **stiffness matrix** only. It carries no mass and generates no load. {% hint style="danger" %} The stiffness columns use the same sign convention as node supports: Entering **1** does not make a direction rigid; it creates a spring of stiffness 1 force unit per length unit, which for any real structure behaves as free. {% endhint %} | Value | Meaning | | --------------------- | -------------------------------------------------------- | | **0** | **Free** — no connection in that direction (the default) | | **negative** (use −1) | **Rigid** — the two nodes are tied in that direction | | **positive** | **Elastic spring** of that stiffness | ## Geometry **Node 1 / Node 2:** The two joints the spring connects. These are **connectivity** parameters: they determine what is joined and, with the nodes' positions, the direction the spring acts in. The two nodes are very often **coincident** — a bearing modelled as a zero-length link between the girder soffit node and the pier-top node. That is the normal arrangement, and it is why **Merge w/Same Loc Node** must usually be turned OFF on those nodes: if they merge, the spring has nothing left to connect and its stiffness disappears from the model with no warning. The spring acts in **global** directions. Define together with the six stiffness values; a spring with both nodes set but every stiffness at 0 connects nothing. **Tx / Ty / Tz:** Translational stiffness along each global axis, in force per unit length. **Rx / Ry / Rz:** Rotational stiffness about each global axis, in moment per unit angle. *Engineering influence, common to all six.* Each direction is independent — this is a diagonal stiffness, not a coupled one. Increasing a stiffness transfers more force through the connection and reduces relative movement between the two nodes; decreasing it toward zero lets them move independently and sheds that load elsewhere. What matters is the value **relative to** the members either side: a bearing stiffness that behaves as nearly rigid under a flexible pier is nearly free under a stiff one, so a number copied from another project without checking that ratio can behave completely differently. A value of 0 means no connection in that direction — exactly how a guided bearing is modelled: rigid across the bearing line, free along it. Setting every direction rigid turns the spring into a full moment connection and defeats the purpose of modelling a bearing at all. Very large positive values are a poor way to express "rigid": they add terms orders of magnitude larger than the surrounding structure, degrade conditioning, and produce noisy reactions and spurious high-frequency modes. Use a negative value. Results sensitive to these: the force transferred through the connection, the distribution of lateral load between substructure elements, and — because a soft link lengthens periods — the whole dynamic response of an isolated structure. **Group:** The FE Group used for construction-stage activation and selection. A spring whose group is inactive in a stage does not exist in that stage, which is how a temporary bearing or a restrainer installed partway through erection is modelled. ## Gap **Tx Gap / Ty Gap / Tz Gap:** A translational gap, in length units, that must close before the spring engages in that direction. **Rx Gap / Ry Gap / Rz Gap:** A rotational gap, in angle units, before the rotational spring engages. *Engineering influence.* A gap makes the connection **nonlinear and one-sided**: the nodes move freely relative to one another until the gap closes, then the stiffness applies. This is the natural model for a shear key with a construction clearance, an expansion joint that closes under thermal contraction, or a restrainer cable that acts only once slack is taken up. Zero (the default) means the spring engages immediately. Gaps are honoured only in a **nonlinear** analysis. In a linear static, modal or response-spectrum case the connection is linearized per the Stiffness Option settings and the gap has no effect — which is why a shear key entered with a gap can appear to carry load from the very first increment of a linear run. Related to this, one-sided behaviour is expressed through the stiffness value itself rather than the gap column: a bracketed stiffness `[value]` denotes a **tension-only** (hook) spring and `[-value]` a **compression-only** (gap) spring. A shear key that must only push is entered as a negative-bracketed stiffness, not as a plain number with a gap. Increasing a gap delays engagement and increases relative movement before load transfers. Results sensitive to it: the order in which restraints engage, displacements at low load, and any envelope spanning load levels either side of closure. ## Stiffness Option These twelve columns decide what stiffness a **nonlinear** spring contributes when the analysis being run is **linear**. A linear static, modal, response-spectrum or non-FNA time-history case cannot represent gapping or a one-sided link, so it must substitute a constant stiffness. **Tx / Ty / Tz / Rx / Ry / Rz Linear Mode:** | Mode | Meaning | | ----------------------- | -------------------------------------------------------------- | | **Nonlinear** (default) | tangent/initial stiffness taken from the current state | | **Initial Stiffness** | always the slope of the nonlinear curve at zero displacement | | **Effective Stiffness** | the constant value typed in the matching Eff. Stiffness column | **Tx / Ty / Tz Eff. Stiffness** and **Rx / Ry / Rz Eff. Stiffness:** The constant stiffness used when that direction's Linear Mode is Effective Stiffness. Ignored in the other two modes. *Engineering influence.* This is where a seismic isolator's design assumption is expressed. **Initial Stiffness** gives small-amplitude behaviour — shorter periods, higher spectral accelerations — appropriate for serviceability or wind-vibration checks. **Effective Stiffness** lets you enter the secant stiffness at the expected design displacement, which is what isolation design normally requires; it lengthens periods, generally lowers force demand, and increases displacement demand. The two can differ by a factor of several, and neither is universally conservative. An Effective Stiffness of zero removes the connection entirely from every linear analysis, which commonly makes a linear case unstable on a model whose nonlinear case solves without complaint. {% hint style="warning" %} The twelve Stiffness Option columns and the 6×6 Stiffness Matrix are **not declared in the object type**. They remain writable from the agent API and `set_parameter` — those resolve any field the object exposes in its sheet — but they carry no unit category, no dropdown option list, and no authorability from a library template. Scripted writes bypass the sheet's own conversion, so a Linear Mode must be given as its raw number (0 Nonlinear, 1 Initial Stiffness, 2 Effective Stiffness). {% endhint %} ## Settings **Use Nonlinear Penalty:** Whether the nonlinear penalty formulation enforces this spring's nonlinear conditions. Defaults to YES. It changes **how** the condition is enforced numerically, not what the condition is; turning it off is a convergence-troubleshooting measure for a nonlinear case that will not converge, not a modelling decision. ## Stiffness Matrix **6x6 Stiffness Matrix:** A full 6×6 stiffness matrix for the connection, edited in its own sub-sheet, for links whose behaviour is **coupled** between directions. *Engineering influence.* The six values above form only the diagonal; they cannot express that a horizontal translation also produces a moment, as an eccentric or extended bearing does. A matrix produced by an **Equivalent Stiffness** point, or supplied by a bearing manufacturer, is normally full. It should be symmetric and positive-definite; one that is not can make the global system indefinite and cause the solve to fail. Leave empty when the diagonal values suffice. ## Verification * Check the spring's force and the relative displacement between its two nodes; their ratio must return the stiffness you entered. This is the fastest way to catch a direction entered as 1 when −1 was meant, or a spring whose nodes were merged away. * Confirm the two nodes still exist separately in the assembled model. If a coincident pair merged, the spring is inert. * Check that a direction left at 0 shows genuine relative movement; if it does not, something else is connecting the nodes. * For a guided bearing, confirm the reaction appears only in the restrained direction. * For a gap, run the nonlinear case either side of closure and confirm engagement at the right relative displacement. * Run a modal analysis on an isolated structure and confirm the isolated period matches a hand calculation from the effective stiffness and the supported mass. * Compare a single bearing against a hand calculation: force = stiffness × relative displacement. ## Common mistakes * **Leaving Merge w/Same Loc Node ON at a zero-length link**, merging the two nodes and silently deleting the connection. * **Entering 1 to mean rigid**, producing an essentially free direction. * **Using a huge stiffness instead of −1**, degrading matrix conditioning. * **Making every direction rigid**, turning a bearing into a moment connection that attracts load the real bearing cannot carry. * **Entering gaps and running a linear analysis**, where they are ignored. * **Leaving Linear Mode at Nonlinear for an isolator** and reading modal periods based on the small-amplitude stiffness rather than the design displacement. * **Copying bearing stiffnesses between projects** without checking them against the substructure stiffness they sit on. * **Setting Effective Stiffness to zero**, removing the link from every linear analysis. # Lines \[FEA] An FE Line is a one-dimensional element spanning two nodes. It is the workhorse of a bridge model — girders, columns, piles, braces, cross-frame members, stays and hangers are all FE Lines — and it carries the section and material that give it stiffness, together with the end conditions, offsets and property modifiers that tailor its behaviour. An FE Line contributes to the **stiffness matrix**, contributes **mass** (through its self-weight and material density) and can **generate load** (self-weight, and pretension where applicable). ## Geometry **Type:** The element formulation: Beam, Truss, Compression Truss, Tension Truss, Cable, or Inelastic Line. *Engineering influence.* This decides which degrees of freedom the element actually connects. **Beam** carries axial force, shear, bending and torsion — the default and the right choice for girders and columns. **Truss** carries axial force only, so it transmits no moment regardless of the end releases; use it for pin-ended bracing where modelling the release explicitly would be redundant. **Compression Truss** and **Tension Truss** are one-sided: they drop out of the structure when the force reverses, which is how slack bracing or a bearing that cannot pull is modelled. **Cable** is a tension-only member intended for stays and hangers. **Inelastic Line** enables the fibre/hinge formulation for pushover work. The one-sided types (Compression Truss, Tension Truss, Cable) are only honoured in a **nonlinear** analysis. In a linear static or modal run they behave as ordinary truss members and will happily carry the force they are supposed to shed — which is why a cable-stayed model can show compression in stays in a linear case and not in the nonlinear one. Changing Beam to Truss removes the member's bending stiffness entirely and can leave the structure a mechanism if that bending was providing stability. **Node 1 / Node 2:** The joints the element spans. These are **connectivity** parameters; with the nodes' coordinates they set the element length and its local axis direction. The order matters: Node 1 is the "start" or "i" end and Node 2 the "end" or "j" end. End releases, end offsets, and the sign convention of reported end forces are all keyed to this order, so reversing two nodes on an otherwise identical member flips the sign of its reported moments and swaps which end a release applies to. **Section at Start / Section at End:** The cross-section at each end. Setting them differently produces a **tapered** member, with properties interpolated between the two. *Engineering influence.* Section properties are the element's stiffness: axial stiffness scales with area, bending stiffness with moment of inertia, torsional stiffness with the torsion constant. A member with no section assigned has no stiffness and is one of the most common causes of a singular matrix or a wildly flexible model. Leave Section at End empty for a prismatic member. Tapering is linear between the two sections; a member whose real depth varies non-linearly should be subdivided into several elements rather than relying on a single taper. **Beta Angle:** Rotation of the element's cross-section about its own longitudinal axis, in angle units. *Engineering influence.* This orients the section's strong and weak axes relative to the global frame. It does not change the section's properties — it changes which direction each one resists. A girder with its strong axis rotated 90° is enormously more flexible vertically, which typically shows up as deflections an order of magnitude too large, or as a structure whose lowest modes are in the wrong direction. For a vertical member the default orientation is often not what you want, so this is the parameter to check first when a column behaves unexpectedly. Local axes should be displayed and checked visually rather than reasoned about from the number. **Group:** The FE Group used for stage activation and selection. A line whose group is inactive in a stage does not exist in that stage. **Pretension:** The cable jacking force, in force units, applied by a **Cable Stressing Load** as an equivalent initial-tension load. *Engineering influence.* Setting a value here does **not** by itself apply anything: it is the magnitude a Cable Stressing Load will use when it stresses this member. A cable with a pretension and no stressing load carries no prestress; a stressing load pointed at a cable with zero pretension applies exactly nothing. Increasing it increases the cable force and, in a stayed structure, lifts the deck and redistributes moment toward the anchorages. **Length (readonly) / Weight (readonly):** Derived values reporting the element's computed length and self-weight. Useful for verification — a length that is not what you expect indicates a node coordinate error, and a weight of zero indicates a missing section or a material with no density. {% hint style="warning" %} These two columns are derived and cannot be edited, but they are not flagged read-only, so typing into them appears to work and the value is discarded on redraw. {% endhint %} ## Global Offset **Node 1 Offset X / Y / Z** and **Node 2 Offset X / Y / Z:** Rigid offsets, in **global** directions, between the node and the element's actual end. *Engineering influence.* An offset inserts a rigid link between the joint and the member end, so the member behaves as though it starts at the offset position while still connecting to the node. This is how a girder is connected to a pier-top node at the correct soffit level, or how the eccentricity between a deck centroid and a girder centroid is represented without adding extra joints. Offsets introduce a **lever arm**, so an axial force in the member produces a moment at the node. That is usually the point — it is the mechanism by which composite eccentricity generates the right behaviour — but it also means an incorrect offset produces spurious moments that are hard to trace, because the member's own forces look perfectly reasonable. Zero (the default) means the member ends at the node. **Related setting:** by default a rigid end offset does **not** expand under uniform temperature, which can lock in force in a restrained member. See **End Offsets Expand Thermally** under Settings. ## Local Offset **Node 1 Offset X / Y / Z** and **Node 2 Offset X / Y / Z:** The same idea expressed in the element's **local** axes rather than global ones. *Engineering influence.* Local offsets follow the member's orientation, so they stay correct when the member is skewed, sloped or rotated — which makes them the better choice for an offset that is defined relative to the section (a soffit offset, an insertion-point offset) rather than relative to the global frame. Global offsets are appropriate when the offset is genuinely a global-direction quantity, such as a fixed vertical drop. Do not enter the same physical offset in both tabs; they add. Use one or the other. ## End Releases **Node 1 Tx / Ty / Tz / Rx / Ry / Rz** and **Node 2 Tx / Ty / Tz / Rx / Ry / Rz:** The connection condition for each degree of freedom at each end. {% hint style="danger" %} **Sign convention — the same as node supports:** Entering `-1` to "release" an end produces a **fixed, moment-carrying** connection. Use `0` to release. Right-click a cell for *Set to Free*, *Set to Fixed* and *Edit Stiffness…* rather than typing the number, which avoids the mistake entirely. {% endhint %} | Value | Meaning | | ------------ | ----------------------------------------- | | **−1** | **Rigid / fully connected** (the default) | | **0** | **Released** — a hinge in that direction | | **positive** | **Semi-rigid** spring of that stiffness | *Engineering influence.* Releasing a rotational degree of freedom converts a moment connection into a pin, which **reduces** the member's end moment to zero and redistributes it into the span and into adjacent members. Releasing makes the structure softer, increasing deflections; over-releasing creates a mechanism and a singular stiffness matrix. Releasing translations is rarer and usually indicates that a spring or a truss element is the better model. A semi-rigid value expresses partial fixity — a bolted connection that is neither pinned nor fixed. What matters is its magnitude relative to the member's own `EI/L`; a value much larger behaves as fixed, much smaller as pinned, and the interesting range is within about an order of magnitude either side. Do not release the same degree of freedom at **both** ends of a member unless something else restrains it: a beam pinned for torsion at both ends is free to spin about its axis. Releases are ignored for Truss-type elements, which already connect only axial force. **Release Coordinate System:** Whether the releases above are interpreted in **Global** (the **default**) or **Local** axes. *Engineering influence.* Local is normally what you want — a hinge is a property of the connection and follows the member — but it is **not** the default, so a release entered on a sloped, skewed or vertical member without changing this is applied about the global axes instead. For a member aligned with the global frame the two agree and the setting is invisible; for anything else it releases a different direction than intended, and the symptom is a member that still carries moment about the axis you thought you had freed. ## Overrides **Section Area / Shear Area Y / Shear Area Z / Torsion Constant / Inertia Y / Inertia Z:** Absolute override values that replace the corresponding property computed from the assigned section. **Material Modulus of Elasticity / Poisson's Ratio:** Absolute overrides for the material properties. **…Factor columns** (Modulus of Elasticity Factor, Poisson's Ratio Factor, Section Area Factor, Shear Area Y/Z Factor, Torsion Constant Factor, Inertia Y/Z Factor): **multipliers** applied to the corresponding property instead of replacing it. *Engineering influence.* These exist for two very different purposes and it is worth being clear which one you are using. **Absolute overrides** substitute a property the section geometry cannot express — a built-up member, a section whose torsion constant has been computed elsewhere, or matching a reference model exactly. **Factors** apply code-prescribed stiffness modifiers: cracked-section properties for concrete in a seismic analysis (commonly 0.35–0.7 on inertia), a reduced torsion constant to reflect concrete cracking in torsion (often 0.1 or lower), or a shear-area factor to tune shear deformation. Reducing an inertia factor softens the member in that direction, lengthens periods, and — because stiffness attracts load in a redundant structure — **sheds** force from that member into stiffer ones. This makes the choice consequential and not conservative in a single direction: softening a pier reduces its own moment but increases the demand on its neighbours. A factor of 1 leaves the property unchanged; a factor of 0 removes that stiffness entirely and will usually make the model unstable. The torsion constant is the property most often modified in concrete bridge work, because an uncracked `J` grossly overstates the torsional stiffness a cracked concrete member actually delivers, and an overstiff torsional path attracts load away from the bending path where the design expects it. {% hint style="warning" %} None of the parameters on this tab are declared in the object type. They are still writable from the agent API and `set_parameter` — those resolve any field the object exposes in its sheet — but they carry no unit category and no authorability from a library template, and scripted writes bypass the sheet's own conversion. {% endhint %} ## Settings **Is Rigid:** Marks the member as rigid, so it transfers force without deforming. *Engineering influence.* A rigid member connects its two ends without adding flexibility, which is useful for representing a stiff connection block, a rigid arm, or a pier cap idealized as non-deforming. It is an idealization: real members are not rigid, and making a member rigid attracts force to it and to whatever it connects, which can materially change the distribution in a redundant structure. Prefer real stiffness where you have it. **Geometric Nonlinear:** Whether the element's geometric stiffness is included, so that axial force affects its bending stiffness. Defaults to YES. *Engineering influence.* This is the P-delta effect at member level: compression reduces the effective bending stiffness and amplifies deflection and moment, while tension stiffens the member. It is only active in a **nonlinear** analysis; a linear static case ignores it regardless of the setting. It matters most for slender compression members and for cables, where tension stiffening is the dominant source of stiffness — a stay analysed without it is far too flexible. **End Offsets Expand Thermally:** Whether a rigid end offset is treated as expanding under uniform temperature. Defaults to NO. *Engineering influence.* With the default, the rigid offset does **not** change length under a temperature change, so a member with offsets in a restrained structure locks in force under uniform temperature that the real structure would not develop. Setting it to YES makes the thermal-free length the node-to-node span, releasing that spurious force. Turn it on where offsets are long enough for the difference to matter and where uniform temperature governs; leave it off to preserve legacy behaviour. ## Time Dependent **Casting Day:** The day the member is cast, used by time-dependent analysis to compute concrete creep, shrinkage and modulus development. *Engineering influence.* Age at loading drives creep: concrete loaded young creeps substantially more than mature concrete, so a casting day that is wrong by a significant margin misstates long-term deflections and the redistribution of force between stages. It only has effect when the analysis includes time-dependent effects and the material is configured for them; in an ordinary static run it is inert. ## Verification * Display local axes and confirm the strong axis of each member points the way you intend. This is the fastest check on Beta Angle. * Check the **Length** and **Weight** columns against expectation; a wrong length means a node coordinate error, and a zero weight means a missing section or density. * Read end moments at any end you released — a released rotation must report **zero moment**. This is the definitive check on the release sign convention. * Confirm a Truss-type member reports no moment. * Check deflections against a hand calculation for a simple span (`5wL⁴/384EI`) to confirm section and material are being picked up. * Where property factors are used, compare the member's stiffness contribution against the unfactored model to confirm the factor took effect. * For a one-sided type (Cable, Tension/Compression Truss), run the nonlinear case and confirm the member drops out when its force reverses. * Where offsets are used, check for unexpected moments at the connected node. ## Common mistakes * **Entering −1 to release an end**, which fixes it instead. Verify by reading the end moment. * **Wrong Beta Angle**, orienting a girder's weak axis vertically. Deflections come out an order of magnitude too large. * **No section assigned**, giving a member with no stiffness. * **Reversing Node 1 and Node 2** on some members but not others, so reported end-force signs are inconsistent across a run of otherwise identical members. * **Releasing the same rotation at both ends** and creating a mechanism. * **Entering the same offset in both the Global and Local tabs**, doubling it. * **Using Truss where Beam was needed**, silently removing bending stiffness that was holding the structure up. * **Applying cracked-section factors to steel members**, or leaving concrete torsion at its uncracked value and attracting load into a torsional path the real structure cannot sustain. * **Setting Pretension but never creating a Cable Stressing Load**, so no prestress is applied. * **Expecting one-sided types or geometric nonlinearity to act in a linear analysis**, where both are ignored. # Surfaces \[FEA] An FE Surface is a two-dimensional shell element spanning three or four nodes. It is used for decks, slabs, webs, walls, diaphragm plates and any component whose behaviour is governed by plate action rather than beam action. A shell carries both **membrane** action (in-plane forces) and **bending** action (out-of-plane moments), plus a drilling degree of freedom that lets it connect properly to beams and to neighbouring shells. It contributes to the **stiffness matrix**, carries **mass** through its thickness and material density, and **generates load** through self-weight. ## Geometry **Node 1 / Node 2 / Node 3 / Node 4:** The corner joints. Supply three for a triangle, four for a quadrilateral. *Engineering influence.* Node **order** defines the element's local axes and the sign of its reported forces, and it must go consistently around the perimeter — a quadrilateral whose nodes are listed in a crossed order produces a self-intersecting "bow-tie" element with a meaningless Jacobian. Consistent ordering across a mesh also matters for interpreting results: shells whose local axes alternate direction report Mxx of opposite sign on adjacent elements, which looks like a discontinuity in the results but is only a sign convention. Element **shape** drives accuracy. Quadrilaterals close to rectangular are the most accurate; accuracy degrades as elements become skewed, warped out of plane, or extreme in aspect ratio. Triangles are stiffer than quads for the same mesh density and are best used to transition between regions rather than to fill a whole panel. **Thickness:** The shell thickness. *Engineering influence.* Thickness is the dominant stiffness parameter and it does **not** act linearly across the two behaviours: membrane stiffness scales with `t`, but bending stiffness scales with `t³`. Doubling the thickness therefore doubles in-plane stiffness while increasing out-of-plane stiffness eightfold. It also scales self-weight linearly. A small thickness error has a large effect on deflection and on how load distributes between plate action and any supporting beams. Thickness also determines whether transverse shear deformation matters, which interacts with the Plate Type setting below. **Material:** The material supplying modulus, Poisson's ratio and density. A shell with no material has no stiffness and no self-weight. **Area (readonly) / Weight (readonly):** Derived values. Compare the total weight of a deck against a hand calculation as a quick check that thickness, material density and mesh extent are all right. {% hint style="warning" %} These two columns are derived and cannot be edited, but they are not flagged read-only, so typing into them appears to work and the value is discarded on redraw. {% endhint %} ## Global Offset **Node 1–4 Offset X / Y / Z:** Rigid offsets in **global** directions between each node and the shell's actual corner. *Engineering influence.* The usual purpose is eccentricity: connecting a deck shell at its mid-surface to girder nodes at the girder centroid, so that composite action develops through the lever arm between them. That lever arm is what makes the deck act compositely with the girders, so an incorrect offset changes the composite section properties the model effectively has, and therefore the share of moment carried by deck versus girder. Zero (the default) puts the shell corner at the node. ## Local Offset **Node 1–4 Offset X / Y / Z:** The same offsets expressed in the element's **local** axes. *Engineering influence.* Local offsets follow the shell's orientation, which is the better choice for an offset defined relative to the shell itself — a mid-surface-to-soffit offset on a deck that is superelevated or curved. Global offsets suit genuinely global quantities. Do not enter the same physical offset in both tabs; they add. ## End Releases **Node 1–4 Tx / Ty / Tz / Rx / Ry / Rz:** The connection condition at each corner, in global axes. {% hint style="danger" %} **Sign convention — the same as node supports and line end releases:** Entering `-1` intending to release a corner produces a **fixed** connection. Use `0` to release. Right-click for *Set to Free*, *Set to Fixed* and *Edit Stiffness…* rather than typing the number. {% endhint %} | Value | Meaning | | ------------ | ----------------------------------------- | | **−1** | **Rigid / fully connected** (the default) | | **0** | **Released** — free in that direction | | **positive** | **Semi-rigid** spring of that stiffness | *Engineering influence.* Corner releases are used far less often on shells than on lines, and they are easy to misuse: releasing a corner disconnects the shell from the mesh in that direction, which can leave a hole in the load path or make the element unstable. The common legitimate case is releasing a rotational degree of freedom where a shell meets a member that cannot carry that moment. Releasing the same degree of freedom at every corner leaves the element unrestrained in that direction. ## Overrides **Section Thickness:** An absolute override of the thickness used for stiffness, leaving the assigned value intact elsewhere. **Material Modulus of Elasticity / Poisson's Ratio:** Absolute overrides of the material properties. **Membrane Fxx / Fyy / Fxy Modifier (local):** Multipliers on the in-plane stiffness terms. **Bending Mxx / Myy / Mxy Modifier (local):** Multipliers on the out-of-plane stiffness terms. *Engineering influence.* These modifiers are how code-prescribed stiffness reductions are applied — cracked-section properties for a concrete deck or wall in a seismic analysis, or a deliberate softening in one direction to represent one-way behaviour or a jointed slab. They act in the shell's **local** axes, so their meaning depends on the element's orientation; applying a directional modifier to a mesh whose local axes are inconsistent produces a stiffness field that varies element by element. Reducing a modifier softens the shell in that action, increases its deflection, and **sheds** force into stiffer adjacent elements — so softening a deck increases the demand on the girders. A modifier of 1 (the default) leaves the term unchanged; 0 removes that stiffness entirely and will usually make the model unstable. Separating membrane from bending matters: a deck may be cracked in bending while retaining most of its in-plane stiffness, and modifying both together overstates the reduction. **Plate Type:** The bending formulation — **Thin** (Kirchhoff, no transverse shear) or **Thick** (Mindlin, shear-deformable), or Default to inherit the global setting. *Engineering influence.* Thin plate theory ignores transverse shear deformation, which is accurate while the element is slender relative to its span and increasingly wrong as it thickens. Thick (Mindlin) includes shear deformation and is the right choice for a deep or stubby panel; it is also what matches a SAP2000 thick-plate model. For a thin deck the two give nearly identical answers, so the setting matters most for thick slabs, pier caps modelled as plates, and deep webs. Choosing Thin for a genuinely thick element **overstates** stiffness and understates deflection. **Triangle Formulation:** The membrane/bending formulation used for three-noded shells — **DKGT** (the default, quad-compatible drilling) or **ANDeS** (high-performance membrane). *Engineering influence.* DKGT shares the drilling convention used by the quadrilateral elements, so it balances correctly where triangles and quads meet. The cost is that its membrane behaviour is constant-strain grade and therefore stiff in in-plane bending. ANDeS has a far better membrane and is the better choice for a panel dominated by in-plane bending — a shear wall or a deep-beam web — but it keeps a moment-carrying drilling convention that only behaves in a narrow envelope. Use ANDeS **only** where all three of these hold: the triangle's neighbours are not quads; the surface is flat rather than faceted-curved; and loads are applied at nodes rather than as distributed surface loads. Outside that envelope the errors are large and not obvious — a mixed mesh misreads displacement by around 8% and stress by around 30%, a pressurized faceted cylinder with a free end bulges by roughly 189%, and under distributed load the error is erratic and gets *worse* under refinement. DKGT holds around 0.02% across the same cases. When in doubt, leave it at DKGT. **Formulation (in use):** Read-only, reporting the formulation actually applied after the Default settings resolve. Check it when you are not sure which formulation a given element ended up with. **Modifier Axis Global X:** Controls the reference axis used to interpret the directional modifiers, so that "local xx" can be tied to a consistent global direction across a mesh. *Engineering influence.* This is what makes directional modifiers usable on a real mesh. Without a consistent reference, "Membrane Fxx modifier" means a different physical direction on each element, and a deck intended to be softened longitudinally ends up softened in a patchwork of directions. {% hint style="warning" %} **Geometric Nonlinear** is honoured by the solver on shells, but the column does **not currently render** in the sheet — its parameter is declared on FE Line rather than on FE Surface, so the column is dropped when the table is built. It **defaults to ON**, so in a nonlinear analysis your shells are already running with geometric stiffness included; you simply cannot see or change that from this table. If you need it off for a particular shell, it has to be set outside this sheet. {% endhint %} ## Groups **Group:** The FE Group used for construction-stage activation and selection. A shell whose group is inactive in a stage does not exist in that stage — which is how a deck cast in a later pour, or a temporary panel, is represented. ## Time Dependent **Casting Day:** The day the shell is cast, used by time-dependent analysis to compute concrete creep, shrinkage and modulus development. *Engineering influence.* Age at loading drives creep: concrete loaded young creeps substantially more than mature concrete. For a deck this matters directly — a slab made composite and loaded early creeps more, increasing long-term deflection and shedding force toward the girders over time. The value is inert unless the analysis includes time-dependent effects and the material is configured for them, and it should reflect the real pour sequence rather than being left at a single default across a deck poured in stages. ## Verification * Display shell local axes across the mesh and confirm they are consistent. Inconsistent axes make directional modifiers and result signs unreliable. * Check **Area** and **Weight** totals against a hand calculation of the deck. * Confirm a released corner reports zero force in the released direction. * Run a patch test: a uniformly loaded, simply supported plate should reproduce the closed-form deflection closely. This validates thickness, material and formulation together. * Refine the mesh and confirm results converge. Shell results that move substantially under refinement indicate the mesh, not the model, is governing. * Compare Thin against Thick on a representative panel; a large difference means shear deformation matters and Thick is required. * Where modifiers are applied, compare against the unmodified model to confirm they took effect and in the intended direction. * Check for warped or highly skewed elements, which degrade accuracy silently. ## Common mistakes * **Entering −1 to release a corner**, which fixes it instead. * **Inconsistent node ordering**, producing alternating result signs across a mesh and, at worst, bow-tie elements. * **Forgetting that bending stiffness scales with `t³`**, so a thickness entered in the wrong unit is off by a factor of 1000 in bending, not 10. * **Using Thin plate theory on a thick element**, overstating stiffness. * **Choosing ANDeS outside its envelope** — next to quads, on a faceted-curved surface, or under distributed load — where its errors are large and not obvious. * **Applying directional modifiers to a mesh with inconsistent local axes**, softening a patchwork of directions rather than the one intended. * **Modifying membrane and bending together** when only bending is cracked. * **Meshing too coarsely** near supports and concentrated loads, where shell stress gradients are steepest. * **Omitting offsets between deck and girder**, losing composite action entirely. # Volumes \[FEA] An FE Volume is a three-dimensional solid element spanning eight nodes (a hexahedron, or "brick"). It is used where the full three-dimensional stress state matters and neither beam nor shell idealization is adequate — anchorage zones, thick pier caps, footings, deep bearing seats, and local regions around a discontinuity. A Volume contributes to the **stiffness matrix**, carries **mass** through its material density, and **generates load** through self-weight. Its nodes have translational degrees of freedom only; a solid element has no rotational stiffness, which is the single most important consequence of choosing it. {% hint style="warning" %} The **Volumes** node is currently disabled in the FEA tree, so this object is not reachable from the object tree in the running product even though the element type is fully supported by the solver. Solid models are still built through meshing and import paths. {% endhint %} {% hint style="info" %} Only the 8-node hexahedron is available. There is no tetrahedron, wedge, or higher-order solid, so a region that cannot be swept into a reasonably regular brick mesh is usually better idealized with shells. Solid elements also do not round-trip through SAP2000 import/export. {% endhint %} ## Geometry **Node 1 … Node 8:** The eight corner joints of the hexahedron. *Engineering influence.* Node **order** must follow the standard brick convention — the four nodes of one face, then the four of the opposite face in the same rotational sense. An inconsistent order produces an inverted or self-intersecting element with a negative Jacobian, which the solver cannot integrate meaningfully; the usual symptom is a failed solve or grossly wrong local stresses. Element **shape** matters more for solids than for any other element type. Accuracy is best when the brick is close to a cube; it degrades as elements become elongated, skewed or warped. An 8-node brick also suffers from shear locking in bending: a single layer of bricks through the depth of a member in flexure is far too stiff, so several elements through the thickness are needed wherever bending dominates. **Because solid nodes carry no rotational stiffness**, connecting a beam or a shell directly to a solid transfers force but **not moment** — the beam effectively becomes pinned where it meets the solid. This is the most common modelling error with solids and it is silent: the model solves, and the member simply sheds the moment the designer expected it to carry. Where moment must transfer, the connection has to be made over a patch of several solid nodes, or through a constraint that couples the rotation. **Material:** The material supplying modulus, Poisson's ratio and density. A volume with no material has no stiffness and no self-weight. *Engineering influence.* Poisson's ratio is more consequential in a solid than in a beam or shell, because a fully three-dimensional element develops confining stress: a value approaching 0.5 (incompressible, as for some rubbers) causes volumetric locking, in which the element becomes artificially stiff and stresses become unreliable. For concrete and steel the usual values cause no difficulty. **Volume (readonly) / Weight (readonly):** Derived values. Comparing total weight against a hand calculation is the quickest confirmation that the mesh covers the intended region and the density is right. {% hint style="warning" %} These two columns are derived and cannot be edited, but they are not flagged read-only, so typing into them appears to work and the value is discarded on redraw. {% endhint %} ## Global Offset **Node 1–8 Offset X / Y / Z:** Rigid offsets in **global** directions between each node and the element's actual corner. Zero (the default) places the corner at the node. Offsets are used far less often on solids than on lines or shells, and a non-zero offset distorts the element's shape, which degrades integration accuracy. ## Local Offset **Node 1–8 Offset X / Y / Z:** The same offsets expressed in the element's local axes. Do not enter the same physical offset in both tabs; they add. ## End Releases **Node 1–8 Tx / Ty / Tz / Rx / Ry / Rz:** The connection condition at each corner, in global axes. {% hint style="danger" %} **Sign convention — the same as node supports and line end releases:** Entering `-1` intending to release a corner produces a **fixed** connection. Use `0` to release. {% endhint %} | Value | Meaning | | ------------ | ----------------------------------------- | | **−1** | **Rigid / fully connected** (the default) | | **0** | **Released** — free in that direction | | **positive** | **Semi-rigid** spring of that stiffness | *Engineering influence.* Releasing a translation at a solid corner disconnects that node from the load path in that direction and normally leaves a hole in the mesh; it is rarely what you want. The rotational columns are of little practical use here, because a solid element has no rotational stiffness at its nodes to release in the first place. ## Overrides **Material Modulus of Elasticity:** An absolute override of the material's modulus for this element. **Material Poisson's Ratio:** An absolute override of the material's Poisson's ratio for this element. *Engineering influence.* These substitute properties for an individual solid without editing the shared material, which is how a locally softened region — cracked concrete around an anchorage, a degraded zone, or a deliberately reduced-stiffness block — is represented. Reducing the modulus softens that element and sheds force into the surrounding solids. Poisson's ratio deserves particular care here: a solid element develops confining stress, and a value approaching 0.5 causes volumetric locking, making the element artificially stiff and its stresses unreliable. Overriding toward that range is more consequential in a solid than it would be in a beam or shell. ## Groups **Group:** The FE Group used for construction-stage activation and selection. A volume whose group is inactive in a stage does not exist in that stage. **Casting Day:** The day the element is cast, used by time-dependent analysis to compute creep, shrinkage and modulus development. Concrete loaded young creeps substantially more than mature concrete, so an incorrect casting day misstates long-term deformation and the redistribution of force between stages. It is inert unless the analysis includes time-dependent effects. ## Verification * Check **Volume** and **Weight** against a hand calculation of the region being modelled. * Confirm no element reports an inverted or negative Jacobian; if the solve fails on a solid region, node ordering is the first thing to check. * Refine the mesh and confirm stresses converge. Solid stress results are more mesh-sensitive than beam or shell results, and a single run tells you little on its own. * Check that at least two or three elements span the thickness anywhere bending is significant, and compare against a shell or beam idealization of the same region — a solid model far stiffer than the equivalent beam usually indicates shear locking from too few elements through the depth. * Where a beam or shell frames into the solid, check whether moment is actually transferring. If the member reports near-zero moment at that face, the connection is behaving as a pin. * Compare a simple block under uniform compression against `σ = P/A` and `δ = PL/AE`. ## Common mistakes * **Connecting a beam or shell to a single solid node and expecting moment continuity.** Solid nodes have no rotational stiffness, so the connection is effectively pinned and the moment silently disappears. * **Incorrect node ordering**, producing an inverted element. * **One element through the thickness in a bending region**, giving a grossly overstiff result through shear locking. * **Highly distorted elements** — elongated, skewed or warped bricks — which degrade accuracy without any warning. * **Using solids where shells would do.** A solid model of a slab needs far more elements and produces results that are harder to interpret than the plate forces a shell reports directly. * **A Poisson's ratio close to 0.5**, causing volumetric locking. * **Expecting solids to survive a SAP2000 round-trip**, which they do not. # Equal Constraints \[FEA] An Equal Constraint ties selected degrees of freedom of one joint to the **same** degrees of freedom of another joint, with a coefficient of one. In the constrained directions the two joints share a single equation and therefore move identically — the slave joint's own equation is eliminated from the system. Use it wherever two coincident or nearly-coincident joints must move together in some directions but remain independent in others: a pinned splice that transfers translation but not moment, a shear key, a bearing that is fixed longitudinally and free transversely, or two meshes that must be stitched along a line without welding every rotational DOF. Equal Constraints affect **connectivity and the stiffness matrix**. They add no stiffness of their own, generate no load, and add no mass — they remove equations by merging them. This makes them exact rather than approximate, which is the main reason to prefer them over a very stiff spring. {% hint style="info" %} **Equal Constraint vs. Rigid Diaphragm.** An Equal Constraint is a strict same-DOF tie with no lever arm: `Ux_slave = Ux_master`. It cannot represent a body that *rotates* about the master, because a lever-arm term couples a slave translation to a master rotation. When you need in-plane rigid-body behaviour — a deck acting as a rigid diaphragm — use **Rigid Diaphragms** instead. {% endhint %} {% hint style="warning" %} **Prefer a constraint over a very stiff spring.** Modelling a rigid tie as a large spring stiffness introduces an artificial term many orders of magnitude larger than the surrounding structure, which degrades the conditioning of the stiffness matrix and can produce numerical noise in reactions and higher modes. An Equal Constraint eliminates the DOF exactly and adds no conditioning penalty. {% endhint %} ## Geometry **Master Node:** The joint whose degrees of freedom are **retained**. In the constrained directions the master's equation is the one both joints solve on, so the pair's response is reported at the master. This is a **connectivity** parameter. Which of the two joints you nominate as master does not change the physics of a coefficient-one tie, but it does determine where the retained equation lives — choose the joint that is genuinely part of the structure rather than a stray or mass-only joint. Define together with Slave Node and at least one constrained direction. Verify by checking that the two joints report identical displacements in the tied directions. **Slave Node:** The joint whose selected degrees of freedom are **eliminated**. Its own equations in those directions are left orphaned and stabilized internally, so the slave no longer has independent freedom there. Because the slave's equation is removed rather than penalized, a reaction cannot appear at a slaved DOF — restraints applied to a slaved direction on the slave joint are effectively superseded by the master's. If you need the restraint, apply it to the master. **Chaining is supported.** A slave may itself act as another constraint's master: the solver resolves the tie set iteratively to a fixed point, so chained equal constraints come out the same regardless of the order they were defined in. You do not need to flatten a chain by hand. What is *not* safe is mixing mechanisms — tying a joint that is **also** a slave of a Rigid Diaphragm in the same direction. The two express different relationships (a coefficient-one tie versus a lever-arm transform), they cannot both hold, and the outcome depends on which is applied last. The program warns when it detects that combination; resolve it rather than ignoring it. **Group:** The activation group used for construction-stage and group filtering. This is a **selection** parameter: it decides *when* the constraint exists, not what it does. If the group is inactive in a given stage, the tie is not applied for that stage and the two joints move independently. Leave it empty for a constraint that should always be active. Define together with the staging scheme; a splice that is only made continuous after erection is modelled by assigning the constraint to the group activated at that stage. Verify by comparing displacements at the two joints stage by stage — they should diverge before activation and coincide after. ## Constrained DOFs Each of the six switches turns the tie on for one direction. They are independent, and **all six default to NO** — a constraint with no direction switched on is created successfully but does nothing at all. Directions are in **global** axes, not the local axes of any element. **Tie Tx:** Ties translation along global X. When YES, `Ux_slave = Ux_master`. **Tie Ty:** Ties translation along global Y. **Tie Tz:** Ties translation along global Z. **Tie Rx:** Ties rotation about global X. **Tie Ry:** Ties rotation about global Y. **Tie Rz:** Ties rotation about global Z. *Engineering influence, common to all six.* Switching a direction ON removes one equation from the system, which makes the structure **stiffer or equally stiff in that direction — never softer**. The effect on any particular result depends on whether the two joints wanted to move differently there: tying a direction in which they were already moving together changes nothing measurable. A value of NO means the direction is simply not tied; it does **not** mean "free to slide" in any special sense — it means no relationship is imposed at all. There is no negative or intermediate value; this is a yes/no switch, not a stiffness, so partial fixity cannot be expressed here (use a spring or a partial-fixity release for that). Tying **rotations** is the switch most often set incorrectly. A moment-transferring connection needs the relevant rotations tied; a true pin must leave them NO. Tying all six is a full weld and will carry moment across a joint you may have intended to be released. Over-constraining is the main hazard: tying directions that are already restrained elsewhere, or tying two joints that are also connected by stiff elements, creates redundant relationships that can leave the system with orphaned equations or produce reactions that do not sum as expected. Under extreme over-constraint the solver may report a singular or ill-conditioned system. These switches do not affect mass, do not generate loads, and are ignored entirely in a direction where the model has no such DOF — for example rotational ties on a model built purely from truss elements. ## Verification * Compare displacements at the master and slave joints in each tied direction; they must be identical to solver precision. A difference means the constraint is inactive, filtered out by its group, or the direction is not actually switched on. * Confirm directions you left as NO show genuinely different displacements — if they match too, the joints are tied by something else (coincident-node merging, a stiff element, or a second constraint). * Check reactions: a slaved direction on the slave joint should not carry a reaction. * Review the constraint warnings after analysis; a joint constrained by both an Equal Constraint and a Rigid Diaphragm in the same direction is flagged. * Step through construction stages and confirm the tie appears only in the stages where its group is active. * For a simple two-joint model, hand-check that the tied assembly behaves as a single joint. ## Common mistakes * **Creating the constraint but leaving every direction NO.** The object exists, the sheet shows a row, and nothing is tied. This is the single most common cause of "my constraint did nothing". * **Expecting rigid-body rotation.** An Equal Constraint has no lever arm. Tying Tx, Ty and Rz on a set of deck joints does *not* make the deck a rigid diaphragm — the translations are forced equal everywhere instead of varying with distance from the master. Use Rigid Diaphragms. * **Restraining the slave joint** in a direction that is slaved. The restraint has no effect because the equation belongs to the master. * **Tying all six directions to "make it simple"**, converting an intended pin or expansion joint into a moment-and-axial-carrying weld, which redistributes forces across the whole structure. * **Tying joints that are far apart.** The constraint is geometric-distance-blind: it will happily force two joints metres apart to have identical displacement, which is almost never intended and produces a stiff, unrealistic model with no warning. * **Using it where a release or a spring was wanted.** Constraints are all-or-nothing; partial fixity belongs in the element's end releases or a spring. # Rigid Diaphragms \[FEA] A Rigid Diaphragm constrains a set of joints so that they translate and rotate together as one rigid body **within a plane**. Every slave joint's in-plane degrees of freedom are tied to the master joint's in-plane degrees of freedom **through a lever arm**, so a rotation of the master produces translations at the slaves proportional to their distance from it. For the default XY plane: ``` Ux_slave = Ux_master − (Y_slave − Y_master) · Rz_master Uy_slave = Uy_master + (X_slave − X_master) · Rz_master Rz_slave = Rz_master ``` The out-of-plane degrees of freedom are left **free**: an in-plane diaphragm couples only the two in-plane translations and the in-plane rotation. A deck constrained as an XY diaphragm can still deflect vertically and rotate about the horizontal axes exactly as it did before. This is the standard idealization for a concrete deck or slab that is very stiff in its own plane compared with the elements below it. Its purpose is usually to distribute lateral load to substructure elements in proportion to their stiffness, and to collapse many in-plane deck DOFs into three — which also makes seismic and lateral models much smaller and better conditioned. Rigid Diaphragms affect **connectivity and the stiffness matrix**. They add no stiffness, mass or load of their own; they eliminate equations by expressing them as weighted sums of the master's. {% hint style="info" %} **Rigid Diaphragm vs. Equal Constraint.** Use a Rigid Diaphragm when the constrained set must rotate as a body — translations must vary with distance from the master. Use an **Equal Constraint** when two joints must simply share the same value of a DOF with no lever arm. A Rigid Diaphragm is not a substitute for a moment connection between two coincident joints. {% endhint %} ## Geometry **Master Node:** The reference joint whose in-plane degrees of freedom are **retained** — commonly placed at the diaphragm's centre of mass for dynamic work, since the mass and the lateral response are reported there. This is a **connectivity** parameter and it defines the origin of every lever arm, so **moving the master changes the constraint equations** even if the slave set is unchanged. The master does not need to be attached to any element: the program adds master and slave joints to the equation system explicitly, so a free-standing centre-of-mass joint carrying only a Nodal Mass is a valid and common master. Place it deliberately — a master at an arbitrary corner still gives correct rigid-body behaviour, but modal results and reported diaphragm displacements are then referenced to that corner rather than the centre of mass. **Slave Node Group:** An FE Group containing the joints whose in-plane degrees of freedom are **eliminated**. This is the normal way to define a diaphragm — collect the deck joints into a group and point at it. Only joints in the group are constrained; anything you forget to add keeps its own in-plane freedom and will deform out of the rigid plane, usually showing up as a local mode. Define together with the Master Node and the Plane. Verify by displaying the group and confirming it contains every joint that should be part of the diaphragm. **Single Slave Node:** An optional single slave joint, for the convenience of a one-slave diaphragm where creating a group would be overhead. It is **additive** — if both this and Slave Node Group are set, the constrained set is the group plus this joint (duplicates are ignored). Leave it empty when using a group. **Group:** The activation group used for construction-stage and group filtering. This is a **selection** parameter that decides *when* the diaphragm exists, not what it does. A deck that only becomes composite and diaphragm-like after the slab cures is modelled by assigning the constraint to the group activated at that stage; before it, the joints move independently. Leave empty for a diaphragm that is always active. Note this is a different field from **Slave Node Group** — this one filters the constraint's activation, that one lists the joints being constrained. Confusing the two is easy and produces either a diaphragm that constrains nothing or one that never activates. ## Settings **Diaphragm Plane:** Selects which plane the rigid body acts in, and therefore which three DOFs are constrained and which three stay free. | Value | Plane | Normal | Constrained | Left free | | ---------------- | ---------- | ------ | ----------- | ---------- | | **XY** (default) | horizontal | Z | Ux, Uy, Rz | Uz, Rx, Ry | | **YZ** | | X | Uy, Uz, Rx | Ux, Ry, Rz | | **XZ** | | Y | Ux, Uz, Ry | Uy, Rx, Rz | {% hint style="warning" %} **Re-check this field on any diaphragm created before this parameter became an enumeration.** In the earlier declaration the option list was inverted, so selecting YZ or XZ stored a value the getter did not recognise and silently fell back to **XY** — an in-plane diaphragm in the wrong plane, with no warning. Models saved under that declaration still open (the legacy text is read correctly now), but a YZ or XZ choice made then may never have taken effect. Confirm the plane and re-check the deformed shape. {% endhint %} *Engineering influence.* XY is correct for an ordinary bridge deck or building floor in the default orientation, where Z is vertical. Choosing the wrong plane is not a subtle error: it rigidly ties the *vertical* behaviour of the deck and leaves the lateral behaviour free, which typically makes the structure far too stiff vertically and too flexible laterally, and produces mode shapes that are obviously wrong. This parameter depends entirely on the model's global axis orientation — if the model was built with Y vertical, the appropriate plane changes accordingly. The parameter is an enumeration; there is no partial or blended plane. It does not affect mass, loads, or out-of-plane stiffness. ## Verification * Display the deformed shape under a lateral load. The diaphragm's joints should show a rigid-body pattern in plan — straight lines stay straight, and translations vary linearly with distance from the master. Any joint bulging out of that pattern was left out of the slave group. * Confirm the out-of-plane behaviour is **unchanged** from the unconstrained model. Vertical deflections under gravity should be essentially the same; if gravity deflections collapse, the Plane is wrong. * Check that the number of joints you expected is actually constrained by reviewing the slave group's object count. * Review reactions: lateral load should distribute to the substructure in proportion to stiffness. A single element taking nearly all of it usually means the diaphragm is not active. * Run a modal analysis: the lateral modes should show the deck moving as a unit, and the many local in-plane deck modes present in the unconstrained model should disappear. * Check the post-analysis warnings for joints constrained by both a diaphragm and an Equal Constraint. * Step through construction stages and confirm the diaphragm appears only where its activation group is active. ## Common mistakes * **Confusing Slave Node Group with Group.** The first defines the diaphragm; the second controls when it is active. Swapping them silently produces a diaphragm that constrains nothing. * **Choosing the wrong Diaphragm Plane** for the model's axis orientation — rigidly tying vertical behaviour instead of in-plane behaviour. * **Expecting the diaphragm to carry vertical load or provide out-of-plane stiffness.** It does not; out-of-plane DOFs are untouched by design. A deck that also needs bending stiffness still needs elements. * **Putting the master at an arbitrary joint** and then reading "the diaphragm displacement" from it in a dynamic analysis, where the centre of mass was intended. * **Including joints that should not be rigid** — for example expansion-joint joints on both sides of a gap, which then cannot open. * **Using a diaphragm where the deck is not actually rigid in plane**, such as a long, narrow, or precast deck with weak transverse connectivity. The idealization forces a distribution of lateral load that the real structure does not achieve, and the error is unconservative for the stiff elements it is supposed to protect. * **Overlapping diaphragms** that share slave joints, where the joint ends up governed by whichever constraint is processed last. # Tendons \[FEA] A Tendon defines a prestressing strand group or bar — its path through the concrete, its material and friction properties, and the force it is jacked to. From these the program computes the force profile along the tendon after friction, wobble and anchor-set losses, and applies the resulting equivalent loads to the structure. A Tendon is **load-generating** and **geometry-defining**. It does not add its own stiffness element to the model; the prestress reaches the structure as an equivalent load system distributed onto the nodes or lines you nominate. {% hint style="info" %} Right-click any cell for **Prestressing Details…**, which displays the full computed force profile along the tendon including every friction and anchor-set loss. That dialog is the primary verification tool for this object — it turns the parameters below into the number the structure actually receives. {% endhint %} ## Geometry **Path Variation:** The tendon's profile through the member — the shape the strand follows between its anchorages. Right-click for **Path Points…** to edit control points along the profile, or **Path Equation…** to define it with an expression. *Engineering influence.* The profile is what makes prestressing work: the **curvature** of the tendon, combined with its force, produces the upward equivalent load that balances applied load, and the **eccentricity** relative to the section centroid produces the moment. A tendon draped low at midspan and high over supports generates hogging where it is needed; a straight tendon at the centroid generates axial compression and no balancing load at all. Changing the profile changes both the equivalent load pattern and the friction losses, because friction accumulates with the total angle turned. Define together with the start/end stations and offsets, which anchor the profile in space. Verify by displaying the tendon in 3D and confirming the drape looks like the design drawing. **Start Station / End Station:** The stations along the alignment where the tendon begins and ends. These place the tendon longitudinally, define its length, and therefore determine which members it prestresses. *Engineering influence.* A tendon that stops short of its intended anchorage leaves the end region unprestressed — usually visible as tension at a location the design assumed was in compression. Stations also determine which construction stage the tendon can be stressed in, since the members it crosses must exist by then. **Start Offset / End Offset:** Transverse offsets from the alignment at each end. Used to place a tendon in the correct web or at the correct transverse position in a wide deck. *Engineering influence.* Transverse position controls the **transverse** distribution of prestress. A tendon offset into one web prestresses that web and produces transverse moment across the deck; the effect is missed entirely if all tendons are modelled on the centreline. **Start Elevation / End Elevation:** Vertical offsets at each end, which together with the path variation set the tendon's eccentricity relative to the section centroid. *Engineering influence.* This is the single most influential geometric quantity for a prestressed member. Eccentricity multiplies the tendon force into a moment, so a small error in elevation produces a proportional error in the balancing moment. The sign matters: a tendon below the centroid produces hogging (upward) camber and relieves sagging moment; above it, the reverse. An elevation error that flips the eccentricity reverses the prestress moment entirely while still reporting a plausible tendon force. **Rotation:** Rotation angle of the tendon about its own axis, for profiles whose orientation matters. **FEGroup (Load Dist. Elems):** The group of elements the equivalent prestress load is distributed onto. This is a **connectivity** parameter and it decides *what receives the prestress*. *Engineering influence.* If the group omits members the tendon physically passes through, those members receive no prestress and will appear under-compressed. If it includes members the tendon does not cross, prestress is applied where it does not exist. This is the most common reason a correctly-defined tendon produces the wrong force distribution. **Load Dist. Elem. Type:** Whether the load is distributed onto **FENodes** (0) or **FELines** (1). *Engineering influence.* Node distribution applies discrete equivalent forces at joints; line distribution applies the equivalent load along members. Line distribution generally gives a smoother and more realistic force profile in a beam model, while node distribution suits a model whose prestressed region is represented by joints. Choosing the type that does not match how the region is meshed produces local disturbances at the application points rather than a smooth prestress field. ## Properties **Material:** The prestressing steel. Supplies the modulus used to convert strain to force and the relaxation properties used in time-dependent analysis. **Prestressing Type:** Pre-tension (0) or Post-tension (1). *Engineering influence.* This is a fundamental behavioural switch, not a label. **Pre-tensioned** strands are stressed against an external bed before the concrete is cast, so there is no duct friction and the force transfers by bond over a transfer length. **Post-tensioned** tendons are stressed after the concrete has gained strength, against the member itself, and therefore lose force to duct friction and anchor set. Selecting pre-tension makes the friction and wobble coefficients below irrelevant; selecting post-tension makes them decisive. **Post-tension Type:** Bonded or Unbonded. Only meaningful for post-tensioned tendons. *Engineering influence.* A **bonded** tendon is grouted, so it strains compatibly with the adjacent concrete and its stress increases locally as the member is loaded; a section analysis can treat it as part of the section. An **unbonded** tendon strains over its whole free length, so its stress rises much less under load, and its ultimate-strength contribution is correspondingly lower. Choosing bonded for an unbonded tendon overstates flexural capacity. **Exposure:** Internal (0) or External (1) to the concrete section. *Engineering influence.* External tendons sit outside the concrete and are connected only at deviators and anchorages, so their eccentricity does not follow the section as it deflects and they are treated as unbonded. Internal tendons follow the section. **Anchor Set Length:** The slip that occurs at the anchorage when the jack is released and the wedges seat, in length units. *Engineering influence.* Anchor set removes force from the tendon **near the stressing end**, over a length that depends on the friction present — high friction confines the loss to a short zone, low friction spreads it further. Increasing it reduces the effective prestress near the anchorage, and on a short tendon the loss can extend over its whole length and reduce force everywhere. A value of zero means no seating loss, which is unrealistic for a wedge anchorage; typical values are a few millimetres and are supplied by the anchorage manufacturer. This parameter is ignored for pre-tensioned strands. **Wobble Friction Coefficient:** Friction arising from unintentional deviation of the duct from its theoretical profile, per unit length. *Engineering influence.* Wobble loss accumulates with **length**, so it dominates on long, nominally straight tendons. Increasing it reduces the force reaching the far end. Setting it to zero models a perfectly-placed duct and overstates the force delivered at the dead end — a non-conservative assumption for the region furthest from the jack. It is ignored for pre-tensioned strands. **Curvature Friction Coefficient (1/rad):** Friction between the strand and the duct as the tendon turns, per radian of angle change. *Engineering influence.* Curvature loss accumulates with **total angle turned**, so it dominates on sharply draped or reverse-curved profiles. Increasing it reduces the force reaching the far end, and the effect compounds with the profile: making a tendon more sharply draped increases the balancing load per unit force but also increases the friction loss, so the two partly cancel. Zero models a frictionless duct. Ignored for pre-tensioned strands. Results sensitive to both friction coefficients: the force profile along the tendon, and therefore the distribution of prestress moment along the member. They do not change the jacking force itself, only what survives at each point. ## Jacking **# of Strands:** The number of strands in the tendon. **Strand Area:** The cross-sectional area of one strand. *Engineering influence, both together.* Their product is the tendon's steel area, which converts the jacking force into a stress and governs how much force the tendon can carry. Increasing either increases the available force and the axial stiffness the tendon contributes in a bonded section analysis. An inconsistent pair — total area entered as the strand area, with the count also set — overstates the steel by the count factor, which shows up as an implausibly low stress at jacking. **Jacking Method:** Where the tendon is stressed from — Start, End, Start then End, or End then Start. *Engineering influence.* Friction loss accumulates **away from the jacking end**, so the force profile is highest at the jack and falls along the tendon. Stressing from one end produces an asymmetric profile; stressing from both ends produces a symmetric profile with the minimum near midlength and substantially higher force at the far end than one-end stressing achieves. For long tendons this choice materially changes the prestress delivered to the middle of the member. The order in "Start then End" matters only in combination with anchor set, which is applied as each end is released. **Start Jacking Force / End Jacking Force:** The force applied at each end. *Engineering influence.* These set the magnitude of everything the tendon does — the balancing load, the axial compression, and the prestress moment all scale with them. Only the force at an end actually jacked is used, so entering a force at the End while jacking only from the Start has no effect. Force is usually limited by code to a fraction of the strand's ultimate strength; entering an unrealistically high value produces a model that satisfies equilibrium but a tendon that could not be stressed in practice. A value of zero produces no prestress at all — the most common reason a tendon appears to do nothing. ## Verification * Open **Prestressing Details…** and read the computed force profile. Confirm the force at the jacking end matches what you entered, that it decays in the right direction, and that the anchor-set dip is where you expect. * Check the member's camber under prestress alone. An upward deflection confirms the eccentricity sign is right; downward usually means the tendon is on the wrong side of the centroid. * Confirm the concrete is in compression where the design intends, particularly at the extreme fibre at midspan and over supports. * Display the tendon in 3D and compare its drape against the drawing. * Check that every member the tendon crosses is in the load-distribution group. * Compare the equivalent balancing load against a hand calculation: for a parabolic profile, `w = 8·P·e/L²`. * Run with friction coefficients set to zero and compare; the difference is the total friction loss, which should be a plausible percentage of the jacking force. * In a staged model, confirm the tendon is stressed in the intended stage and that its force carries forward correctly. ## Common mistakes * **Zero jacking force**, so the tendon exists geometrically and prestresses nothing. * **Eccentricity sign reversed**, producing prestress moment in the wrong direction while the tendon force itself looks correct. * **Omitting members from the load-distribution group**, leaving parts of the member unprestressed. * **Leaving friction and wobble at zero for a post-tensioned tendon**, overstating force at the dead end. * **Selecting Bonded for an unbonded tendon**, overstating ultimate flexural capacity. * **Entering the total strand area as the Strand Area** while also setting the strand count, multiplying the steel area by the count. * **Stressing from one end on a long tendon** and not checking the force that survives at the far end. * **Stressing the tendon in a stage before the concrete it acts on exists**, or before it has gained the strength the design assumes. # FE Groups \[FEA] An FE Group is a named collection of model objects — nodes, lines, surfaces, volumes, springs. Groups are how you refer to a set of things repeatedly without listing them: activating part of the structure in a construction stage, nominating the slave joints of a rigid diaphragm, filtering which elements a load applies to, and selecting what to extract results for. Groups are **selection** objects. They add no stiffness, no mass and no load, and a group by itself changes no analysis result. What they change is which objects other parameters act on — which makes them indirectly one of the most consequential objects in the model, because a wrong group silently redirects a load, a constraint, or a whole construction stage. Groups can be nested, so a hierarchy such as *Superstructure → Girder 1 → Girder 1 Web* can be addressed at whatever level a given operation needs. ## Data **Parent Group:** The group this one belongs to, establishing the hierarchy. *Engineering influence.* Selecting a parent group includes the contents of all its descendants. This is what makes staging manageable — activating "Superstructure" activates every girder beneath it — but it also means a change deep in the tree propagates upward into every operation that referenced an ancestor. Before adding a group under a parent, check what already references that parent: adding "Temporary Falsework" under "Superstructure" will silently include the falsework in every stage, load and constraint that named the superstructure. A group with no parent is a root group. Circular parent relationships are meaningless and should be avoided; the hierarchy is intended to be a tree. **Alignment:** Associates the group with a roadway alignment, so its members can be addressed by station and offset and so alignment-based computations apply to them. Leave empty for a group with no alignment relationship. **# of Objects (readonly):** The count of objects currently in the group. *Engineering influence.* This is **output**, not input — a derived value that reports what the group actually resolved to. It is the single most useful field on the object for verification: a group you believe contains 48 girder elements but which reports 0, or 3, or 4800, tells you immediately that a membership rule or a filter is not doing what you assumed. Check it after any change to the model or to the group's filter, and check it before trusting any result that depends on the group. A count of 0 is the classic silent failure: every operation that references the group — stage activation, diaphragm slaves, load filters — then applies to nothing at all, without raising an error. {% hint style="warning" %} This column is derived and cannot be edited, but it is not flagged read-only in the sheet, so typing into it appears to work and the value is discarded on redraw. {% endhint %} ## Verification * Read **# of Objects** and compare it against the number you expect. This catches most group problems in one step. * Select the group in the 3D view and confirm the highlighted set is what you intended — particularly its extent at the boundaries, where an off-by-one member is easy to miss in a count. * For a nested hierarchy, check the count at each level and confirm parent counts include children. * After a staged analysis, step through the stages and confirm the structure activating at each one matches the group you assigned. * Where a group drives a rigid diaphragm, confirm the deformed shape shows every intended joint moving as part of the rigid body — a joint left out of the group will visibly deviate. * Where a group filters a load, compare the total applied load against a hand calculation of the intended area or length. ## Common mistakes * **An empty group.** Every operation referencing it silently does nothing. Nothing in the product flags this; only the object count reveals it. * **Adding a group under a parent without checking what references that parent**, quietly changing the scope of stages, loads and constraints that named the ancestor. * **Confusing a node's Group with the slave group of a rigid diaphragm**, or with the activation Group on a constraint — these are separate fields with different meanings, and swapping them produces a constraint that either constrains nothing or never activates. * **Assuming a group updates itself** after model changes without re-checking the object count. * **Building groups that overlap in staged construction**, so an element is activated twice or deactivated by one stage while another expects it present. * **Naming groups ambiguously** — several groups whose names differ only in a suffix are easy to select wrongly in a long dropdown, and the mistake is invisible afterwards. # Loads \[FEA] The Loads branch holds everything that acts on the structure, organised by the kind of action. **Static Loads** covers load cases and the loads that belong to them - nodal, line and surface loads, temperature, prestressing, and analysis overrides. **Live Loads** covers the vehicles, design lanes and influence surfaces used for traffic loading. **Wind Loads**, **Pushover** and **Dynamic Loads** each hold their own analysis case types. **Staged Construction** is different in kind: rather than a single loading condition, it defines a sequence of stages, each inheriting the deformed and stressed state of the previous one. Two things are worth knowing before working anywhere in this branch. Every load belongs to an **analysis case**, and a load with no case assigned applies nowhere, silently. And the **sign** of a load component follows the axis direction - a downward load in a Z-up model is negative. # Static Loads \[FEA] Static Loads holds the load cases and the individual loads that belong to them. **Load Cases** are the containers: each represents one loading condition, switches self-weight on through its weight factors, and chooses whether the solution is linear or nonlinear. Loads come in two families. **Element-targeted** loads name the object they act on - Nodal Loads, FE Line Loads, FE Surface Loads, Temperature Loads, Strain Loads, Cable Stressing Loads. **Global** loads are placed geometrically, by coordinate, path or polygon, and are distributed to whatever elements of a nominated group lie there - Global Point, Line and Surface Loads. The global forms survive re-meshing; the element-targeted forms are unambiguous. **Prestressing Loads** apply a tendon's force, and **Analysis Overrides** change an object's properties for one case only. The most common failure across this whole branch is silent: a load with no case assigned, a group that matches nothing, or a factor left at zero. Checking that reactions sum to the load you intended is the single most effective verification available. # Load Cases \[FEA] A Load Case is one distinct loading condition — dead load, wearing surface, a construction operation, a wind event — and it is the container every static load belongs to. Loads point at a case; the case is solved; results are reported per case and then combined. The case is also where **self-weight** is switched on and where the **solution method** (linear or nonlinear) for that condition is chosen. A Load Case does not itself apply anything to the structure except self-weight. It **generates load** through its weight factors, and it **controls the solution** through its nonlinear settings. ## Self Weight **Weight Factor X / Y / Z:** Multipliers applied to the structure's own self-weight in each global direction, computed from element volume and material density. *Engineering influence.* This is how gravity enters the model. In a model with Z vertical and downward gravity, a dead-load case normally uses **Weight Factor Z = −1**; the sign must match the model's orientation, and getting it wrong applies gravity upward, which produces a plausible-looking deflected shape in the wrong direction. A factor of **0 in every direction means no self-weight at all** in this case — the correct setting for a superimposed-load case, and the single most common reason a dead-load case reports far less load than expected. Values other than ±1 scale self-weight, which is how a load factor can be baked into the case, though it is usually cleaner to apply factors in the combination instead. Only elements that are **active** in this case contribute — see Structure Group and construction staging. Results sensitive to it: everything in a gravity-dominated structure; reactions are the quickest check. **Load Type:** Classifies what kind of load the case represents, for use by combinations and design code checks. *Engineering influence.* This is a **classification** parameter, not a physical one — it does not change the analysis. It matters because design code checks and automated combinations select cases by type, so a case classified wrongly may be omitted from a combination that should include it, or factored with the wrong partial factor. The error surfaces in design results, not in analysis results. ## Nonlinear **Nonlinear:** Whether the case is solved with a nonlinear (incremental, iterative) solution rather than a single linear solve. *Engineering influence.* This is the master switch that decides whether the model's nonlinear ingredients are actually honoured. **Gaps, one-sided springs, tension-only and compression-only members, cables and geometric (P-delta) stiffness are all ignored in a linear case** — the model is linearized and solves as if those features were ordinary linear elements. A cable-stayed or gap-supported structure analysed linearly can therefore show stays in compression and shear keys carrying tension, with no warning at all. Turning it on costs solution time and introduces convergence risk. Turn it on when the model contains nonlinear features whose behaviour matters, or when large-displacement effects are significant; leave it off for an ordinary linear structure, where it adds cost without changing the answer. Note that results from nonlinear cases cannot be superposed the way linear results can, which constrains how they may legitimately be used in combinations. **# of Steps:** The number of load increments the total load is applied in. *Engineering influence.* Applying load in more steps follows the structure's changing stiffness more closely and generally improves convergence and accuracy for a strongly nonlinear problem. A single step is fine for a mildly nonlinear case and often fails to converge for one with gapping or large displacement. Increasing steps increases run time roughly proportionally. It has no effect on a linear case. If a nonlinear case fails to converge, increasing this is usually the first thing to try. **Maximum # of Iterations:** The iteration limit within each load step. *Engineering influence.* Bounds the effort spent trying to satisfy equilibrium in a step before the solver gives up. Raising it lets a slowly-converging step succeed; it also allows a genuinely divergent problem to waste a lot of time before failing. A converged solution is not more accurate for having been given more iterations — the tolerances below define accuracy, this only defines patience. **Force Tolerance:** The out-of-balance force below which a step is accepted as converged. **Displacement Tolerance:** The displacement change below which a step is accepted as converged. *Engineering influence, both.* These define what "solved" means. Loosening them makes convergence easier and the answer less accurate — an out-of-balance force left in the model is a real force the structure never received. Tightening them improves equilibrium and may prevent convergence entirely. Set them relative to the magnitudes in your model: a force tolerance of 1 is meaningful in a model whose reactions are thousands and meaningless in one whose reactions are single digits. Both defaults are absolute values, so a model built in different units needs them reviewed. ## Settings **Structure Group:** The part of the structure active in this case. *Engineering influence.* Restricting a case to a group analyses a partial structure — a construction condition where only part of the bridge exists, or a check on a subassembly. Elements outside the group are absent, and self-weight is only generated for elements inside it. Leave empty to analyse the whole structure. A group that resolves to nothing produces a case with no structure at all. **Is Active:** Whether the case is solved. *Engineering influence.* Inactive cases are skipped silently, which is convenient for keeping a large suite of cases in one project and running a subset — and is a frequent reason a case appears to produce no results. Any combination referencing an inactive case will be missing that contribution. ## Verification * Check reactions against a hand calculation of total applied load. For a dead-load case, the vertical reaction total must equal the structure's weight. * Confirm the deflected shape points the right way; an upward dead-load deflection means the weight factor sign is wrong. * For a superimposed case, confirm the weight factors are zero so self-weight is not double-counted with the dead-load case. * Compare a nonlinear case against its linear equivalent. A large difference tells you the nonlinearity matters; no difference at all suggests the nonlinear features are not actually engaging. * For a nonlinear case, confirm it reported convergence rather than hitting the iteration limit, and check that the out-of-balance force is small relative to applied load. * Re-run with more steps and confirm the answer is stable. * Check that the case is Active and that every combination referencing it includes it. ## Common mistakes * **Weight factors left at zero in the dead-load case**, so the structure weighs nothing. * **Weight factor applied in the wrong direction or sign**, applying gravity sideways or upward. * **Self-weight switched on in more than one case**, double-counting dead load through the combinations. * **Running a model with cables, gaps or one-sided members as a linear case**, where all of those features are silently ignored. * **Loosening tolerances to force convergence** and accepting a solution with meaningful residual out-of-balance force. * **Tolerances left at their defaults in a model whose units make them meaningless** — either unreachably tight or trivially loose. * **Leaving a case inactive** and not noticing that a combination is short a contribution. * **Superposing nonlinear case results** in a combination as if they were linear. # Nodal Loads \[FEA] A Nodal Load applies a concentrated force and/or moment directly at a node. Use it for equipment weights, a reaction handed over from another model, jacking forces, and any action that genuinely acts at a point. Nodal Loads **generate load**. They add nothing to stiffness or mass. **Load Case:** The analysis case the load belongs to. A load with no case assigned is applied nowhere; it exists in the model and contributes to nothing, with no warning. Loads reach results only through their case and any combination that includes that case. **Node:** The joint the load acts at. This is a **connectivity** parameter. *Engineering influence.* A concentrated load applied at a node is exactly a point load in the mathematics of the model, so in a shell or solid mesh it produces a local stress singularity — the stress at that node rises without limit as the mesh is refined, and any stress read there is a function of mesh size rather than of the structure. Read forces a little away from the application point, or spread the load over several nodes, wherever local stress matters. For frame models this is not an issue. The node must exist in the active structure for the case; a load on a node that is inactive in the current construction stage does nothing. **Coordinate System:** Whether the components below are interpreted in **Global**, **Local**, or a **UCS** (user coordinate system). *Engineering influence.* Global is the usual choice and means the components act along the global axes regardless of the structure's orientation. Local and UCS let the load follow a skewed or superelevated geometry — a braking force along the roadway direction on a curved bridge, or a load normal to a skewed abutment. Selecting the wrong system silently rotates the load: a longitudinal braking force entered as global X on a bridge at 30° skew delivers only part of its magnitude along the road and introduces a transverse component that was never intended. **UCS:** The user coordinate system used when Coordinate System is set to UCS. Ignored otherwise. ## Forces & Moments **Fx / Fy / Fz:** Force components along each axis of the chosen coordinate system. **Mx / My / Mz:** Moment components about each axis of the chosen coordinate system. *Engineering influence, all six.* Each component is applied directly to the corresponding degree of freedom, and the response scales linearly with it in a linear analysis. **Sign follows the axis direction**, so a downward load in a model with Z up is entered as a **negative** Fz — a sign error here is the most common mistake on this object and produces an uplift case that looks superficially plausible. A component applied to a **restrained** degree of freedom goes straight into the reaction and produces no deformation at all — which is why a load applied at a support node can appear to do nothing. Similarly, a **moment applied to a node with no rotational stiffness** — a node connected only to truss elements, or only to solid elements, which have no rotational degrees of freedom — is either absorbed with no effect or makes the model singular. This is a frequent surprise when loading a solid model. A value of zero simply means no load in that component. Results sensitive to these: everything downstream of the case, most directly the reactions, which should always be checked first. ## Verification * Sum the reactions for the case and confirm they equal the total applied load in each direction. This is the single most effective check and catches sign errors, missing cases and coordinate-system mistakes at once. * Confirm the deflected shape moves in the direction you intended. * Check that the load appears in the applied-load display at the node you meant. * For a moment, confirm the node actually rotates; no rotation means the degree of freedom is restrained or has no rotational stiffness. * For a skewed or local-system load, resolve the components by hand and compare against the global reactions. * Compare against a hand calculation of the resulting support reactions for a simple span. ## Common mistakes * **Sign error on a gravity load** — entering a positive Fz in a Z-up model, applying uplift. * **No Load Case assigned**, so the load does nothing at all. * **Wrong coordinate system**, rotating the load away from the direction intended, most damagingly on skewed and curved structures. * **Applying a moment at a node with no rotational stiffness** (truss-only or solid-only connectivity), where it has no effect or destabilizes the model. * **Applying the load at a restrained node** and expecting deformation; it goes directly into the reaction. * **Reading local stress at the application point** in a shell or solid mesh, where the result is a mesh-dependent singularity. * **Applying a load at a node that is inactive** in the relevant construction stage. # Nodal Disp. Loads \[FEA] A Nodal Displacement Load imposes a **prescribed movement** at a node rather than a force. Use it for support settlement, jacking a bearing to a known lift, an imposed deformation at a boundary, or any condition where the displacement is known and the force required to cause it is the unknown. This is the inverse of a Nodal Load: a force load asks "what movement results from this force?", a displacement load asks "what force is needed to produce this movement?". Nodal Displacement Loads **generate load**. They add nothing to stiffness or mass. {% hint style="warning" %} **The degree of freedom must be restrained for the prescribed displacement to mean anything.** A prescribed movement is enforced through the support at that node; on a **free** degree of freedom there is nothing to push against, and the imposed value is either ignored or produces a rigid-body movement rather than the intended settlement. Check the node's DOF settings before entering values here. {% endhint %} **Load Case:** The analysis case the imposed displacement belongs to. With no case assigned it applies nowhere. *Engineering influence.* Settlement is normally kept in its own case so it can be combined at the factor the code requires, and so its effects can be examined separately — settlement effects are often a significant fraction of design moments in continuous structures and need to be visible. **Node:** The joint the displacement is imposed at, normally a support node. ## Displacements **Tx / Ty / Tz:** Prescribed translations along each global axis. **Rx / Ry / Rz:** Prescribed rotations about each global axis. *Engineering influence, all six.* The response is driven entirely by the **restraint the movement is imposed against**. In a **statically determinate** structure a support settlement produces movement but **no internal force at all** — a simply supported span whose abutment settles simply tilts. In a **redundant** structure the same settlement forces the structure to deform out of its natural shape, generating large internal moments and shears and redistributing reactions between supports. This is why differential settlement matters enormously in continuous bridges and not at all in simple spans, and it is the most important thing to understand about this object. The forces generated scale with the structure's stiffness as well as the settlement, so a stiffer structure attracts **more** force from the same imposed movement. Anything that softens the structure — cracked-section factors, creep — reduces settlement effects, which is why codes often permit long-term settlement to be assessed with reduced stiffness. Sign follows the global axis directions: a downward settlement in a Z-up model is a **negative** Tz. A value of zero means no imposed movement in that component — not "free". **Differential** settlement is what generates force; imposing the same settlement at every support translates the whole structure rigidly and generates nothing. Cases are therefore normally set up to settle one support, or a subset, at a time, and the envelope of those cases is what governs design. Results sensitive to these: support reactions (which redistribute markedly), moments over interior supports, and bearing and joint movements. ## Verification * Check that the node actually moves by the amount you prescribed. If it does not, the degree of freedom is unrestrained and the load is not being enforced. * Check the reactions: settling one support of a continuous beam should **reduce** its reaction and increase the adjacent ones, summing to the same total. * Confirm that in a determinate structure the same settlement produces essentially zero internal force — a useful sanity check on both the model and your expectations. * Compare the moment induced over an interior support against a hand calculation for a two-span beam with a known central settlement. * Confirm settlement is applied differentially rather than uniformly, unless a rigid movement is genuinely intended. * Check the sign by looking at the deflected shape. ## Common mistakes * **Imposing a displacement on an unrestrained degree of freedom**, where it cannot be enforced. * **Sign error**, settling a support upward. * **Applying the same settlement at every support**, which produces a rigid-body movement and no internal force — and then concluding settlement does not affect the structure. * **Combining settlement with full uncracked stiffness** where the code expects a reduced long-term stiffness, overstating the induced forces. * **Putting settlement in the dead-load case** rather than its own, so it cannot be factored separately or examined on its own. * **Expecting a determinate structure to develop force** from settlement. * **Forgetting to envelope** the individual support-settlement cases, and checking only the all-supports-settle condition, which is the least onerous. # FE Line Loads \[FEA] An FE Line Load applies a load **to a line element** rather than to a node: a point load or moment at a position along the member, or a distributed load varying linearly between two positions. The program converts it into equivalent nodal forces and fixed-end moments during assembly. Applying load to the element rather than to nodes is what allows a load to sit **between** nodes, and it produces the correct fixed-end moments without requiring a node at the load position. FE Line Loads **generate load**. They add nothing to stiffness or mass. **Load Case:** The analysis case the load belongs to. With no case assigned it applies nowhere. **Element:** The FE Line, or group of lines, the load acts on. This is a **connectivity** parameter. Pointing at a group applies the load to every member in it — convenient for a deck-wide superimposed load, and a common source of over-application when the group is broader than intended. **System:** Whether the direction below is interpreted in the element's **local** axes or in **global** axes. *Engineering influence.* This is the parameter that most often goes wrong on sloped and curved members. A **global** load acts in a fixed world direction regardless of member orientation — correct for gravity-type loads such as a wearing surface, whose magnitude per unit length is measured along the member. A **local** load follows the member, so it stays perpendicular to a sloped girder — correct for pressure-type loads such as wind on a face. On an inclined member the two differ by the slope angle, and a superimposed dead load entered in local axes on a sloped girder is both reduced and given a spurious axial component. **Direction:** Which axis of the chosen system the load acts along. *Engineering influence.* Combined with the sign of the magnitude, this sets where the load actually goes. A downward load in a Z-up model with a global system is a **negative** magnitude in the Z direction. Note the load is applied **per unit length of the member**, not per unit horizontal projection: on a sloped member, a load defined per horizontal metre must be converted before entry, or the total applied will exceed the intended value by the ratio of member length to horizontal span. ## Point Load **Point Force Magnitude:** A concentrated force applied at a position along the member. **Point Moment Magnitude:** A concentrated moment applied at a position along the member. **Point Load Location (x/L):** The position, as a **fraction of member length** from Node 1 — 0 at the start, 0.5 at midspan, 1 at the end. *Engineering influence.* Because the position is a fraction rather than an absolute distance, it **follows the member if the geometry changes** — useful for parametric models, and a trap if you intended a fixed physical location. A value outside the range 0 to 1 places the load off the member. Position governs the response: a point load at midspan produces the maximum sagging moment, while the same load near a support produces mostly shear and little moment. For a concentrated moment, the position determines where the step in the moment diagram occurs. Both are applied exactly, without needing a node there. ## Linear Load **Force Magnitude at Start / Force Magnitude at End:** Distributed force intensity, in force per unit length, at the start and end of the loaded region. **Moment Magnitude at Start / Moment Magnitude at End:** Distributed moment intensity, in moment per unit length, at each end of the loaded region. **Linear Load Start Location (x/L) / Linear Load End Location (x/L):** The extent of the loaded region, as fractions of member length. *Engineering influence.* Setting start and end magnitudes **equal** gives a uniform load; setting them different gives a linearly varying (trapezoidal or triangular) load — the natural way to model a tapering superimposed load, a soil pressure varying with depth, or a load that ramps across a member. Setting one to zero gives a triangular distribution. The **locations** define a partial-length load. Leaving both at their defaults (0 and 0) applies the load over zero length and therefore applies **nothing** — a load that has been entered with magnitudes but no extent does nothing at all, silently. To load the full member, the end location must be 1. Total applied load is the average intensity times the loaded length, so both the magnitudes and the extent must be right for the total to be right; checking reactions is the only reliable confirmation. Results sensitive to these: span moments and shears, and — because a distributed load produces different fixed-end moments than an equivalent point load — the moment distribution in a continuous structure. ## Verification * Sum the case's reactions and compare against the total applied load computed by hand: average intensity × loaded length. This catches location errors, unit slips and the zero-extent trap in one step. * Display the applied loads and confirm the arrows are on the right members, pointing the right way, and covering the intended extent. * Compare a simply supported span's midspan moment against `wL²/8` for a uniform load, or `PL/4` for a central point load. * For a sloped member, confirm the total load matches what you intended per unit length along the member, not per horizontal metre. * Check that a local-system load stays perpendicular to a sloped member and a global-system load does not, by inspecting the load display. * Confirm a partial-length load starts and ends where you meant, remembering the values are fractions. ## Common mistakes * **Leaving the linear load locations at 0 and 0**, applying the load over zero length so nothing happens. * **Sign error**, applying a gravity load upward. * **Confusing local and global systems on a sloped member**, changing both the magnitude delivered and the direction. * **Entering a load defined per horizontal metre** on a sloped member without converting to per-metre along the member. * **Assuming x/L is a distance.** It is a fraction; entering 5 for "5 metres from the start" places the load well off the member. * **Applying to a group** that contains more members than intended, multiplying the total load. * **No Load Case assigned**, so the load does nothing. * **Expecting the load position to stay fixed** when the model geometry is parametric — the fraction moves with the member. # FE Surface Loads \[FEA] An FE Surface Load applies load **to a shell element** — either a uniform pressure over the whole element face, or a concentrated force or moment at a position within it. The program converts it into equivalent nodal forces during assembly. Use it for deck surfacing, water or earth pressure, snow, and any distributed action over an area, as well as for a wheel or bearing load that lands inside an element rather than at a node. FE Surface Loads **generate load**. They add nothing to stiffness or mass. **Load Case:** The analysis case the load belongs to. With no case assigned it applies nowhere. **Element:** The FE Surface, or group of surfaces, the load acts on. This is a **connectivity** parameter, and for a distributed pressure it is normally a group covering the whole loaded area. *Engineering influence.* The total load applied is the pressure times the **summed area of the elements in the group** — so the extent of the group is exactly as important as the pressure value. A group that misses a strip of deck under-applies the load; one that extends past the loaded region over-applies it. Neither is flagged. **System:** Whether Direction is interpreted in the element's **local** axes or in **global** axes. *Engineering influence.* A **local** direction follows the shell, so a pressure stays normal to the surface as it slopes or curves — correct for water pressure, earth pressure, and wind on a face. A **global** direction is fixed in world axes — correct for gravity-type loads such as surfacing weight, whose intensity is measured per unit of plan area. On a sloped or curved deck the difference is significant: a surfacing load entered as a local (normal) pressure is reduced by the cosine of the slope and gains an in-plane component. **Direction:** Which axis of the chosen system the load acts along. Combined with the sign of the magnitude, this sets where the load goes; a downward load in a Z-up model with a global system is a **negative** value. ## Point Load **Uniform Force Magnitude:** A uniform pressure over the element face, in force per unit area. *Engineering influence.* This is the main way area loads enter the model. The total force delivered is pressure × element area, so the value scales the response linearly. Note it is applied per unit of the **element's own area**, not per unit plan area, so on a sloped deck a pressure derived from a plan quantity must be converted first. The uniform-load lumping is translation-only, which is worth knowing when triangles are involved: the ANDeS triangle formulation is inconsistent under distributed load and its error grows under mesh refinement, so distributed loads on triangular elements should use the default DKGT formulation. Increasing pressure increases deflection and moment proportionally in a linear analysis. A value of zero applies nothing. **Point Force Magnitude:** A concentrated force applied at a position inside the element. **Point Moment Magnitude:** A concentrated moment applied at a position inside the element. **X Coord. (in elem. local) / Y Coord. (in elem. local):** The position of the concentrated load, in the element's **local** coordinates. *Engineering influence.* These let a wheel load or a bearing reaction be placed accurately without putting a node there. The coordinates are local to the element, so they depend on the element's node ordering and orientation — a position that is correct on one element is not the same physical point on its neighbour if the local axes differ. Check local axes before relying on a precise position. A concentrated load on a shell produces a local **stress singularity**: the stress directly under it grows without bound as the mesh is refined, so any stress read at that point reflects mesh size rather than the structure. Read stresses a short distance away, or spread the load, whenever local stress matters. Global response — deflection, reactions, overall moment — is unaffected by this and remains reliable. ## Verification * Sum the case's reactions and compare against pressure × total loaded area computed by hand. This is the definitive check and catches group-extent errors, which are the most common problem here. * Display the applied loads and confirm the loaded region matches the intended area, with no gaps or overlaps at its boundary. * Confirm the direction: a pressure entered as local should be visibly normal to a sloped surface, a global one visibly vertical. * Compare a uniformly loaded simply supported plate against the closed-form deflection. * For a concentrated load, confirm its position by inspection rather than trusting the local coordinates, and check that reported stresses stabilize away from the application point. * Refine the mesh and confirm the global response is unchanged; if it moves, the mesh rather than the load is governing. ## Common mistakes * **A group that does not cover the intended area**, silently under- or over-applying the total load. * **Sign error**, applying pressure upward. * **Confusing local (normal) with global (vertical) pressure** on a sloped or curved deck, changing both magnitude and direction. * **Using a plan-area pressure on a sloped deck** without converting to the element's own area. * **Reading peak stress directly under a concentrated load** and treating a mesh-dependent singularity as a real result. * **Placing a concentrated load by local coordinates** without checking the element's local axes. * **Applying distributed load to ANDeS triangles**, where the lumping is inconsistent and refinement makes it worse. * **No Load Case assigned**, so the load does nothing. # Global Point Loads \[FEA] A Global Point Load applies a concentrated force or moment at a **coordinate location** rather than at a named node. The program finds the elements in the nominated group nearest that location and distributes the load onto them. This is the load to use when you know *where* something acts but not *which* element is there — a piece of equipment at a surveyed position, a load whose position is driven by a parameter, or a load that must stay put while the mesh around it changes. Global Point Loads **generate load**. They add nothing to stiffness or mass. {% hint style="info" %} **Compared with a Nodal Load:** a Nodal Load targets a node by name and is exact. A Global Point Load targets a position and is resolved against the model at solve time. The Global form survives re-meshing and geometry changes; the nodal form is unambiguous. Prefer the nodal form when a suitable node exists and the geometry is stable. {% endhint %} ## Point Load **Load Case:** The analysis case the load belongs to. With no case assigned it applies nowhere. **Group:** The FE Group searched for elements to receive the load. This is a **connectivity** parameter and it is the critical one on this object. *Engineering influence.* The load is distributed onto elements **within this group**. If the group does not contain anything near the specified location, the load has nowhere to go and is silently lost — the model solves, and the load simply is not there. If the group contains more than you expect, the load may land on the wrong member. Because there is no error for either case, checking reactions against the applied total is the only reliable confirmation. **Location X / Y / Z:** The coordinates the load acts at. *Engineering influence.* These place the load in space. A location that does not coincide with the structure — outside the deck, above or below it, or beyond the end of a girder — leaves the load unattached, and it disappears. When the model geometry is parametric, remember these are absolute coordinates and do **not** follow the structure unless they are driven by the same parameters. Position governs the response in the usual way: near a support the load produces shear, near midspan it produces moment. **Coordinate System:** Whether the force and moment components below are interpreted in **Global**, **Local**, or a **UCS**. **UCS:** The user coordinate system used when Coordinate System is set to UCS. Ignored otherwise. *Engineering influence.* As with nodal loads, selecting the wrong system rotates the load. A longitudinal force on a skewed or curved structure entered in global axes delivers only part of its magnitude along the intended direction and introduces a transverse component. **Fx / Fy / Fz:** Force components. **Mx / My / Mz:** Moment components. *Engineering influence.* Each acts on the corresponding degree of freedom of whatever the load is distributed to, scaling the response linearly in a linear analysis. **Sign follows the axis direction**, so a downward force in a Z-up model is a **negative** Fz. A moment applied to a region represented only by truss or solid elements has no rotational degree of freedom to act on, and will either have no effect or destabilize the model. A value of zero applies nothing in that component. ## Verification * Sum the case's reactions and compare against the total force entered. A shortfall means the load did not find anything to attach to — the usual cause is a location outside the group's elements. * Display applied loads and confirm the arrow appears at the intended position, on the intended member. * Confirm the load moved to the right place after any geometry change; absolute coordinates do not follow a parametric model. * Check the sign by inspecting the deflected shape. * For a local or UCS load, resolve the components by hand and compare against global reactions. ## Common mistakes * **A location that misses the group's elements**, so the load is silently lost. This is the characteristic failure of this object and it produces no warning at all. * **A group narrower than the region the load should reach.** * **Sign error**, applying a gravity load upward. * **Assuming the location follows a parametric model.** It does not unless driven by the same parameters. * **Using a Global Point Load where a Nodal Load would be unambiguous**, introducing avoidable uncertainty about where the load landed. * **Wrong coordinate system** on a skewed or curved structure. * **No Load Case assigned**, so the load does nothing. # Global Line Load \[FEA] A Global Line Load applies a distributed force or moment along a **polyline path** defined by a set of points, distributing it to whichever elements in the nominated group lie along that path. Use it for barrier and parapet weights, lane loads, services running along the deck, and any linear load whose position is defined geometrically rather than by naming elements. It survives re-meshing, which makes it the practical choice for a load that must stay on a line while the mesh beneath it changes. Global Line Loads **generate load**. They add nothing to stiffness or mass. ## Line Load **Load Case:** The analysis case the load belongs to. With no case assigned it applies nowhere. **Group:** The FE Group whose elements can receive the load. *Engineering influence.* The load is distributed onto elements **within this group** that lie along the path. A path that runs outside the group's elements delivers nothing, silently. This pairing of a path and a group is the crux of the object: both must be right, and neither is validated. **Points:** The polyline defining the load path, edited in its own sub-sheet. *Engineering influence.* The path defines both **where** the load acts and **how long** it is, and the total load applied is intensity × path length. A path that stops short of the deck end under-applies the barrier weight over the last portion of the span; a path that overshoots applies load beyond the structure, where it is lost. Because the path is geometric, it does not automatically follow a change in the structure's extent. On a curved bridge the polyline must have enough points to follow the curve — too few and it cuts across the arc, shortening the path and placing load off the intended line. **Fx / Fy / Fz:** Distributed force intensity in each direction, in force per unit length. **Mx / My / Mz:** Distributed moment intensity, in moment per unit length. *Engineering influence.* Intensity times path length gives the total applied load, and response scales linearly with it in a linear analysis. **Sign follows the axis direction** — a downward barrier weight in a Z-up model is a **negative** Fz. Note the intensity is **per unit length along the path**, so on a sloped or curved path it is not the same as per unit horizontal length; a quantity taken off a plan drawing must be converted before entry. Applying an eccentric line load — a barrier at the deck edge — produces both vertical load and torsion about the deck's centroid. That torsional effect is part of the point of placing the load geometrically, and it is lost if the load is simplified onto the centreline. **Convert to Node Load:** When enabled, the distributed load is resolved into equivalent concentrated loads at nodes rather than applied as a distributed load along the elements. *Engineering influence.* Node conversion is simpler and more predictable, but it loses the correct fixed-end moments that a genuinely distributed load produces within a member — the total load and the overall response are close, while local moments between nodes are not. Leave it off unless you specifically need nodal application; if it is on, ensure the mesh is fine enough that the discretized load is a fair representation. **Coordinate System:** Whether the components are interpreted in **Global**, **Local**, or a **UCS**. **UCS:** The user coordinate system used when Coordinate System is set to UCS. Ignored otherwise. *Engineering influence.* Global suits gravity-type loads. Local follows the path, which is what a pressure-type load along a curved or superelevated alignment needs. On a curved deck the two diverge continuously along the path, so the choice matters more here than on a straight member. ## Verification * Sum the case's reactions and compare against intensity × path length computed by hand. This catches a path that misses the group, a path shorter than intended, and unit slips in one step. * Display the applied loads and confirm the line follows the intended alignment with no gaps at either end. * On a curved structure, check that the polyline has enough points to follow the curve rather than cutting the chord. * Confirm the eccentricity produces the torsion you expect, by comparing against a case with the load on the centreline. * Check the sign by inspecting the deflected shape. * If Convert to Node Load is on, compare against the distributed case and confirm the difference is acceptable for the mesh density. ## Common mistakes * **A path that lies outside the group's elements**, so the load is silently lost. * **Too few polyline points on a curve**, shortening the path and misplacing the load. * **A path that does not span the full length** it should, under-applying the total. * **Sign error**, applying barrier weight upward. * **Using a plan-length intensity on a sloped or curved path** without converting. * **Simplifying an eccentric load onto the centreline** and losing the torsion. * **Leaving Convert to Node Load on with a coarse mesh**, distorting local moments. * **No Load Case assigned**, so the load does nothing. # Global Surface Load \[FEA] A Global Surface Load applies a distributed pressure over a **polygonal area** defined by a set of points, distributing it to the elements and nodes of the nominated group that fall within that area. Use it for deck overlays, snow, equipment pads, soil surcharge, and any area load whose footprint is defined geometrically rather than by naming elements. Like the other Global loads, it survives re-meshing. Global Surface Loads **generate load**. They add nothing to stiffness or mass. ## Surface Load **Load Case:** The analysis case the load belongs to. With no case assigned it applies nowhere. **Group:** The FE Group whose elements can receive the load. *Engineering influence.* Only elements inside this group and inside the polygon receive load. Both filters apply, so a load can be lost either by a polygon that misses the structure or by a group that excludes it — and neither produces a warning. **Points:** The polygon defining the loaded area, edited in its own sub-sheet. *Engineering influence.* The polygon sets the **footprint**, and the total load is pressure × enclosed area. Its accuracy therefore directly scales the applied load. A polygon that does not close properly, that is self-intersecting, or whose points are ordered inconsistently can enclose a different area than intended — sometimes a much smaller one. On a curved deck the polygon must have enough points to follow the edge, or it will cut across the curve and under-apply near the outside. **Fx / Fy / Fz:** Pressure components, in force per unit area. *Engineering influence.* Response scales linearly with pressure in a linear analysis. **Sign follows the axis direction** — a downward overlay pressure in a Z-up model is a **negative** Fz. The pressure is applied over the polygon's area. Where the deck is sloped, an overlay quantity derived from **plan** area must be converted, or the applied load will differ from the intended total by the slope factor. **Convert to Node Load:** When enabled, the pressure is resolved into equivalent concentrated loads at nodes rather than applied as a distributed pressure. *Engineering influence.* Node conversion is more predictable but loses the correct distribution within each element, so local moments differ while the total and the global response are close. Leave it off unless nodal application is specifically needed, and if it is on, ensure the mesh is fine enough for the discretization to be fair. ## Load Distribution These settings control how the pressure varies across the footprint rather than being uniform. **Load Type:** Selects the distribution pattern applied over the polygon — uniform, or varying between a base and an apex value. *Engineering influence.* A uniform pattern is right for an overlay or snow. A varying pattern is what soil pressure needs, since lateral earth pressure grows with depth; applying a uniform pressure where a triangular distribution is correct puts the resultant at the wrong height and produces the wrong overturning moment on a wall or abutment even when the total force happens to match. **Direction X / Direction Y / Direction Z:** Define the axis along which the distribution varies. *Engineering influence.* This is the direction the "base to apex" variation is measured in — for earth pressure on a wall, the vertical. Setting it to the wrong axis makes the pressure vary horizontally across the wall instead of with depth, which produces a completely different force distribution while still summing to a plausible total. **Load Coeff 1 (Base) / Load Coeff 2 (Apex):** The multipliers applied at the base and apex of the distribution. *Engineering influence.* These scale the pressure at each end of the variation. Equal values give a uniform distribution; 0 at one end and 1 at the other gives a triangular one, which is the usual earth-pressure idealization. The resultant force and, more importantly, its **line of action** depend on the ratio between them — a triangular distribution puts the resultant at one third of the height, a uniform one at mid-height, and the overturning moment differs accordingly. ## Verification * Sum the case's reactions and compare against pressure × polygon area computed by hand. This is the definitive check. * Display the applied loads and confirm the loaded footprint matches the intended area, with no gaps at the boundary and no spill beyond the structure. * Confirm the polygon closes and does not self-intersect. * For a varying distribution, check the **line of action** by comparing the overturning moment at the base against a hand calculation — a correct total force with a wrong distribution shows up here and nowhere else. * On a sloped deck, confirm whether your pressure was derived from plan or surface area. * Check the sign by inspecting the deflected shape. ## Common mistakes * **A polygon that misses the group's elements**, so the load is silently lost. * **Too few polygon points on a curved edge**, under-applying load near the outside. * **A self-intersecting or unclosed polygon**, enclosing the wrong area. * **Using a uniform distribution for earth pressure**, putting the resultant at mid-height and understating overturning at the base. * **The distribution direction set to the wrong axis**, varying pressure across the wall rather than with depth. * **Using plan-area quantities on a sloped deck** without converting. * **Sign error**, applying overlay pressure upward. * **No Load Case assigned**, so the load does nothing. # Temperature Loads \[FEA] A Temperature Load applies a thermal effect to line elements — either a uniform temperature change across the whole section, or a gradient through its depth. The temperature is converted to strain using the material's thermal coefficient, and that strain becomes force wherever the structure is restrained. Temperature Loads **generate load**. They add nothing to stiffness or mass. {% hint style="info" %} **Thermal effects produce force only where movement is restrained.** An unrestrained member simply changes length or curves and carries nothing. A member restrained against that movement — by fixed bearings, by integral abutments, or by redundancy in a continuous frame — develops large forces. This is why thermal actions often govern bearing, joint and substructure design, and why the same temperature change can be irrelevant in one bridge and decisive in another. {% endhint %} **Load Case:** The analysis case the load belongs to — typically a case classified as uniform temperature (TU) or thermal gradient (TG) so that combinations and code checks pick it up correctly. With no case assigned it applies nowhere. *Engineering influence.* Codes treat uniform temperature and gradient as separate actions with different factors, so keep them in separate cases. Temperature cases are also normally run as both a rise and a fall, since the two produce opposite-signed effects and different members govern in each. **Element:** The FE Line, or group of lines, the temperature applies to. This is a **connectivity** parameter. *Engineering influence.* Thermal force depends on which members expand relative to which do not, so the **extent** of the group is part of the physics rather than a bookkeeping detail. Heating the whole superstructure produces a very different result from heating one girder: the latter produces differential expansion and induces force between girders that the uniform case does not. **Use Active Elements:** When YES, every active line in the stage receives the temperature rather than only the named element. Convenient for a whole-structure temperature case; indiscriminate if the active set is broader than the region you intend to heat. **Equation to Filter Elements:** An expression evaluated per element to narrow the selection. Leave empty for no filter. A filter matching nothing produces a load object that silently does nothing — confirm how many elements actually received the temperature. ## Temperature **Temperature:** The temperature change, in temperature units. This is a **change from the stress-free state**, not an absolute temperature. *Engineering influence.* The induced strain is `α × ΔT`, and in a fully restrained member the induced stress is `E × α × ΔT` — independent of member length, which is why long and short restrained members develop the same thermal stress. The **force** does depend on area, and the **movement** in an unrestrained member depends on length. A positive value is a temperature rise, producing expansion; a negative value is a fall, producing contraction and, in a restrained member, tension. Both directions must normally be checked, because expansion and contraction load bearings, joints and substructure in opposite senses and different elements govern each. A value of zero applies nothing. The effect is **entirely dependent on the material's thermal coefficient**: a material whose coefficient is left at zero produces no thermal effect at all regardless of the temperature entered, which is a common reason a thermal case appears to do nothing. Results sensitive to it: bearing and joint movements, substructure moments and shears, and axial force in continuous or integral structures. **Temp. Variation Dir.:** Whether a gradient varies through the element's local **Y** or local **Z** direction. *Engineering influence.* This selects the axis the temperature varies across, which determines the plane the resulting thermal curvature acts in. For a bridge girder the vertical direction is the one that matters — solar heating warms the deck relative to the soffit and produces a **vertical** gradient, which causes the member to curve and, in a continuous structure, generates significant secondary moments over the supports. Choosing the wrong direction applies the gradient across the width instead of the depth, producing lateral curvature rather than the vertical hogging the design expects. Because both options are local, the correct choice depends on the member's **Beta Angle**, so a girder that is rotated will need the other setting — this is worth checking element by element rather than assuming. {% hint style="warning" %} Thermal gradients apply to **frame** elements only. Shell elements support uniform temperature but **not** a through-thickness gradient, so a deck modelled with shells cannot carry a thermal gradient directly and needs an equivalent representation. {% endhint %} ## Verification * Check that an **unrestrained** member simply expands by `α × ΔT × L` and carries no force. If it develops force, it is restrained somewhere you did not intend. * Check that a **fully restrained** member develops `E × α × ΔT` and compare against a hand calculation. * Confirm bearing and joint movements are within their capacity, and that they move in the direction the temperature sign implies. * Confirm the material's thermal coefficient is non-zero; a zero coefficient produces no effect at all. * For a gradient, inspect the deflected shape: a vertical gradient should produce visible upward or downward curvature, not lateral movement. Lateral movement means the variation direction is wrong for that member's orientation. * Run both a rise and a fall and confirm the effects reverse. * Check how many elements the load actually reached, particularly when using Use Active Elements or a filter. ## Common mistakes * **Entering an absolute temperature** rather than a change from the stress-free state. * **A zero thermal coefficient on the material**, so the load has no effect whatsoever. * **Checking only a temperature rise**, missing the contraction case where joints open and different members govern. * **Wrong variation direction** for the member's orientation, applying a gradient across the width instead of the depth. * **Applying a gradient to shell elements**, which do not support it. * **Heating only part of the structure unintentionally**, through a filter or group narrower than intended, producing spurious differential expansion. * **Combining thermal cases with uncracked stiffness** where the code expects reduced stiffness, which overstates the induced forces. * **Restraining the structure more than the real bridge is restrained**, which is the most common way thermal forces come out unrealistically high. # Cable Stressing Loads \[FEA] A Cable Stressing Load applies the jacking force of one or more cables to the structure. It converts each cable's **Pretension** into an equivalent initial-tension load, so that stressing a stay, a hanger, or an external tendon produces the correct axial force in the cable and the corresponding reactions in the anchorages and the rest of the structure. It is a **load-generating** parameter set. It adds nothing to the stiffness matrix and no mass; it builds a load vector from the geometry and pretension of the cables it selects. {% hint style="info" %} The magnitude comes from the **Pretension** parameter on the FE Line itself, not from this object. The Cable Stressing Load decides *which* cables are stressed, *in which case*, and *what fraction* of their pretension is applied. A cable whose Pretension is zero contributes nothing no matter what is set here. {% endhint %} ## General **Load Case:** The analysis case the resulting load belongs to. This is a **selection** parameter — the generated forces appear only in this case and in any combination that includes it. A stressing load with no case assigned produces no effect anywhere. In staged construction, this is normally the case attached to the stage in which the cable is actually stressed; assigning it to the wrong stage applies the jacking force before or after the structure has the geometry and stiffness to receive it, which changes the force distribution substantially. **Element:** The cable to stress — an FE Line, or a group of them. This is a **connectivity** parameter: it selects the members whose Pretension is converted to load. The referenced line should be a cable-type element with a non-zero Pretension. Pointing at an ordinary beam is not an error but is rarely meaningful. Define together with **Use Active Elements** and **Equation to Filter Elements**, which offer two alternative ways of choosing the same thing; use whichever expresses your intent most directly rather than combining them unnecessarily. **Use Active Elements:** When YES, every active cable in the stage is stressed, rather than only the element named above. This is the convenient choice for a stage in which a whole family of stays is tensioned at once, and it keeps working as cables are added to later stages without editing the load. When NO (the default), only the named Element (or group) is used. *Engineering influence.* Switching this to YES broadens the load to every currently active cable — including any you did not intend, such as cables that were stressed in an earlier stage and remain active. Re-stressing an already-stressed cable in a later stage double-counts its jacking force. Use the filter below, or explicit elements, when the active set is broader than the set being jacked. **Equation to Filter Elements:** An expression evaluated per element to narrow the selection. Use it to stress a subset — one side of a bridge, a numbered range of stays — without building a group for every combination. Leave it empty to apply no filter. An expression that matches nothing produces a load object that silently does nothing, so verify the count of elements actually stressed rather than assuming the filter matched. **Stressing:** The proportion of each cable's Pretension applied by this object, **entered in this sheet as a percentage**. {% hint style="danger" %} **Enter `100` (or `100%`) for full stressing, not `1`.** The cell is a percentage: the sheet divides what you type by 100 and displays the value back with a `%` suffix. Entering `1` applies **1%** of the Pretension, and entering `0.4` for "40%" applies **0.4%** — understating cable force, camber and reactions by a factor of 100, with no error. (The underlying stored parameter is a fraction where 1 = 100%, which is what the agent API and ParamML see; the percentage convention applies to this spreadsheet cell.) {% endhint %} *Engineering influence.* The applied force is `Stressing × Pretension`, so the response of a linear model scales linearly with it. Values below 100% represent partial stressing — the natural way to model a multi-stage jacking sequence, where a stay is taken to 40% in one stage and to full force in a later one. Take care that the values across stages express the *total* intended at each point, not increments, unless that is how you have set the sequence up; getting this wrong is the usual cause of final cable forces that are a multiple or a fraction of the target. A value of 0 applies no force. Values above 100% over-stress the cable and are legitimate for checking an over-tensioning condition. Negative values reverse the jacking direction, which is not physically meaningful for a cable and will usually put it into compression, where a cable-type element carries no load in a nonlinear analysis. Results sensitive to this parameter: cable forces, deck profile and camber, anchorage reactions, and in a staged model the locked-in forces carried into every subsequent stage. ## Verification * Check the axial force reported in the stressed cables and compare it with `Stressing × Pretension`. This is the most direct confirmation the load was generated. * Confirm the number of elements actually stressed matches your intent, particularly when using **Use Active Elements** or a filter. * Check the deflected shape: stressing a stay should lift the deck at the anchorage. No movement means the load was not generated — usually a missing Load Case, a zero Pretension, or a filter matching nothing. * Check anchorage reactions and confirm the structure is in equilibrium under the jacking force. * In a staged model, review cable forces stage by stage and confirm they follow the intended jacking sequence rather than jumping to full force early. * Hand-check a single stay: the vertical component of the jacking force should equal the change in the supported reaction. ## Common mistakes * **Zero Pretension on the cable.** The stressing load then applies exactly nothing. This has a documented history in this codebase — the parameter was once undeclared, which produced a jacking force of zero with no warning — so confirm the value is actually set on the FE Line. * **Assigning the load to the wrong stage**, applying jacking force to a structure that is not yet erected or is already complete. * **Leaving Use Active Elements YES across several stages**, re-stressing cables that were already tensioned and multiplying their force. * **Entering `1` in the Stressing cell to mean "full"**, which applies 1% of the pretension. The cell is a percentage — enter `100`. * **Treating Stressing as an increment** when the sequence expects a cumulative total, or the reverse. * **Stressing a cable modelled as an ordinary beam**, which carries compression and hides the error. * **Forgetting that the load lives in a case** — reviewing results in a combination that does not include that case and concluding the stressing did nothing. # Strain Loads \[FEA] A Strain Load imposes an initial (fabrication) strain on one or more line elements. The member behaves as though it were manufactured slightly longer or shorter than the geometry it must fit into, so forcing it into place induces stress in it and in the surrounding structure. This is how deliberate lack-of-fit is modelled: cross-frames detailed for a no-load, steel-dead-load or total-dead-load fit condition, pre-cambered members, jacked-in closure segments, and any element whose stress-free length differs from its modelled length. A Strain Load is **load-generating**. It adds no stiffness and no mass; it produces an equivalent load vector from the imposed strain and the member's axial stiffness. ## General **Load Case:** The analysis case the resulting load belongs to. A Strain Load with no case assigned produces no effect anywhere. In staged construction the choice of case (and therefore stage) decides what structure the lack-of-fit is forced into — the same strain applied to a bare steel frame and to a composite deck produces very different force distributions. **Element:** The line element, or group of lines, to strain. This is a **connectivity** parameter. Define together with **Use Active Elements** and **Equation to Filter Elements**, which are alternative ways of selecting the same set. **Use Active Elements:** When YES, every active line in the stage is strained rather than only the named element. Convenient for applying a uniform fabrication strain to a whole family of members, but indiscriminate — it will include members you did not intend if the active set is broader than the group being detailed. **Equation to Filter Elements:** An expression evaluated per element to narrow the selection. Leave empty for no filter. A filter that matches nothing yields an object that silently does nothing; confirm how many elements were actually strained. **Initial Strain:** The imposed strain, dimensionless (length per unit length). **Positive means the member was fabricated short** — it must be stretched to fit, so it ends up in tension at zero displacement, and it pulls the surrounding structure toward it. Negative means the member was fabricated long, ends in compression, and pushes the structure apart. Getting this sign backwards reverses every force the load induces, which is the single most consequential mistake with this object. *Engineering influence.* For a linear model the induced forces scale linearly with the strain. The magnitude of force produced depends on the **restraint** the member is forced against, not on the member alone: an unrestrained member with an initial strain simply changes length and induces almost nothing, while the same strain in a stiff, redundant frame produces large locked-in forces. This is why fit-condition effects are often negligible in one framing arrangement and dominant in another. A value of zero means no lack of fit. **This parameter is ignored when Displacement Stage is set** — the strain is then computed from that stage's solved displacements instead. Entering a value in both places is a common source of confusion because the typed value has no effect. Typical magnitudes are small: a fabrication strain corresponding to a few millimetres over a cross-frame length is of order 1e-4. Values orders of magnitude larger are usually a units slip (entering a length rather than a strain) and produce enormous, obviously wrong member forces. **Displacement Stage:** When set, the strain is **computed at solve time** from that stage's solved displacements, rather than taken from the Initial Strain field. The member is made stress-free in its *deflected* shape — which is precisely the definition of a dead-load fit condition. It is applied in a trailing "Locked-in Force Effects" substage, after the referenced stage has been solved. *Engineering influence.* This makes the load **dependent on the analysis result** rather than on a number you supply, so it automatically tracks changes to the structure, its loads, or its staging. Referencing a stage in which the relevant dead load has not yet been applied gives a fit condition based on an incomplete deflected shape — the usual cause of a fit that does not match the detailer's intent. Leave empty to use the typed Initial Strain instead. **Displacement Components:** Which global direction of the referenced stage's displacement is measured when computing the strain — All (0), X (1), Y (2) or Z (3). *Engineering influence.* Restricting to a single component isolates the part of the deflected shape that the fit is detailed against — commonly the vertical component for a girder bridge, where the cross-frames are detailed for vertical dead-load deflection and the small longitudinal and transverse movements are not part of the fit. Using All includes every component and generally produces a larger computed strain. This parameter only has meaning when **Displacement Stage** is set; it is ignored otherwise. **Scale:** A multiplier on the strain, whether typed or computed; 1 means 100%. *Engineering influence.* Scales the imposed strain and therefore, in a linear model, the induced forces proportionally. Useful for partial-fit conditions and for sensitivity studies — running the same model at 0, 0.5 and 1.0 shows how much of the force distribution is attributable to the fit condition. A value of 0 disables the load while keeping it in the model. Negative values invert the sense of the fit. ## Verification * Check the axial force in the strained members. It should have the sign the strain implies: positive strain (fabricated short) puts the member in **tension**. * Confirm the number of elements actually strained matches intent, especially with Use Active Elements or a filter. * Run the model with Scale at 0 and at 1 and compare. The difference is exactly the locked-in effect of the fit condition; if there is no difference, the load is not being generated. * For a computed fit, review the referenced stage's deflected shape and confirm the dead load you intend to fit against has actually been applied in it. * Check that the surrounding structure shows the expected response — a fabricated-short cross-frame should pull the girders together and induce girder lateral bending. * Hand-check an isolated member: force ≈ `E · A · strain · Scale` when fully restrained; much less when free. ## Common mistakes * **Sign reversal.** Reading positive as "fabricated long". Every induced force flips, and the result is plausible-looking but exactly wrong. * **Entering Initial Strain while Displacement Stage is set.** The typed value is ignored, and the analysis quietly uses the computed strain instead. * **Referencing a stage whose dead load is not yet applied** for a dead-load fit condition. * **Entering a displacement instead of a strain** — a value like 0.5 rather than 5e-4 — producing member forces orders of magnitude too large. * **Using Displacement Components = All** when the fit was detailed against vertical deflection only. * **Applying the strain to a member that is essentially unrestrained** and concluding fit conditions do not matter for the structure, when the restraint, not the strain, was the missing ingredient. * **Leaving the Load Case empty**, so the object exists and does nothing. # Prestressing Loads \[FEA] A Prestressing Load applies the force of a **Tendon** to the structure. The Tendon object defines the geometry, material, friction and jacking force; this object decides **which analysis case** receives the resulting prestress, **which ends** are stressed, and whether elastic-shortening loss is included. Prestressing Loads **generate load**. They add nothing to stiffness or mass; the prestress reaches the structure as an equivalent load system derived from the tendon force profile and its curvature. {% hint style="info" %} The magnitude comes from the **Tendon**, not from this object. A tendon with zero jacking force produces nothing here, no matter how this load is configured. Use **Prestressing Details…** on the Tendon to see the force profile that this load will apply. {% endhint %} **Load Case:** The analysis case the prestress belongs to — normally a case classified as prestress (PS) so combinations and code checks treat it correctly. With no case assigned, the prestress is applied nowhere. *Engineering influence.* In a **staged** model, the case determines when the tendon is stressed, and therefore what structure the prestress acts on: a tendon stressed before the deck is composite acts on the bare girder and produces a very different stress distribution than the same tendon stressed afterwards. In a non-staged model this simply separates prestress from other actions so it can be factored independently. **Tendon:** The tendon whose force is applied. This is a **connectivity** parameter — it selects the geometry, profile and force that will be converted into equivalent loads. A Prestressing Load with no tendon assigned does nothing. ## Stressing **Stressing at Start:** The proportion of the tendon's jacking force applied from its start end, **entered in this sheet as a percentage**. **Stressing at End:** The same, for the end. {% hint style="danger" %} **These are proportions, not yes/no switches, and the cells are percentages.** Enter `100` (or `100%`) to stress fully from that end and `0` not to stress from it. The sheet divides what you type by 100 and displays it back with a `%` suffix, so entering `1` applies **1%** of the jacking force from that end — a 100× under-application with no error. The value multiplies the tendon's jacking force, so intermediate values express partial stressing from an end. {% endhint %} *Engineering influence, both together.* Friction loss accumulates **away from a stressing end**, so the force profile peaks at each end that is jacked and dips in between. Stressing from **one** end gives an asymmetric profile with the lowest force at the far end; stressing from **both** gives a symmetric profile whose minimum is near midlength and whose far-end force is substantially higher than one-end stressing achieves. For a long tendon this choice materially changes the prestress delivered to the middle of the member, and therefore the balancing load and the concrete stresses there. For a short tendon the difference is small. Anchor-set loss is applied at each end actually stressed, so stressing both ends introduces the seating dip at both. Setting **both to 0** leaves the tendon unstressed, which produces no prestress at all. {% hint style="warning" %} The **View Tendon Short Term Losses** preview applies `Stressing at End` to *both* ends when it builds its preview, so for a tendon with different values at each end that dialog shows a force profile that does not match the analysis. The analysis itself uses both values correctly; trust the results over the preview in that case. {% endhint %} These settings must be consistent with the Tendon's own **Jacking Method** and jacking forces — nominating an end here that carries no jacking force on the tendon delivers nothing from that end. ### Instantaneous Elastic Shortening Loss **Instantaneous Elastic Shortening Loss:** Whether the immediate loss caused by the member shortening as it is compressed is included. *Engineering influence.* When a tendon is stressed, the member shortens elastically, and that shortening relieves some of the strain in tendons already stressed. Including it **reduces** the effective prestress, most for tendons stressed early in a sequence and least for the last one stressed — the final tendon experiences no elastic-shortening loss from itself in a post-tensioned member, while a pre-tensioned strand loses immediately at transfer. Ignoring it overstates the prestress force, which is unconservative for serviceability tension checks and for camber prediction. The magnitude grows with the number of stressing operations and with how heavily the member is compressed, so it matters most in heavily prestressed members with many tendons. ## Verification * Open **Prestressing Details…** on the referenced tendon and confirm the force profile is what this load will apply, including the anchor-set dips at the ends actually stressed. * Check the member's camber under prestress alone — upward deflection confirms the eccentricity and the force are both being applied. * Confirm the concrete is in compression where the design expects it, particularly at the extreme fibre at midspan and over supports. * Compare the force at midlength between one-end and both-end stressing to confirm the setting took effect. * Toggle elastic shortening loss and confirm the effective prestress changes by a plausible percentage. * In a staged model, confirm the prestress appears in the intended stage and carries forward. * Compare the equivalent balancing load against `w = 8·P·e/L²` for a parabolic profile. ## Common mistakes * **Entering `1` in a stressing cell to mean "yes, stress this end"**, which applies 1% of the jacking force. The cells are percentages — enter `100`. * **Both stressing ends set to 0**, so the tendon is never stressed. * **No tendon assigned**, or a tendon with zero jacking force, producing no prestress while the load object exists. * **Stressing ends inconsistent with the Tendon's jacking method or forces**, delivering less than intended. * **Ignoring elastic shortening loss** in a heavily prestressed member, overstating the effective prestress and the resulting compression. * **Applying prestress in the wrong stage**, acting on a structure that is not yet composite or not yet erected. * **Assuming one-end stressing is adequate on a long tendon**, leaving the far end substantially under-stressed. * **No Load Case assigned**, so nothing is applied. # Analysis Overrides \[FEA] An Analysis Override changes a property of an object **for one analysis case only**, without editing the object's base definition. The same model can therefore be analysed with different properties in different cases — cracked sections for seismic, uncracked for service; a bearing fixed in one case and free in another; a support removed to check a jacking condition. Overrides change the **stiffness matrix** (or whatever property they target) for their case. They generate no load and add no mass. {% hint style="info" %} An override is scoped to its **Analysis Case**. It does not change the object anywhere else, and the spreadsheet for the object continues to show the base value — which is why an override is easy to forget about. When a case produces results that do not match the model as you read it in the sheets, the overrides are the first place to look. {% endhint %} **Analysis Case:** The case the override applies to. This is the parameter that scopes everything else; an override with no case assigned applies nowhere. *Engineering influence.* Overrides are how one model serves several code checks with different stiffness assumptions. Assigning an override to the wrong case silently applies a cracked-section or released-bearing assumption to an analysis that should have used the base properties, and nothing in the results announces it. ## Nodes **Object:** The node whose property is overridden. **Property:** The node property being changed — typically one of the six DOF restraint or spring values. **Value:** The value used in this case. *Engineering influence.* This is how a **support condition is changed per case**: releasing a restraint to model a jacking operation or a bearing replacement, fixing a normally-free direction to represent a temporary condition, or substituting a different spring stiffness for a case where the soil behaves differently. Because it changes restraint, it changes the whole load path: releasing a support redistributes its reaction to the others and can, if over-used, leave the structure a mechanism for that case. The value follows the node's own sign convention — **0 free, negative fixed, positive a spring stiffness** — so an override entered as 1 to "fix" a direction produces an almost-free spring instead. ## Springs **Object:** The spring whose property is overridden. **Property:** The spring property being changed — usually a directional stiffness. **Value:** The value used in this case. *Engineering influence.* The standard use is substituting an isolator's or bearing's stiffness per case: the small-amplitude stiffness for a service or wind case, and the effective secant stiffness for a seismic one. Because the isolated period depends directly on this, an override here can change the dynamic response of the whole structure. Setting a stiffness to zero removes the connection for that case, which may leave the model unstable. ## Lines **Object:** The line element whose property is overridden. **Property:** The property being changed — section area, inertia, torsion constant, modulus, or one of the corresponding factors. **Value:** The value used in this case. *Engineering influence.* This is the most common override in practice: applying **cracked-section properties** to concrete members for a seismic or long-term case while keeping gross properties for service checks. Reducing a member's inertia softens it, lengthens periods, and **sheds** force into stiffer adjacent members — so softening a pier reduces its own moment while increasing demand on its neighbours. That redistribution means an override is not conservative in a single direction, and the whole structure has to be reviewed after applying one. Overriding torsion constant is the other frequent case, since uncracked `J` grossly overstates the torsional stiffness a cracked concrete member delivers. ## Surfaces **Object:** The shell whose property is overridden. **Property:** The property being changed — thickness, modulus, or one of the membrane/bending modifiers. **Value:** The value used in this case. *Engineering influence.* Used to apply cracked-section stiffness to a deck or wall for a specific case. Because the shell modifiers act in **local** axes, an override applied across a mesh with inconsistent local axes softens different physical directions on different elements. ## Volumes **Object:** The solid whose property is overridden. **Property:** The property being changed. **Value:** The value used in this case. ## Custom **Object:** Any object in the model, for overriding a property not covered by the typed tabs above. *Engineering influence.* The general-purpose escape hatch. It is powerful and correspondingly easy to misuse: there is no type checking that the property named is meaningful for the object selected, and a property name that does not resolve produces an override that silently does nothing. {% hint style="warning" %} Several columns on this object read blank in the sheet because their values are held per-tab; the Object/Property/Value trio you edit is the one belonging to the active tab. Check you are on the right tab for the object type you intend to override. {% endhint %} ## Verification * Run the case with and without the override and compare. If nothing changes, the override is not being applied — the usual causes are an unassigned case, a property name that does not resolve, or the wrong tab. * Check periods and mode shapes after a stiffness override; a cracked-section override should measurably lengthen periods. * Check reactions after a restraint override; releasing a support must redistribute its reaction to the others while the total stays the same. * Confirm the base model is unchanged by reviewing the object's own spreadsheet row. * List all overrides before signing off a case, and confirm each one is intended for that case. * Where an override softens a member, check the members around it for the increased demand. ## Common mistakes * **Forgetting an override exists.** The object sheets show base values, so a case can behave differently from what the model appears to say, indefinitely. * **Assigning the override to the wrong analysis case**, applying cracked properties to a service check or gross properties to a seismic one. * **Using the node sign convention wrongly** — entering 1 to fix a direction, which creates an almost-free spring. * **A property name that does not resolve**, producing an override that does nothing without warning. * **Editing on the wrong tab** for the object type being overridden. * **Softening a member and reviewing only that member**, missing the increased demand redistributed into its neighbours. * **Overriding a stiffness to zero** and destabilizing the model for that case. # Live Loads \[FEA] Live Loads holds the objects used for influence-surface traffic loading. **Vehicles** define axle configurations. **Design Lanes** define a traffic lane - its width, the vehicles that travel in it, the accompanying lane load, and the rules for placing vehicles within it. **Influence Surfaces & Lines** define the loaded region and the grid of unit-load positions used to build the influence coefficients. **Live Load Cases** tie the lanes and surfaces together and run the search. The analysis places a unit load at every grid point, solves, and then searches for the vehicle and lane arrangement that maximizes each response. Results are therefore **envelopes**: each value is the worst case over all positions, and different values correspond to different truck positions. They are not a single equilibrium state, and pairing two enveloped maxima for an interaction check combines actions that never coexist. Grid spacing is the main trade-off: finer grids find sharper peaks, at a cost that grows quadratically. # Vehicles \[FEA] A Vehicle defines an axle configuration — the axle spacings, wheel spacings and wheel loads that make up a design truck, a tandem, a fatigue vehicle or a permit load. It is a **definition**, not a load: a vehicle applies nothing until a Design Lane references it and a Live Load Case runs. The axle and wheel geometry is held in the vehicle's sub-objects, edited through its own sheet. Vehicles ultimately **generate load**, indirectly, through the influence-surface machinery. They add nothing to stiffness or mass. ## Data **Factor:** A multiplier applied to the vehicle's wheel loads. *Engineering influence.* Scales the whole vehicle linearly, so response scales with it in a linear analysis. It is the natural place to express a load factor that belongs to the vehicle itself rather than to the lane or the combination — a permit vehicle at a proportion of its full weight, or a fatigue truck scaled to a code-specified fraction. Take care not to double-count: impact (dynamic allowance) is applied on the **Design Lane** as an impact factor, and load combination factors are applied in the combination. A factor applied here as well as there multiplies them together. A value of 1 leaves the vehicle at its defined weight. **Gross Vehicle Weight (readonly):** The total weight of all wheel loads, after the factor. *Engineering influence.* This is **output** and it is the most useful verification field on the object. Compare it against the published gross weight for the design vehicle you intended — a mismatch means a wheel load, an axle, or the factor is wrong, and it catches the error before it propagates into every live-load result. {% hint style="warning" %} This column is derived and cannot be edited, but it is not flagged read-only, so typing into it appears to work and the value is discarded on redraw. {% endhint %} ### Axle and wheel definition The axle configuration itself — the number of axles, their longitudinal spacing, the transverse wheel spacing, and the load on each wheel — is defined in the vehicle's sub-objects. *Engineering influence.* **Axle spacing** governs which spans and which influence-surface peaks the vehicle can load simultaneously: a closely-spaced tandem concentrates load and maximizes local deck effects and short-span moments, while a long truck spreads load and can straddle two spans to maximize negative moment over an interior support. Variable-spacing axles exist in design vehicles precisely so the critical spacing can be searched. **Wheel spacing** transversely determines the distribution between girders — a wheel line directly over a girder produces a very different girder moment than one between girders — which is the whole reason for running an influence-surface analysis rather than a simple distribution factor. **Wheel loads** scale the response directly, and their distribution between axles matters as much as the total: two vehicles of the same gross weight but different axle distributions produce different local effects. ## Verification * Check **Gross Vehicle Weight** against the published value for the design vehicle. This single check catches most definition errors. * Display the vehicle and confirm the axle and wheel layout matches the code figure, including spacings. * Confirm the number of axles is right — a missing axle is easy to overlook and shows up in the gross weight. * Run a simple single-span case and compare the maximum moment against a hand calculation for the vehicle at its critical position. * Confirm impact is applied once, on the lane, and not duplicated in the vehicle factor. * Compare results against a published live-load moment table for a standard span where one exists. ## Common mistakes * **Double-counting impact** by applying it both in the vehicle Factor and in the lane's impact factor. * **Gross weight not matching the design vehicle**, from a wrong wheel load or a missing axle. * **Entering axle loads where wheel loads are expected**, doubling the vehicle weight — the gross weight check catches this immediately. * **Wrong wheel spacing**, misrepresenting transverse distribution between girders. * **Fixing a variable axle spacing** at one value and losing the critical-spacing search. * **Assuming the vehicle is applied** — it does nothing until a Design Lane references it and a Live Load Case runs. # Design Lanes \[FEA] A Design Lane defines a traffic lane for live load analysis: its width, which vehicles travel in it, the accompanying lane load, and the rules governing where vehicles may be placed within it. Given the roadway dimensions, OpenBrIM manages lane placement in the transverse direction for influence-surface live load analysis, exploring the alternatives — shifting lanes across the roadway and evaluating enormous numbers of configurations — to find the arrangement that maximizes each response. Design Lanes **generate load**, indirectly, through the influence-surface search. They add nothing to stiffness or mass. ## Properties **Lane Width:** The width of the design lane. *Engineering influence.* Lane width, together with the roadway width from the loading surface, determines **how many lanes fit** — and the number of loaded lanes, combined with the multiple presence factors on the Live Load Case, is often what governs the design. A lane narrower than the code value allows more lanes onto the deck than the code intends; a wider one allows fewer. The lane width is a code quantity (commonly 12 ft / 3.6 m), not the physical marked lane. **Margin btw. Vehicle & Lane Edge:** The clearance kept between the vehicle's outer wheel and the lane edge. *Engineering influence.* This limits how far a vehicle may shift transversely within its lane, and therefore how close a wheel line can get to an exterior girder or a deck edge. Because exterior girder distribution is often governed by the extreme wheel position, increasing the margin **reduces** the worst-case exterior girder demand, and decreasing it increases it. The value is prescribed by code (commonly 2 ft / 600 mm from the lane edge); choosing it arbitrarily changes the exterior girder result directly. ## Vehicles **Vehicle 1–4:** Up to four vehicles that may occupy this lane. *Engineering influence.* These are **alternatives**, and the analysis takes the governing one for each response — a design truck and a design tandem are both listed so that whichever produces the larger effect at each location is used. Listing only one omits the possibility that the other governs, which in short spans is frequently the tandem and in long spans the truck. **Vehicle 1–4 Impact Factor:** The dynamic load allowance applied to each vehicle. *Engineering influence.* Amplifies the vehicle's static effect to account for dynamic interaction with the deck. Codes typically apply it to the truck or tandem but **not** to the lane load, and often use a reduced value for fatigue and none for some limit states. Applying impact to the lane load, or applying it here as well as in the vehicle's own factor, over-counts it. A factor of 1 means no dynamic allowance. **Vehicle 1–4 Left Wheel Factor:** A multiplier on the left wheel line of each vehicle. *Engineering influence.* Allows an unbalanced axle — heavier on one side — which is used to maximize transverse effects such as exterior girder demand or deck overhang moment. A value of 1 keeps the axle symmetric. **Vehicle 1–4 Direction:** The travel direction of each vehicle. *Engineering influence.* Matters for vehicles whose axle configuration is not symmetric front-to-back: reversing such a vehicle changes which axle group leads and therefore the critical position and the resulting effects. For a symmetric vehicle it makes no difference. ## Lane Load **Lane Load Magnitude:** The uniformly distributed lane load, in force per unit length. *Engineering influence.* The lane load represents the general traffic stream and is applied **in addition to** the vehicle, not instead of it. Its relative importance grows with span: for short spans the vehicle dominates, while for long spans and for negative moment over interior supports the lane load contributes a large share. It is also applied to the influence surface in whatever pattern maximizes each response, which is why it can be discontinuous — loaded in some spans and not others. Impact is **not** normally applied to the lane load. **Lane Load Width:** The transverse width the lane load is spread over. *Engineering influence.* The lane load is distributed across this width rather than applied as a knife edge, which affects the transverse distribution between girders. A width narrower than the code value concentrates the load and increases the demand on the girder beneath it. ## Vehicle Placement Settings **Min. Vehicle Spacing (Back to Front) / Max. Vehicle Spacing:** The range of longitudinal spacing allowed between successive vehicles in the lane. *Engineering influence.* This governs the multiple-truck configurations used for effects that require more than one vehicle — most importantly **negative moment over interior supports**, where codes specify two trucks at a defined minimum headway. Setting the minimum too large prevents the critical two-truck arrangement from being found, under-predicting negative moment; the range should reflect the code requirement. **Adjacent Span Placement:** Whether vehicles may be placed in adjacent spans simultaneously. *Engineering influence.* Loading adjacent spans is what maximizes negative moment and interior support reactions, while loading a single span maximizes positive moment in it. Disabling this prevents the adjacent-span pattern from being considered and **understates** negative moment over the supports — one of the more consequential simplifications available on this object. ## Lane Placement Settings **Apply Lane Constraint:** Whether the lane's transverse position is restricted rather than free to shift across the roadway. **Left Transverse Offset / Right Transverse Offset:** The bounds of the permitted transverse position when the constraint is applied. *Engineering influence.* By default lanes shift freely across the roadway and the analysis finds the governing transverse position. Constraining them fixes lanes at particular positions — appropriate when the actual striping is fixed and will not change, or when checking a specific known configuration. Constraining unnecessarily **prevents the search from finding the critical arrangement**, which typically understates exterior girder demand. Leaving the constraint off is the conservative and usual choice. **Allow Multi Lane Placement:** Whether more than one lane may be loaded simultaneously. *Engineering influence.* Multiple loaded lanes maximize total load and interior girder demand; single-lane loading with the higher multiple presence factor often governs exterior girders. Disabling multi-lane placement removes the multi-lane cases from the search entirely and understates the demand on interior members and substructure. ## Verification * Confirm the number of lanes the analysis actually placed matches the roadway width divided by the lane width, and matches the code's requirement. * Check that the governing transverse lane position for an exterior girder puts a wheel line near the edge, subject to the margin — if lanes are not shifting, a lane constraint is probably active. * Confirm impact is applied to the vehicle and not to the lane load, and only once. * Compare a simple span's maximum live-load moment against a published table or hand calculation. * Check negative moment over an interior support with adjacent-span placement enabled and disabled; the difference confirms the setting is working and shows how much it matters. * Confirm both truck and tandem alternatives are being considered by checking which governs at different locations. ## Common mistakes * **Listing only one vehicle**, missing the alternative that governs — commonly the tandem on short spans. * **Applying impact twice**, in both the vehicle Factor and the lane's impact factor. * **Applying impact to the lane load**, which codes generally do not. * **Disabling adjacent span placement**, understating negative moment over interior supports. * **Constraining lane positions unnecessarily**, preventing the search from finding the critical transverse arrangement and understating exterior girder demand. * **Disabling multi-lane placement**, removing the cases that govern interior girders and substructure. * **A lane width that is not the code lane width**, changing how many lanes fit on the deck. * **A minimum vehicle spacing too large** to allow the code's two-truck negative-moment configuration. # Influence Surfaces & Lines An Influence Surface defines the roadway area over which live loads are placed, and the grid used to build the influence coefficients. The analysis places a unit load at each grid point, solves the model, and records the effect on every response — producing a surface that can then be searched for the vehicle and lane arrangement that maximizes each result. ## Influence surface or influence line? The same object does both. Set **Type** to say which you are building, and point the **Loaded Group** at the matching elements: | Type | Loaded Group holds | You get | Typical model | | --------------------- | ------------------ | --------------------------------------------------------------------------- | ----------------------------- | | **Surface** (default) | **FESurfaces** | An influence **surface** — a 2D grid of unit-load positions across the deck | Deck / grillage / shell model | | **Line** | **FELines** | An influence **line** — unit loads travelling along the members | Beam-line ("spine") model | The engine dispatches on the element it finds, not on Type, so a mismatch is not fatal — but Type is what gives a new path sensible **defaults** (a Line starts with a real lane width instead of zero), and it is what files the path under **Influence Lines** rather than **Influence Surfaces** in the analysis-case list. If a path places no load and its Type disagrees with its group, the error says so. Type defaults to **Surface**, so every path built before this parameter existed is unchanged. For the influence-line case the unit load rides on the line elements themselves, and the **width of the loaded strip is taken from each FELine's section**. This has three consequences worth knowing before you build the model: * **The path still needs a width**, even though you are building a "line" — it is the width the vehicles occupy, not a property of the members. Setting Type to **Line** seeds it for you; a zero-width path encloses no area and can place no load anywhere, and the analysis stops rather than reporting zero live load. * **An FELine can only be loaded if it has a Section with geometry**, two end nodes and non-zero length. A property-only section — area and inertias entered numerically, with no shape — has no width to load, and lines carrying one are skipped. This is a common way to build a spine model, so check it first if live load comes out low. * **The path width must be consistent with the section widths.** A path drawn wider than the strip the lines present puts grid points where there is nothing to load. If a path ends up unable to place *any* load — no group, no loadable elements in it, a zero-width path, or an all-zero unit load — the analysis stops with a message naming the cause. **Partial** gaps are not reported: if nine girder lines are loadable and the tenth is not, the analysis completes and that tenth region simply reads zero. Verify coverage rather than relying on an error. A beam-line model does **not** need a dummy deck of FESurfaces to carry live load. Point the Loaded Group at the FEGroup holding the girder FELines and draw the path along them. For each unit load position a finite element analysis is run. A 1000 ft × 50 ft roadway at 1 ft spacing would require 50,000 solutions, so the grid spacing is the main lever on run time and must be chosen deliberately. Influence Surfaces **generate load**, indirectly, and define the geometry the live load search operates over. They add nothing to stiffness or mass. ## Data **Type \[Surface/Line]:** Which influence workflow this path is — see above. Defaults to **Surface**. *Engineering influence.* It does not change the analysis, which dispatches on the elements in the Loaded Group. It changes the **defaults** (a Line starts with a usable path width instead of zero, which is the difference between an influence line that works and one that silently places no load) and where the path is filed in the analysis-case list. **Width Right Side (Start / Mid / End)** and **Width Left Side (Start / Mid / End):** The roadway half-widths either side of the alignment, at the start, middle and end of the surface. *Engineering influence.* These define the trafficable width, which determines **how many design lanes fit** and how far transversely a lane may shift. Both feed directly into the multiple presence factors and into the exterior girder result, so the widths are not merely a drawing quantity — they change the answer. Specifying start, mid and end values allows a **varying** width, which is how a widening deck, a tapered approach or a ramp is represented. Leaving the mid value empty gives a linear variation between the ends. A width narrower than the real roadway understates the lane count; one that extends past the barrier places vehicles where traffic cannot go and over-predicts local effects, particularly deck overhang and exterior girder demand. **Loaded Group (Surfaces or Lines):** The FE Group whose elements receive the unit loads — FESurfaces for an influence surface, FELines for an influence line (see above). *Engineering influence.* This is the **connectivity** parameter: the unit loads are applied to these elements. If the group does not cover the roadway footprint, parts of the surface have nothing to load and the influence surface is incomplete there — producing live-load results that are simply too low in those regions. If the group is unset, contains neither surfaces nor lines, or contains only FELines that cannot be loaded, the analysis stops with a message naming which of those it is. **Span Locations (For two truck cases):** The span boundaries used when placing multiple vehicles. *Engineering influence.* Codes require two trucks in adjacent spans for negative moment over interior supports, at a defined headway. These locations tell the search where the spans are so it can construct that configuration. Omitting or misplacing them prevents the critical two-truck arrangement from being found and **understates negative moment** over the supports. **# of Path Points (readonly):** Reports how many points define the surface path. *Engineering influence.* Output, used for verification. On a curved alignment, too few points mean the path cuts across the curve, misplacing the roadway. This is derived and cannot be edited, though it is not flagged read-only in the sheet. ## Unit Load **Long. Placement Increment / Trans. Placement Increment:** The grid spacing at which unit loads are placed, longitudinally and transversely. *Engineering influence.* This is the accuracy-versus-time trade-off, and it is the most consequential setting on the object. A finer grid resolves the influence surface more accurately and finds sharper peaks — coarse spacing **misses the true maximum** between grid points and under-predicts, particularly for local effects such as deck moments and exterior girder demand where influence surfaces have sharp peaks. Global effects such as span moments have smooth influence surfaces and tolerate coarser grids. The cost is quadratic in the two increments together: halving both multiplies the number of solutions by four. Choose the transverse increment fine enough to resolve wheel positions relative to girder spacing — a transverse grid coarser than the girder spacing cannot represent transverse distribution at all. **Unit Force X / Y / Z** and **Unit Moment X / Y / Z:** The unit load applied at each grid point to build the influence coefficients. *Engineering influence.* Normally a unit vertical force, which is what a wheel load applies. The other components exist for specialized cases — a longitudinal component for braking, or a moment for a concentrated torsional effect. The influence surface is scaled by the actual wheel loads afterwards, so the magnitude here is a reference rather than a design load; what matters is that the **direction** matches the load being represented. ## Centrifugal **Centrifugal Fact. for Radial Force:** A station-dependent factor generating radial force from the vertical load, for curved alignments. *Engineering influence.* On a curved bridge, vehicles travelling at speed produce an outward radial force proportional to their weight and inversely proportional to the radius. This factor generates that force alongside the vertical wheel load, so it is captured in the same influence-surface search. Because it acts at deck level, above the bearings, it produces overturning and torsion in addition to lateral load — the effect that governs bearing and substructure design on tight-radius curves. A value of zero omits centrifugal effects entirely, which is correct only for a straight bridge. ## Verification * Check **# of Path Points** and display the surface, confirming it follows the alignment and that the width matches the roadway drawing at start, mid and end. * Confirm the surface group covers the full roadway footprint. * Halve the placement increments and re-run. If the governing results move materially, the grid was too coarse; if they are stable, it is adequate. This is the only reliable way to know. * Check that the number of lanes placed matches the roadway width divided by the lane width. * Confirm negative moment over interior supports is being produced by a two-truck configuration, which requires the span locations to be set. * For a curved bridge, confirm radial forces appear and that they act at deck level. * Compare a simple span's maximum live-load moment against a published table. ## Common mistakes * **Placement increments too coarse**, missing the peak of the influence surface and under-predicting — most damagingly for local deck and exterior girder effects. * **A transverse increment coarser than the girder spacing**, which cannot resolve transverse distribution at all. * **A surface group that does not cover the whole roadway**, leaving regions with no influence data. * **Roadway width extending past the barrier**, placing vehicles where traffic cannot go. * **Missing span locations**, so the two-truck negative-moment configuration is never constructed. * **Zero centrifugal factor on a curved bridge**, omitting radial force and the overturning it causes. * **Too few path points on a curved alignment**, so the roadway cuts across the curve. * **Refining the grid everywhere** when only local effects need it, multiplying run time unnecessarily. # Live Load Cases \[FEA] A Live Load Case ties together the lane definitions and the roadway surfaces, and runs the influence-surface search that finds, for every response in the model, the vehicle and lane arrangement that maximizes it. Its results are therefore **envelopes**: each reported value is the worst case over all considered positions, and different values in the same report generally correspond to different vehicle positions. Live Load Cases **generate load** through the influence-surface machinery. They add nothing to stiffness or mass. {% hint style="warning" %} Live load results are enveloped maxima, not a single equilibrium state. Reactions will not sum to any one applied load, and a moment and a shear reported at the same section usually occur under different truck positions. Use the concurrent-force extraction facilities where a genuinely simultaneous set of actions is needed for a design check. {% endhint %} ## Properties **Multiple Presence Factors (MPF):** The factors applied according to how many lanes are loaded simultaneously, entered as a list — by default `[1.2, 1, 0.85, 0.65]` for one, two, three and four or more loaded lanes. *Engineering influence.* These account for the reducing probability that several lanes are simultaneously loaded to their design maximum. The value **greater than 1 for a single lane** is the one that surprises people: it exists because the design lane load is calibrated on multi-lane statistics, and a single loaded lane is more onerous per lane than the calibration assumes. Because of it, **single-lane loading frequently governs exterior girders** even though multi-lane loading produces more total load. Entering fewer factors than the number of lanes that can fit leaves the extra cases without a defined factor. Setting all factors to 1 removes the reduction and over-predicts multi-lane demand. **Maximize for Stress Range (Fatigue):** Whether the search maximizes stress **range** rather than peak effect. *Engineering influence.* Fatigue is driven by the range between maximum and minimum stress at a detail, not by the peak value, and the vehicle position that maximizes range is generally **not** the one that maximizes peak. Enabling this makes the search target the range, which is what a fatigue check requires. Using peak-effect results for a fatigue assessment misstates the range — sometimes substantially, particularly in continuous structures where a detail sees both sagging and hogging. Note that fatigue is normally assessed with a single fatigue truck, no multiple presence factor and a reduced impact factor, so the lane and vehicle definitions used for a fatigue case usually differ from those used for strength. **Maximum # of Lanes:** A cap on the number of simultaneously loaded lanes. A value of −1 means no cap beyond what the roadway geometry allows. *Engineering influence.* Restricting this reduces the multi-lane cases considered, which understates demand on interior girders and substructure. It is legitimate where the physical roadway genuinely cannot carry more lanes, and unconservative if used to shorten run time. ## Lanes **Design Lane Option 1–4:** The lane definitions available to this case. *Engineering influence.* These are **alternatives** — the analysis considers each lane configuration and takes the governing result. Providing several allows different lane widths or vehicle mixes to compete, which is how a permit case and a standard case can be evaluated in one run. A case with no lane assigned has nothing to place and produces no live load at all. ## Roadways **Influence Path 1–4:** The influence surfaces or influence lines the lanes are placed on. A beam-line model attaches an influence line here exactly as a deck model attaches an influence surface — both are authored as the same object, distinguished only by whether its Loaded Group holds FELines or FESurfaces. *Engineering influence.* The loading surface defines the **available roadway width and extent** — the region vehicles may occupy. It therefore governs how many lanes fit and how far transversely they can shift, which feeds directly into the multiple presence factors and the exterior girder result. A surface narrower than the real roadway understates the number of lanes; one that extends over regions traffic cannot reach (a sidewalk, beyond a barrier) places vehicles where they never go and over-predicts local effects. A case with no influence path assigned produces no live load, silently. A case whose assigned path cannot place any load (no loaded group, no loadable elements in it, a zero-width path, or an all-zero unit load) stops the analysis with a message naming the cause. ## Magnification Factors **Magnification Factor Fx / Fy / Fz / Mx / My / Mz (Pos)** and the matching **(Neg)** columns: separate multipliers applied to each force and moment component, for positive and negative effects independently. *Engineering influence.* Live-load effects are enveloped, so a given component has both a maximum (positive) and a minimum (negative) extreme, and codes do not always factor the two identically — uplift and reversal cases in particular are often treated differently from the governing positive effect. Twelve separate factors let each extreme be scaled on its own. The factors scale the reported effect linearly. A value of **1** leaves a component unchanged, which is the normal setting; **0** suppresses that component's contribution entirely, which is a silent way to lose a design action if set by mistake. Because positive and negative are independent, setting only the Pos column leaves the negative extreme unfactored — a common oversight when a code factor is meant to apply to both senses. These are applied at result time and do not change where vehicles are placed. ## Settings **Structure Group:** The part of the structure active for this case. Leave empty to analyse the whole model. Restricting it also restricts which members the influence surface is built for. **Is Active:** Whether the case is solved. Inactive cases are skipped silently, so a live-load case that appears to produce nothing is worth checking here first. ## Verification * Confirm the case produced results at all. Zero live load usually means no lane or no loading surface is assigned, or the case is inactive. * Check the number of lanes the analysis placed against the roadway width and code lane width. * Compare a simple span's maximum live-load moment against a published table or a hand calculation for the design vehicle at its critical position. * Check that exterior girder results are governed by the single-lane case with its higher multiple presence factor, and interior girders by multi-lane — if not, look at the lane placement constraints. * Confirm the governing vehicle position is physically plausible by displaying it. * For fatigue, confirm the stress-range option is on and that the fatigue vehicle, impact and presence factors are the ones the code prescribes. * Do not check equilibrium against reactions; enveloped results are not in equilibrium. ## Common mistakes * **No loading surface or no design lane assigned**, so the case produces nothing. * **Using peak-effect results for a fatigue check** instead of enabling stress-range maximization. * **Setting all multiple presence factors to 1**, removing the reduction and over-predicting multi-lane demand — while also losing the 1.2 single-lane amplification that often governs exterior girders. * **A loading surface that extends beyond the trafficked width**, placing vehicles on sidewalks or past barriers. * **Capping the number of lanes** to shorten run time, understating interior girder and substructure demand. * **Treating enveloped results as a simultaneous load state** and trying to check equilibrium or combine components that never coexist. * **Reusing the strength case's lanes and vehicles for fatigue**, where a different vehicle, impact and presence treatment apply. # Wind Loads \[FEA] Wind Loads holds the **Wind Load Case**, which applies wind pressure to the projected area of the nominated components and sweeps a range of attack angles. This is a **static** treatment: pressure on projected area. It does not model aerodynamic instability - flutter, galloping or vortex shedding - nor gust dynamics, so slender and cable-supported bridges need a separate aerodynamic assessment. The two things that most often go wrong are the exposed area (parapets and barriers contribute disproportionately and are easy to omit) and the FE group that receives the computed forces (if it does not cover the loaded region, the force is silently lost). # Wind Load Cases \[FEA] A Wind Load Case applies wind pressure to the structure. The program projects the exposed area of the nominated components perpendicular to the wind direction and applies the specified pressure to it, producing the resulting forces. Several attack angles can be swept in one case, and the envelope of them taken. Wind Load Cases **generate load**. They add nothing to stiffness or mass. {% hint style="info" %} This is a **static** wind treatment: pressure applied to projected area. It does not model aerodynamic instability — flutter, galloping or vortex shedding — nor gust dynamics. Long-span, slender or cable-supported bridges need a dedicated aerodynamic assessment beyond this case. {% endhint %} ## Wind **Wind Pressure:** The design wind pressure, in force per unit area. *Engineering influence.* This scales the whole case linearly: doubling it doubles every wind force, moment and reaction in a linear analysis. It is a **pressure**, already incorporating the velocity, exposure, gust and drag factors your code requires — the program does not derive it from a wind speed, so all of that conversion happens before the value is entered. A value of zero applies no wind at all. Because different components have different drag characteristics, a single pressure across the whole structure is an approximation; see Pressure Per 3D Components below. **Start Attack Angle / End Attack Angle:** The range of wind directions swept. **# of Directions:** How many directions are analysed within that range. *Engineering influence, all three together.* Wind rarely governs from a single direction: transverse wind maximizes lateral load on the superstructure, skewed wind produces torsion on the deck and maximizes load on some substructure elements, and longitudinal wind governs bearing and abutment design. Sweeping a range and enveloping the results is how the governing direction is found rather than assumed. Increasing the number of directions resolves the envelope more finely at proportionally more run time. Too few directions can step straight over the critical angle — with only two or three across a 180° range, a skew that governs a particular member is easily missed. Setting the start and end angles equal analyses a single direction. For a skewed or curved bridge the critical angle is usually not aligned with a global axis, which is precisely why the sweep exists. **Coordinate System:** Whether the attack angles are measured in global axes or a local/user system. For a curved or skewed structure, measuring angles relative to the structure's own axes makes the sweep easier to interpret. **Is Active:** Whether the case is solved. Inactive cases are skipped silently. ## Structure **3D Components:** The 3D geometry whose projected area catches the wind. *Engineering influence.* This is a **connectivity** parameter, and it determines the exposed area — which, with the pressure, determines the total force. Wind force is proportional to projected area, so omitting components under-applies load and including components that are shielded or not really there over-applies it. A parapet, a noise barrier or a sign gantry contributes disproportionately to transverse wind because of its height above the deck, and leaving one out is a common under-estimate. **Pressure Per 3D Components:** Per-component pressure overrides. *Engineering influence.* Lets different components carry different pressures, which is how differing drag coefficients and height-varying exposure are represented — a tall pier sees higher pressure near its top than at its base, and an open truss has a very different drag characteristic from a solid barrier. Using one uniform pressure everywhere is simpler and, for a low bridge with similar components, usually adequate; for a tall structure it understates the load aloft. **FE Group:** The FE Group whose elements receive the resulting forces. *Engineering influence.* The wind force computed from the 3D geometry has to be delivered to the analysis model through these elements. If the group does not include the members under the exposed geometry, the computed force has nowhere to go and is silently lost — the classic failure mode for this object, and one that produces no warning at all. ## Verification * Sum the case's reactions and compare against pressure × projected area computed by hand. This is the definitive check that the load was both generated and delivered. * Confirm the exposed area used matches your expectation, including parapets, barriers and any superstructure depth. * Display the applied loads and confirm they appear on the intended members in the intended direction. * Plot a governing response — a pier base moment, say — against attack angle across the sweep, and confirm the peak is resolved rather than falling between analysed directions. * Check that transverse, longitudinal and skewed directions are all represented in the envelope. * Compare against a hand calculation for a simple case: transverse pressure × deck depth × span should approximate the total transverse force. ## Common mistakes * **An FE Group that does not cover the loaded region**, so the computed wind force is silently lost. * **Omitting parapets, barriers or signage** from the exposed components, understating transverse load. * **Analysing only one or two directions**, missing the governing skew — particularly on curved and skewed bridges. * **Entering a wind speed rather than a pressure**, or a pressure that has not had the code's exposure and gust factors applied. * **Applying one uniform pressure to a tall structure**, understating the load near the top. * **Assuming this case covers aerodynamic stability.** It does not; flutter and vortex shedding need a separate assessment. * **Forgetting to envelope** the swept directions and reporting only the last one analysed. # Pushover \[FEA] Pushover holds the **Pushover Case**, a nonlinear static procedure that pushes the structure with an incrementally increasing lateral load or displacement and produces a capacity curve of base shear against displacement. It shows the sequence in which members yield, the ductility available before collapse, and the lateral strength - none of which a linear analysis can reveal. Two things determine whether the result is meaningful. The model must actually contain nonlinearity: plastic hinges on the members expected to yield, or inelastic line elements. And the analysis must use **displacement control** if you need the softening branch, because a force-controlled analysis cannot pass the peak of the capacity curve. # Pushover Cases \[FEA] A Pushover case is a nonlinear static procedure: the structure is pushed by an incrementally increasing lateral load or displacement until a target is reached, producing a **capacity curve** of base shear against displacement. It shows the sequence in which members yield, the ductility available before collapse, and the lateral strength — none of which a linear analysis can reveal. Pushover **controls the solution** and reads the model's nonlinear ingredients (plastic hinges, material nonlinearity, geometric stiffness). It generates load through the pattern it pushes with. {% hint style="warning" %} A pushover case is only meaningful if the model actually contains nonlinearity — plastic hinges on the members expected to yield, or inelastic line elements. Pushing a purely elastic model produces a straight line that reveals nothing about capacity. {% endhint %} ## Control **Reference Node:** The node whose displacement is monitored and controlled — conventionally a point at the top of the structure, at the deck level or the centre of mass. *Engineering influence.* This node defines the horizontal axis of the capacity curve, so the whole result is expressed relative to it. Choosing a node that is not representative — one on a locally flexible member, or one that barely moves in the pushed direction — produces a capacity curve that misrepresents the structure's global behaviour, and in displacement control it can prevent the analysis progressing at all. **Reference Direction:** The direction the reference displacement is measured in. **Control CoorSys:** An optional coordinate system for the reference direction, so a skewed structure can be pushed along its own axes rather than the global ones. *Engineering influence.* For a skewed or curved bridge the governing direction is usually not a global axis; pushing along global X on a skewed bridge pushes partly across the bents and produces a mixed response that is hard to interpret. Several directions are normally checked. **Reference Displacement:** The target displacement the analysis pushes to. *Engineering influence.* This sets how far the capacity curve extends. Too small a target stops the analysis before the structure yields significantly, producing a curve that looks linear and uninformative; too large a target pushes far past collapse, where results are meaningless but harmless. It should reach at least the code's target displacement for the seismic demand being assessed. **Max # of Steps:** The maximum number of increments used to reach the target. *Engineering influence.* More steps resolve the capacity curve more finely and follow the changing stiffness through each yielding event more accurately, at proportionally more run time. Too few steps jump over the formation of hinges, so the curve misses the knee where yielding begins and the sequence of hinge formation is lost. If a pushover fails to converge, increasing steps is usually the first remedy. **Initial Load Factor:** The load factor applied at the first step. **Load Factor Increment:** How much the load factor increases each step. *Engineering influence, both.* These govern force-controlled stepping. A large increment reaches the target quickly but can step across a yielding event and fail to converge; a small one is robust and slow. Note that a purely force-controlled analysis **cannot pass a peak** in the capacity curve — once the structure begins to soften, no increase in load is possible and the analysis stops. Capturing post-peak, softening behaviour requires displacement control. **Displacement-Controlled Steps:** Whether stepping is controlled by displacement rather than by load. *Engineering influence.* This is the parameter that determines whether you can see the descending branch. **Displacement control** imposes the movement and reports the force required, so it follows the capacity curve through and past the peak into softening — which is where ductility and collapse behaviour are assessed. **Force control** cannot do this and terminates at the peak. For any pushover intended to assess ductility, displacement control is the correct choice. ## Nonlinear **Nonlinear:** Whether the case is solved nonlinearly. *Engineering influence.* Effectively mandatory for a meaningful pushover — with it off, hinges never form, materials never yield, and the "capacity curve" is a straight line whose slope is just the elastic stiffness. **# of Iterations:** The iteration limit within each step. Raising it allows a slowly-converging step near a yielding event to succeed; it does not make a converged answer more accurate. **Force Tolerance:** The out-of-balance force below which a step is accepted as converged. *Engineering influence.* Defines what counts as equilibrium. Loosening it eases convergence at the cost of accepting residual out-of-balance force — which in a pushover is particularly misleading, because the residual can masquerade as capacity the structure does not have. Set it relative to the base shear magnitudes in your model. ## Settings **Structure Group:** The part of the structure active for this case. Leave empty for the whole model. **Is Active:** Whether the case is solved. Inactive cases are skipped silently. ## Verification * Plot the capacity curve. It should show an initial elastic slope, a knee as hinges form, and a plateau or descending branch. A straight line means nothing yielded — check that hinges exist and that Nonlinear is on. * Confirm the initial elastic slope matches the structure's elastic lateral stiffness from a linear case. * Check the **sequence** of hinge formation against engineering expectation; hinges should form where the design intends them, typically at column tops and bases rather than in the deck. * Confirm the analysis reached the target displacement rather than stopping early on non-convergence. * Re-run with more steps and confirm the curve is stable. * Compare base shear at yield against a hand plastic-mechanism calculation. * Check that the reference node's displacement is representative by comparing it with other points on the structure. ## Common mistakes * **No hinges or nonlinear members in the model**, producing a straight-line "capacity" curve. * **Force control used to assess ductility**, so the analysis stops at the peak and never shows the softening branch. * **A target displacement too small** to reach yielding, making the structure look elastic. * **A poorly chosen reference node** — locally flexible, or barely moving in the pushed direction. * **Too few steps**, stepping over hinge formation and losing the sequence. * **Loosening the force tolerance to force convergence**, accepting residual out-of-balance force as capacity. * **Pushing only along global axes** on a skewed or curved bridge, missing the governing direction. * **Reading results past the point where the analysis stopped converging** and treating them as valid. # Dynamic Loads \[FEA] Dynamic Loads holds the objects used for modal, seismic and transient analysis. **Eigenvalue & RSA Cases** compute natural periods and mode shapes, and - when response spectrum curves are assigned - combine the modal responses into peak seismic demand. **Response Spectrum Curves** define the design spectrum those cases look modes up on. **Time History Functions** hold a tabulated excitation record, and **Time History Cases** integrate the equation of motion step by step, which is what you need when the timing of the response matters or when nonlinear links dissipate energy. **Support Motions** prescribe a displacement record at an individual support joint. Several of them on one Time History Case give multi-support (spatially varying) excitation - different ground motion at different supports, which is what a bridge long enough for wave passage, incoherence or differing site conditions actually sees. Uniform excitation cannot produce differential-support demand at all, since moving every support together is rigid-body translation. **Nodal Mass** adds concentrated mass at a joint for inertia that exists on the real structure but is not carried by any modelled element - barriers, utilities, equipment. Mass is the thing to get right first in this branch: every period scales with it, and every dynamic result follows from the periods. Note that nodal mass values are entered as **weights**, which the solver divides by gravity. # Response Spectrum Curves \[FEA] A Response Spectrum Curve is the design spectrum: the peak acceleration a single-degree-of-freedom oscillator of a given period experiences under the design earthquake. The RSA case looks up each mode's period on this curve, scales the mode by the resulting spectral acceleration, and combines the modal responses. The curve is **input data only**. It adds nothing to stiffness or mass and generates no load until an Eigenvalue & RSA case references it. {% hint style="danger" %} **A curve with no points produces a spectral acceleration of zero at every period**, so the RSA case returns exactly zero displacements and forces — with no error and no warning. If an RSA case reports zero response, check this first: it is far more often an empty curve than a structure that does not respond. {% endhint %} ## Data **Period/Frequency:** Whether the curve's X axis is expressed as **period** (seconds) or **frequency** (Hz). *Engineering influence.* The two are reciprocals, so selecting the wrong one does not merely rescale the curve — it **reverses** it, mapping long-period modes onto the short-period end of the spectrum and vice versa. The result is not obviously wrong: a plausible set of forces comes out, but the flexible modes are assigned the accelerations belonging to stiff ones. Design spectra are most often published against period; check which convention your source uses. **Points/Equations:** Whether the curve is defined by tabulated points or by a code equation. *Engineering influence.* Tabulated points are explicit and reviewable, which suits a site-specific spectrum. An equation form generates the curve from code parameters and stays consistent if those parameters change. Neither is more accurate; the equation form is less prone to transcription error, the tabulated form easier to audit against a published figure. **Period/Frequency vs Acceleration:** The tabulated curve itself — the pairs of X value and spectral acceleration. *Engineering influence.* This is the substance of the object. Its shape drives everything: a design spectrum characteristically has a short-period ramp, a constant-acceleration plateau, and a descending branch beyond a corner period. **Where the structure's fundamental period falls on that shape governs the demand** — a period on the plateau attracts the maximum acceleration, while a longer period on the descending branch attracts substantially less. This is exactly why base isolation works, and why a small error in modelled stiffness can move a structure between two very different parts of the curve. The tabulated range must **cover the structure's periods**. Values beyond the last tabulated point are not extrapolated meaningfully, so a curve that stops at 2 seconds applied to a structure with a 4-second isolated period will not give sensible demand for that mode. Include enough range at both ends. Interpolation between points is linear, so a curve defined with too few points cuts corners on the plateau and can under- or over-state acceleration for a period that falls between them. **Units matter and are easy to get wrong**: a spectrum published in **g** must be converted to the model's acceleration units, or scaled through the RSA case's direction scale factor. A spectrum left in g in a model expecting in/s² understates demand by a factor of \~386. Results sensitive to it: every RSA force, displacement and reaction, in direct proportion. ## Verification * **Plot the curve** and compare it against the published design spectrum. Shape errors, unit errors and reversed axes are all obvious visually and nearly invisible in a table. * Confirm the curve contains points at all before running an RSA case. * Check the X-axis convention against the source, and confirm the plateau is at short periods rather than long ones — a reversed axis puts it at the wrong end. * Confirm the tabulated range spans the structure's periods, including the longest mode of interest. * Check the peak spectral acceleration against the expected value for the site — typically a few times the peak ground acceleration. * Verify units by hand: read the acceleration at the fundamental period, multiply by the participating mass, and compare against the reported base shear. * Cross-check an RSA result against a time-history analysis using a record compatible with the spectrum; they should be the same order of magnitude. ## Common mistakes * **An empty curve**, giving an RSA case that reports zero everywhere with no error. * **Period and frequency interchanged**, reversing the spectrum and assigning stiff-mode accelerations to flexible modes. * **Leaving the spectrum in g** in a model whose acceleration units are not g, understating demand by a large factor. * **A tabulated range that does not cover the structure's periods**, particularly for isolated or long-period structures. * **Too few points**, so linear interpolation cuts across the plateau or the corner. * **Using the same spectrum for the vertical direction** without the reduction the code requires. * **Transcribing a spectrum from a figure** without plotting the result to check it. # Nodal Mass \[FEA] A Nodal Mass object places a concentrated (lumped) mass at a single node so that it contributes to the global mass matrix. It represents inertia that exists on the real bridge but is not carried by any modelled element with self-weight — barriers, railings, utilities, signs, ballast, machinery, or a superstructure segment that has been condensed away. Nodal Mass affects **mass only**. It adds nothing to the stiffness matrix, applies no static load, and produces no reactions in a static case. It is read by eigenvalue/modal, response-spectrum and time-history cases; a linear static case ignores it entirely. {% hint style="info" %} **All six values are entered as WEIGHTS, not masses.** The solver divides every entry by the **Gravity** constant of the analysis case that consumes it (`mass = value / Gravity`). Enter the weight of the item in force units and let the program convert. Leaving Gravity blank or zero on the case is safe — it is treated as "unset" and falls back to standard gravity in the project's length unit — but an explicitly *wrong* Gravity scales every nodal mass in the model. {% endhint %} ## General **Analysis Case:** The eigenvalue/RSA or time-history case this mass belongs to. This is a **selection** parameter, not a physical one: a case assembles the Nodal Mass objects whose Analysis Case points at it, **or** that are defined as its children in the object tree. A mass created from this sheet is a project-level object, so for it the Analysis Case field is the only thing connecting it to a case — **left empty, it participates in no case at all** and is silently ignored, appearing in no nodal-mass count and changing no period. (A mass nested under a case in the tree, which the agent API and ParamML authoring can produce, is picked up through that parent relationship instead and will show an empty Analysis Case here while still being used.) Set it as soon as you create the row. To apply the same physical mass to several cases, duplicate the row and point each copy at its own case. **Node:** The joint the lumped mass is attached to. This is a **connectivity** parameter: it selects which six rows of the global mass matrix receive the contribution — it does not create a node or move one. The mass acts at the node's own location, so an eccentric item (a barrier whose centre of gravity sits outboard of the girder line) is only represented correctly if you either attach it to a node at that offset or supply the corresponding rotational terms below. Define together with the weights; a Nodal Mass with no Node is skipped silently during assembly. If the node is a slave of a rigid diaphragm, the in-plane translational contribution is redistributed onto the master joint through the diaphragm transform, so the mass still participates — it simply appears on the master's equations. Verify by displaying the node and confirming the mass marker sits at the intended joint. **Fx:** Weight generating translational inertia along **global X**. Divided by Gravity to give the mass placed on the node's X translational DOF. *Engineering influence.* Increasing Fx lowers the natural frequencies of every mode with X participation and raises that node's modal displacement amplitude; the effect on any individual mode depends on the mode shape, so a mass sitting near a nodal point of a given mode may change it very little. A value of zero means no mass in X — not "inherit from self-weight". Negative values are not physical; the solver takes the absolute value, so a sign error will not be reported as an error. Fx does not affect stiffness, static results, or member design. Results sensitive to it: periods, mode shapes, modal participation factors, and therefore all response-spectrum and time-history output. Unrealistically large values drive the structure toward a rigid-body mode and can make the eigen solver converge slowly or return spurious low-frequency modes. **Fy:** Weight generating translational inertia along **global Y**. Same conversion and behaviour as Fx, on the Y translational DOF. **Fz:** Weight generating translational inertia along **global Z** (vertical in the default orientation). Same conversion and behaviour as Fx. For an ordinary object that simply has weight, set **Fx = Fy = Fz** to that weight — inertia is direction-independent for a point mass. Specifying them separately is for cases where you deliberately want directional mass, such as sloshing or entrained-fluid idealizations, or when you are matching a reference model that reported only one direction. **Mx:** Weight-based rotational inertia about **global X** — that is, mass moment of inertia multiplied by Gravity, in force × length² units. Divided by Gravity to give the rotational mass on the node's Rx DOF. *Engineering influence.* Rotational terms matter when the lumped item is physically extended rather than point-like, or is offset from the node: a barrier along the deck edge, a heavy cross-girder, or a condensed pier cap. Increasing Mx lowers the frequency of torsional and rocking modes about X while leaving pure translational modes largely unchanged. Zero means the item is treated as a point mass with no rotational inertia, which is conservative for frequency in some cases and unconservative in others — it is not automatically safe. These terms are only meaningful if the model actually has rotational DOFs at that joint: on a node whose rotations are fully restrained, or in a model built entirely from truss elements, Mx is ignored. **My:** Weight-based rotational inertia about **global Y**. Same conversion and behaviour as Mx. **Mz:** Weight-based rotational inertia about **global Z**. Same conversion and behaviour as Mx. ## Verification * Run the eigenvalue case and read the **System Mass (from Nodes)** lines the solver reports for each global direction. They echo the total translational mass assembled from Nodal Mass objects, converted back to force units — compare against the sum of the weights you entered. (The assembled value also carries the analysis state's own scale factor, so treat this as an order-of-magnitude and proportionality check rather than an exact equality unless that scale is 1.) * Check the **# of Nodal Mass** column on the Eigenvalue & RSA case; it counts the objects that case actually picked up. A count lower than expected almost always means an empty **Analysis Case** field on one of the rows. * Compare periods before and after adding the mass. The fundamental period should lengthen; if it does not move at all, the mass is either not being read, sitting on a restrained DOF, or located at a nodal point of that mode. * Check modal participating mass ratios — added mass that participates will show up there. * For a simple case, hand-check against `T = 2π√(m/k)` using the tributary stiffness at the node. * Confirm against a benchmark model with a known lumped mass before trusting a large production model. ## Common mistakes * **Entering a mass instead of a weight.** The value is divided by Gravity. Entering mass units understates the inertia by a factor of g, which shortens periods and typically *reduces* computed seismic demand — an unconservative error that no warning will catch. * **Entering a Gravity value in the wrong length unit** on the eigenvalue or time-history case — e.g. 32.2 (ft/s²) in a model whose internal length unit is inches, where 386.09 is expected. This scales every nodal mass by \~12 and is not flagged. Leaving it blank is safer than guessing. * **Double-counting.** Modelling a barrier as elements with self-weight *and* adding its weight as Nodal Mass. Nodal Mass supplements the structure's own mass; it does not replace it. * **Leaving Analysis Case empty.** This is the most common way a nodal mass silently does nothing: the case only collects masses that point at it. Confirm with the **# of Nodal Mass** column. * **Setting only Fz.** A vertical-only mass leaves the item weightless in the horizontal directions, which is usually wrong for seismic work — lateral periods come out too short. * **Omitting rotational terms for an eccentric or extended item**, then being surprised that torsional modes are too stiff. * **Attaching the mass to a node that is fully restrained**, where it can never participate. # Eigenvalue & Rsa Cases An Eigenvalue case computes the structure's natural periods and mode shapes — the free-vibration properties that govern all of its dynamic behaviour. Adding response spectrum curves turns the same case into a **Response Spectrum Analysis (RSA)**, which combines the modal responses against a design spectrum to estimate peak seismic demand without integrating in time. The case reads **mass** from the model (self-weight plus Nodal Mass objects assigned to it) and **stiffness** from the current model state. It generates no load of its own; RSA produces a set of peak responses rather than a single equilibrium solution. {% hint style="warning" %} **RSA results are peak magnitudes, not a snapshot.** They are combined statistically across modes, so the reported values do not occur simultaneously and are not in equilibrium: reactions will not sum to any applied load, and signs are conventionally positive. Do not expect a check that works for a static case to work here. {% endhint %} ## Modal Parameters **Analysis Type:** Selects what the case computes — a normal modal extraction or a buckling analysis. *Engineering influence.* Modal extraction solves the free-vibration eigenproblem for periods and mode shapes. Buckling instead solves for the load factor at which the structure becomes unstable under the applied load pattern, and requires the Applied Load and Buckling Load Factor fields below. The two share the machinery but answer completely different questions. **# of Mode Shapes:** The number of modes to extract. *Engineering influence.* Too few modes truncates the response and **understates** demand, most noticeably in the stiff directions and near supports where high-frequency modes contribute. The standard acceptance criterion is that the retained modes capture at least about **90% of the participating mass** in each direction of interest — check the participating mass ratios rather than picking a number. Increasing the count costs solution time and never makes the answer worse. A value of 0 extracts nothing and the case cannot solve. **Gravity:** The gravitational constant in the model's length units per second squared, used to convert **weights** into masses. *Engineering influence.* This scales the entire mass matrix, so an incorrect value shifts every period by `√` of the error and invalidates the whole analysis. Leaving it blank or zero is safe — it falls back to standard gravity in the project's length unit — but an explicitly wrong value (32.2 in an inch model, where 386.09 is expected) rescales everything by a factor of twelve with no warning. **Type of Modes:** The extraction method — Eigen, or one of the Ritz variants (WYD, LWYD, QSRV). *Engineering influence.* **Eigen** vectors are the true natural modes and are what you want when the physical periods matter. **Ritz** vectors are load-dependent: they are generated from a specific load pattern and concentrate on the modes that pattern actually excites, so for the same number of vectors they typically capture far more participating mass than eigen modes do. For seismic work Ritz vectors usually give better results for fewer vectors; for reporting natural frequencies, use Eigen. Ritz methods require the **Applied Load** below to define the pattern. **Applied Load (Ritz / Buckling):** The load case that supplies the pattern for Ritz vector generation, or the load pattern whose buckling factor is sought. *Engineering influence.* For Ritz, the vectors are tuned to this pattern, so it should represent the loading the analysis is about — a poor choice produces vectors that miss the response of interest. For buckling, this defines the load whose multiplier the analysis reports; the buckling factor is meaningless without knowing which load it multiplies. **Pre-stress Load (Stress-Stiffened Modal):** A load case whose axial forces are used to build a geometric stiffness that modifies the modal solution. *Engineering influence.* Axial force changes a member's effective bending stiffness: tension stiffens, compression softens. Including a prestress or dead-load case here produces **stress-stiffened** modal results, which matter for cables and stays (whose stiffness comes almost entirely from tension) and for slender compression members (whose periods lengthen under load). Leaving it empty analyses the unstressed structure, which for a cable-stayed bridge gives periods that are far too long. **Pre-stress Load Factor:** A multiplier on the prestress load used for stress stiffening. Scales how much geometric stiffening is included; 1 uses the case as-is. **Centering Frequency (Ritz QSRV Method):** The frequency the QSRV Ritz method centres its vector generation around. Only meaningful for that method; set it near the frequency range that dominates the response of interest. **Buckling Load Factor:** Reports the computed factor by which the Applied Load must be multiplied to cause buckling. *Engineering influence.* This is **output**. A factor below 1 means the structure buckles under less than the applied load; a large factor means buckling is not critical. Interpretation depends entirely on which load case was applied — the same structure has different factors for different patterns. Linear buckling overestimates capacity for real, imperfect structures, so the factor is an upper bound. ## RSA Curves **Curve in Dir. 1 / 2 / 3:** The response spectrum applied in each of the three directions. **Scale in Dir. 1 / 2 / 3:** A multiplier on each curve. *Engineering influence.* A case with **no curves assigned is a pure modal analysis** — it reports periods and mode shapes and no seismic demand. Assigning curves turns on the RSA combination. The scales apply code-required factors — importance factors, response modification, or the reduced factor commonly applied to the vertical component. Response scales linearly with them. Directions 1 and 2 are usually the two horizontal directions with the same spectrum, and direction 3 the vertical with a reduced one. {% hint style="danger" %} An RSA case whose curve contains **no points** produces spectral accelerations of zero and therefore **zero displacements and forces** — with no error. A result of exactly zero from an RSA case is almost always an empty curve, not a structure that does not respond. {% endhint %} **Dir. Angle:** The angle between the spectrum's direction 1 and the global X axis. *Engineering influence.* Rotates the excitation directions, which is how a skewed bridge is analysed along and across its bearing lines rather than along the global axes. For a skewed or curved structure the response varies with this angle, and codes commonly require several angles to be checked because the governing direction is not obvious. ## RSA Combination **Damping Ratio:** The modal damping assumed when combining. *Engineering influence.* Damping is embedded in the spectrum itself, and this value governs the **correlation** between modes in the CQC combination: higher damping increases correlation between closely-spaced modes and generally increases the combined result. The default 0.05 (5%) matches the damping most design spectra are published for. Using a value inconsistent with the spectrum's basis double-counts or omits damping. **Modal Comb. Method:** How responses from different modes are combined — CQC, SRSS, ABS, or the ten-percent rule. *Engineering influence.* **SRSS** (square root of sum of squares) assumes modes are independent and under-predicts when periods are closely spaced. **CQC** (complete quadratic combination) accounts for cross-correlation between close modes and is the general-purpose choice; it reduces to SRSS when modes are well separated. **ABS** (absolute sum) assumes all modes peak together — very conservative and rarely required. Structures with closely-spaced modes, which includes most skewed and curved bridges, are exactly where the choice matters. **Spatial Comb. Method:** How the three directional results are combined — typically ABS, SRSS or CQC3. *Engineering influence.* This implements the directional-combination rule the code requires (the familiar 100%/30% style rules, or SRSS). **CQC3** additionally searches over the angle of incidence to find the critical orientation, which is valuable for skewed structures where the governing direction is not aligned with the model axes. ABS is the most conservative. **γ – (CQC3):** The ratio between the two horizontal spectra used by the CQC3 method. Only meaningful when CQC3 is selected. ## Mass Source **Self Mass Factor:** A multiplier on the mass derived from the structure's own self-weight. *Engineering influence.* Codes commonly require a portion of live load to be included in seismic mass, or a factor applied to superimposed dead load. A factor of 1 uses the structural self-weight as-is; 0 removes it entirely, leaving only Nodal Mass contributions — which produces a nearly massless model with implausibly short periods. **Mass Case 1–5:** Load cases whose applied vertical load is converted into additional mass for this analysis. **Mass Case 1–5 Factor:** The multiplier applied to each of those cases when converting its load to mass. *Engineering influence, both.* Self-weight alone is rarely the whole seismic mass. Superimposed dead load, ballast, equipment applied as surface load, and the code-required fraction of live load are all applied as *loads* rather than modelled as structure, and this is how they contribute inertia — the same case can act as a gravity load in the static analysis and as mass here, without being modelled twice. The factor is where the code's fraction is expressed: a live-load case included at 0.2 contributes a fifth of its load as mass. A factor of 0 contributes nothing, so a Mass Case named but left at zero factor is a silent omission. Leaving all five empty means the mass is self-weight plus Nodal Mass only, which for most bridges **understates** the seismic mass. Adding mass lengthens periods, and because spectral ordinates fall with period beyond the plateau, the effect on force demand can go either way — it is not conservative in one direction. Take care not to double-count load that is already carried by modelled elements with density. **# of Nodal Mass:** Reports how many Nodal Mass objects this case actually picked up. **Output, not input.** *Engineering influence.* This is the verification field for nodal mass. A count lower than expected almost always means a Nodal Mass row has no Analysis Case assigned, since a case only collects masses that point at it. ## Settings **Structure Group:** The part of the structure active for this case. Leave empty for the whole model. **Is Active:** Whether the case is solved. Inactive cases are skipped silently. ## Verification * Check the periods against expectation or a hand estimate before trusting anything downstream. A fundamental period that is wildly off means mass or stiffness is wrong, and every RSA result inherits that error. * Check **modal participating mass ratios** reach about 90% in each direction; if not, increase the mode count. * Animate the mode shapes and confirm they are physically sensible — a first mode that is a local vibration of one member rather than global movement usually means a missing connection. * Confirm **# of Nodal Mass** matches the number of mass objects you created. * Confirm total model mass against a hand take-off. * For RSA, verify the spectrum curve actually contains points and plot it. * Compare CQC against SRSS; a large difference indicates closely-spaced modes and confirms CQC is the right choice. * For a stress-stiffened case, compare periods with and without the prestress load; cables should stiffen markedly. ## Common mistakes * **An empty response spectrum curve**, producing exactly zero displacements and forces with no error. * **Too few modes**, understating demand — especially near supports. * **Wrong Gravity value**, rescaling the entire mass matrix and every period. * **Nodal Mass objects with no Analysis Case assigned**, so they are silently excluded. Check the count. * **Expecting RSA results to be in equilibrium.** They are statistically combined peaks; reactions will not sum to an applied load. * **Using SRSS on a structure with closely-spaced modes**, under-predicting the combination. * **Omitting the prestress load for a cable-stayed structure**, giving periods far too long. * **Self Mass Factor at zero**, leaving a nearly massless model. * **No Mass Cases named**, omitting superimposed dead load from the seismic mass entirely — or naming one and leaving its factor at zero, which contributes nothing. * **Checking only the global axis directions** on a skewed bridge, missing the governing angle. # Time History Functions \[FEA] A Time History Function is a tabulated record of a quantity against time — most often a ground acceleration accelerogram, but equally a forcing function for a machine, a blast, or any prescribed excitation. It carries the shape of the excitation; the Time History Case decides how that shape is applied, scaled by gravity, and integrated. The function itself is **input data only**. It adds nothing to stiffness or mass and generates no load until a Time History Case references it. ## General **Time vs Value:** The tabulated record — a series of (time, value) pairs. Time is in seconds and must increase monotonically; the value is whatever the record measures, most commonly ground acceleration in **g**. This is the substance of the object. The solver interpolates linearly between the tabulated points, so the sampling interval of the record sets the highest frequency the excitation can actually represent: a record sampled at 0.02 s cannot carry meaningful content above about 25 Hz, no matter how finely the analysis is stepped. Do not resample a coarse record to a fine interval and assume higher-frequency content has been recovered — interpolation adds points, not information. The record's own length determines the default analysis duration. Records that do not start and end near zero introduce an artificial initial or terminal transient; most published accelerograms are already baseline-corrected, but a hand-built or truncated record may not be. *Engineering influence.* The response is driven entirely by the interaction between this record's frequency content and the structure's periods. A record with strong energy near a structural period produces resonant amplification; the same record applied to a structure with different periods can produce an order-of-magnitude different response. This is why several records are normally run rather than one. Results sensitive to it: everything the case produces — displacements, member forces, reactions, and their peaks. **Scale:** A multiplier applied to every tabulated Y value before it is used. The default of **386.4** converts a record given in **g** into in/s² for a kip-inch model. If your record is already in the model's acceleration units, set this to **1** — otherwise the excitation is overstated by a factor of \~386 and the analysis will produce absurd displacements. *Engineering influence.* Scale acts linearly on the excitation, and for a linear structure the response scales linearly with it: doubling Scale doubles displacements and member forces. This makes it the natural place to scale a record to a target design intensity, or to apply a code-required scaling factor. In a **nonlinear** case (FNA with nonlinear links) that proportionality no longer holds — the response may change disproportionately once links gap, yield, or slip. A value of zero means no excitation and a trivially zero response. A negative value reverses the sign of the record, which is a legitimate way to check sign sensitivity in a non-symmetric structure. Note this is a **unit-and-intensity** conversion combined in one number. If you both need to convert from g and apply a design factor, multiply them together here. {% hint style="warning" %} Scale and the case's **Gravity** are different things and are not interchangeable. Scale converts the record's own values; Gravity converts nodal *weights* into masses. Setting the correct value in one does not compensate for a wrong value in the other. {% endhint %} ## Verification * Plot the tabulated record and confirm its shape, peak value, and duration match the source accelerogram. A record read in with a mis-parsed delimiter usually shows up immediately as a visually wrong plot. * Check the peak value after scaling: for a record in g with the default Scale, peak × 386.4 should be the peak acceleration in in/s². Compare against the record's documented PGA. * Confirm the time column increases monotonically and the sampling interval is what you expect. * Run a short trial case and confirm the response builds and decays in step with the record rather than starting abruptly. * Compare the computed peak response against a response-spectrum analysis using a spectrum derived from the same record — they should be of the same order. ## Common mistakes * **Leaving Scale at 386.4 for a record already in model acceleration units**, inflating the excitation by \~386×. The tell-tale is displacements that are physically impossible. * **Setting Scale to 1 for a record in g**, understating the excitation by the same factor — the more dangerous direction, because the results look plausible. * **Using a record whose sampling interval is coarser than the output step** and assuming the analysis resolves the difference. * **A record with a non-zero first value**, producing a step input and an artificial initial transient. * **Reusing one record for all directions and all sites** — real assessments require a suite of records, and single-record conclusions are not defensible. * **Editing the record's units and its scale factor at the same time** and losing track of which conversion has already been applied. # Time History Cases \[FEA] A Time History Case integrates the equation of motion step by step and produces the structure's response as a function of time, rather than a single enveloped peak. Use it when the *timing* of the response matters: when peaks in different members occur at different instants, when damping or nonlinear links dissipate energy over the record, or when a response-spectrum analysis is not accepted because modal combination rules discard phase. The case reads mass from the model (self-weight plus Nodal Mass objects pointed at it), reads the excitation from a Time History Function, and marches forward in time. ## Solution **Solution Method:** Selects the integration strategy. This is the parameter that determines which of the other fields matter, so set it first. | Method | Integrator | Damping input | Nonlinear links | | ---------- | ------------------------------------------------------------------ | ---------------- | ---------------- | | **Modal** | Nigam–Jennings piecewise-exact recurrence on decoupled modal SDOFs | Damping Ratio | no — linear only | | **Direct** | average-acceleration Newmark (γ=½, β=¼), full system | Rayleigh α and β | no | | **FNA** | modal basis with iterated link forces | Damping Ratio | **yes** | *Engineering influence.* **Modal** is the cheapest and, for a linear structure whose response is captured by a manageable number of modes, it is exact for a piecewise-linear excitation — accuracy is limited by how many modes you retain, not by the time step. **Direct** integrates the full system and therefore captures all modes without truncation, at much greater cost, and its accuracy *is* governed by the step size. **FNA** is the method to choose when the model contains nonlinear links (gaps, hooks, isolators): Modal and Direct treat those links with their linear stiffness and will not reproduce gapping or yielding at all. Choosing Modal for a model with nonlinear links does not raise an error — it silently analyses a linearized structure. This is the most consequential setting on the object. {% hint style="danger" %} **FNA corrects nonlinear `FESpring` links only.** Nonlinear behaviour authored directly on an **FENode support** — a gap, hook or nonlinear curve on the node's own DOF — is assembled at its linearized stiffness and stays permanently linear even under FNA. A node gap will not open or close. Model any support that must behave nonlinearly as a **zero-length FESpring** between two coincident nodes instead. The solver detects this and reports it, so read the case messages rather than assuming. Two further FNA limitations are reported the same way: nonlinear links combined with a **rigid diaphragm** or other DOF transform can produce incomplete link residuals, and running FNA under consistent mass makes the modal mass and participation approximate. In both cases benchmark before relying on the result. {% endhint %} ## Modal **# of Modes (Modal):** The number of modes extracted and superposed. Used by **Modal** and **FNA**; ignored by **Direct**. *Engineering influence.* Too few modes truncates the response: high-frequency content, and the stiff-direction response in particular, is simply absent, which typically **understates** member forces near supports. The usual acceptance criterion is that the retained modes capture at least about 90% of the participating mass in each direction of interest — check the modal participating mass ratios rather than guessing a number. Increasing the count costs eigen-solution time and always improves (or leaves unchanged) the fidelity of the superposition; it never makes the answer worse. A value of 0 means no modes, and a Modal or FNA case cannot solve — the case is skipped. ## Excitation **Gravity:** The gravitational constant, in the model's length unit per second squared, used to convert nodal **weights** into masses. Leaving it blank or zero is safe — it falls back to standard gravity in the project's length unit (386.09 in/s² for an inch model). An explicitly wrong value rescales the entire mass matrix, shifting every period and invalidating the whole analysis. It does not scale the excitation record; that is the function's own **Scale**. **Ground Motion:** The Time History Function supplying the excitation. This is a **connectivity / selection** parameter — without it the case has nothing to integrate and the solve is skipped. Define together with Direction and the function's Scale. Changing the record changes everything about the result; the structure's periods are unaffected. **Direction:** The global direction (X, Y or Z) the ground motion is applied in. The excitation is applied as a uniform base acceleration in that direction, so the load on each mass is proportional to that mass. Choose the direction that governs — for most bridges the transverse direction controls substructure demand — and run each direction as its own case rather than expecting one case to cover all. A record applied in a direction with little participating mass produces a small, misleading response. Both parameters describe a **uniform** base motion — every support moving identically and in phase. For a bridge long enough that the seismic wave reaches one pier appreciably later than another, or whose supports sit on different soils, that assumption removes the differential-support demand entirely: moving every support together is rigid-body translation and generates no member force. To model spatially varying ground motion instead, leave Ground Motion **empty** and attach [Support Motions](https://github.com/openbrim/platform/tree/master/docs/documentation/templates/openbrimfea/loads-fea/dynamic-loads-fea/support-motions-fea.md) — one prescribed displacement record per (joint, DOF), with an optional per-support time shift for wave passage. The two are mutually exclusive and the analysis enforces it: uniform base excitation reports displacements *relative* to the moving ground while support motions report *absolute* displacements, so a case carrying both is rejected rather than summing two different reference frames. Multi-support also requires Solution Method = **Direct** — Modal and FNA carry one participation factor per mode per direction, which cannot represent more than one uniform base motion, nor the pseudo-static response to differential movement at all. Direction is ignored on a multi-support case, since each Support Motion names its own DOF. **Output Step (s):** How often results are **saved** — the sampling interval of the stored response history and of the peak search. *Engineering influence.* A coarse output step can miss the true peak between saved samples, so reported maxima are slightly unconservative; it also loses the visual detail of the response history. A fine output step multiplies stored data volume, which on a large model is the practical limit. For Modal and FNA this is also the marching interval. Choose it small enough to resolve the shortest period of interest — a common rule is at least ten points per period of the highest mode that matters. **Integration Sub-Steps (Direct):** Whole number of Newmark steps taken per saved output step; **Direct only**, capped at 1000. This separates accuracy from storage. The march advances by `Output Step / N` while results are still saved every Output Step, so `N = 4` integrates four times more finely at no extra storage cost. Increase it when the Direct solution looks unstable or period-elongated but you do not want to store more data. A value of 1 (the default) integrates at the output step. It has no effect on Modal or FNA. **Duration (s):** How long to analyse. **0 means use the record's own length**, which is usually what you want. Setting a duration shorter than the record truncates the excitation and may cut off the peak entirely; setting it longer continues the analysis past the end of the record, which is a legitimate way to observe free-vibration decay and confirm the damping is behaving. **Save Response History (Direct):** Retains the full per-step response for the viewer. Turning it off keeps peak results while discarding the history, which is the pragmatic choice on large models where the stored history dominates project size. It does not change the computed answer — only what is kept. ## Damping **Damping Ratio (Modal):** A single modal damping ratio applied to **all** modes. Used by **Modal** and **FNA**; ignored by Direct. *Engineering influence.* Damping controls how quickly the response decays and strongly governs the peak in near-resonant conditions. Increasing it reduces peak response — sharply near resonance, only mildly away from it. A value of 0 means undamped: the response grows without bound at resonance and free vibration never decays, which is almost never realistic and is usually a data-entry slip. The default 0.05 (5%) is a common assumption for a bridge at moderate response levels; concrete at high strain, or a structure with energy-dissipating devices, warrants a different value, and codes often prescribe it. Because one ratio applies to every mode, this cannot represent a structure whose damping genuinely varies with frequency. **Rayleigh α (Direct, mass):** Mass-proportional damping coefficient in `C = αM + βK`. **Direct only.** **Rayleigh β (Direct, stiffness):** Stiffness-proportional damping coefficient in `C = αM + βK`. **Direct only.** *Engineering influence, both.* Rayleigh damping gives a damping ratio that varies with frequency: the α term damps **low** frequencies, the β term damps **high** frequencies, and the combination is exactly at the target ratio at only two frequencies, over-damping everything outside that band. Pick the two frequencies to bracket the modes that carry the response, then compute α and β from them — choosing round numbers without that calculation is the usual source of a Direct analysis that is inexplicably over- or under-damped compared with an equivalent Modal run. Both default to 0, which means an **undamped** Direct analysis. That is rarely intended and, unlike a missing modal damping ratio, it is easy to overlook because the fields sit on a different tab from the solution method. ## Mass Source **Mass Case 1 / Mass Case 2 / Mass Case 3:** Up to three load cases whose applied vertical load is converted into additional mass for this analysis. *Engineering influence.* The structure's own self-weight is always available as mass, but a seismic or vibration assessment usually has to include mass that is applied as *load* rather than modelled as structure — superimposed dead load, a code-required fraction of live load, ballast, or equipment represented as a surface load rather than as elements. Naming a case here converts its load into mass at the corresponding joints, so the same superimposed dead load can act as both a gravity load in the static cases and a mass contribution here without being modelled twice. Adding mass lengthens periods and, for a spectrum whose ordinates fall with period, can either raise or lower the force demand — the effect depends on where the structure sits on the spectrum, so it is not conservative in a single direction. Leaving all three empty means the only mass is the structure's self-weight plus any Nodal Mass objects assigned to the case. For most bridges that **understates** the seismic mass, because it omits the superimposed dead load entirely. Take care not to double-count: a load already represented by modelled elements with density should not also be named here. ## Settings **Structure Group:** The part of the structure active for this case, for staged or partial models. Leave empty to analyse the whole structure. **Is Active:** Whether the case runs. Inactive cases are skipped without error, which is convenient for keeping a suite of records in one project and running them selectively — and is also a common reason a case appears to produce no results. ## Verification * Run a modal analysis first and confirm the periods are sensible before trusting any time-history output. A time history built on a wrong mass or stiffness model is wrong everywhere. * Check modal participating mass against the retained mode count. * Compare the Modal and Direct solutions of the same linear model. They should agree closely; a significant difference usually means too few modes (Modal) or too coarse a step (Direct). * Compare the peak response against a response-spectrum analysis using a spectrum for the same record — same order of magnitude is expected. * Extend Duration past the record and confirm free vibration decays at the rate the damping implies. * Halve the Output Step, or raise Integration Sub-Steps, and confirm the peaks are stable. If they move materially, the step was too coarse. * For a nonlinear case, confirm link forces show the expected gapping or yielding rather than a linear response. ## Common mistakes * **Using Modal or Direct on a model with nonlinear links**, silently analysing a linearized structure. Use FNA. * **Expecting FNA to handle a nonlinear FENode support.** It corrects `FESpring` links only — model the support as a zero-length spring. The solver warns; read the case messages. * **Leaving Rayleigh α and β at zero in a Direct case**, producing an undamped analysis whose peaks are far above the Modal result — then "reconciling" the two by adjusting the wrong parameter. * **Retaining too few modes** and under-predicting force demands, particularly near supports. * **Setting Duration shorter than the record** and truncating before the strongest pulse. * **Assuming the case runs** when Is Active is off, or when no Ground Motion is assigned. * **Applying the record in one direction only** and treating that as a complete assessment. * **Confusing the function's Scale with the case's Gravity** — one scales the excitation, the other converts weights to mass. Getting either wrong rescales the answer without any warning. * **Reading peaks from a coarse Output Step** and reporting them as the true maxima. # Staged Construction \[FEA] Staged Construction models the erection sequence. Each **Stage** inherits the deformed, stressed state of its prior stage, activates or deactivates parts of the structure, applies its loads, and passes the resulting state forward. This matters because **the structure that carries each load is the structure that existed when the load was applied**. A girder erected simply supported and later made continuous carries its self-weight on the simple span forever, regardless of the finished geometry - and only a staged analysis reproduces that. **States** declare what is present at each stage and whether it contributes stiffness, weight, or both. **Loading** schedules existing load cases into stages. **Changes** modify object properties from a stage onward - releasing falsework, locking a bearing. **Prestressing** schedules tendon stressing operations. **Tendon Path Points** define the tendon geometry those operations act on. A staged result **should** differ from a single all-at-once analysis. If the two agree exactly, the staging is not taking effect. # Stages \[FEA] A Construction Stage represents one step in the erection sequence. Each stage inherits the deformed, stressed state of its prior stage, activates or deactivates parts of the structure, applies its loads, and passes the resulting state forward. This sequencing is what makes a staged analysis different from a single all-at-once solve: **the structure that carries each load is the structure that existed when that load was applied.** A girder erected simply supported and later made continuous carries its self-weight on the simple span forever, regardless of what the finished structure looks like — and only a staged analysis reproduces that. Stages **control the solution** and carry the accumulated state. They generate load only through the cases attached to them. ## Stage **Prior Stage:** The stage whose end state this stage begins from. *Engineering influence.* This defines the sequence. The first stage has none; every other stage names its predecessor, forming a chain. The chain is the analysis order, so a wrong prior stage silently reorders construction — applying a load to a structure that does not yet exist, or missing the locked-in forces from a step that should have preceded it. The chain does not have to be linear in intent: for **transient** loads such as wind or live load, select the final permanent stage as the prior stage, so the transient case acts on the completed structure and does not feed its effects into subsequent permanent stages. **Construction Day:** The day, on the project timeline, that this stage occurs. *Engineering influence.* This drives every time-dependent effect. The interval between a member's casting day and the day it is loaded determines its modulus and its creep; the interval between stages determines how much creep and shrinkage accumulate between them. Days that are wrong relative to one another misstate long-term deflection and the redistribution of force between stages — and because creep is strongly nonlinear in age at loading, errors early in the sequence matter more than errors late in it. Days must increase along the chain. A stage dated before its predecessor is not physically meaningful. **Temperature:** The ambient temperature during this stage. *Engineering influence.* Used by the time-dependent calculations, where curing temperature accelerates maturity, and as the reference condition for the stage. It is not a thermal load — a temperature *change* applied to the structure comes from a Temperature Load. **Humidity (%):** The relative humidity during this stage. *Engineering influence.* A primary input to CEB-FIP creep and shrinkage: drier conditions produce substantially more shrinkage and more creep. The default of 80% suits a temperate exposed environment; an enclosed or arid environment warrants a lower value and produces markedly larger long-term effects. This is a property of the **stage**, not of the material, which is where engineers often look for it first. **Const. Method:** The construction method used for distributing effects within the stage. *Engineering influence.* Describes how the work in this stage proceeds, which affects how load and stiffness are introduced across the elements activated in it — whether they all come into service together or progressively. The distinction matters most for long stages activating many elements at once. **Is Active:** Whether the stage is included in the analysis. *Engineering influence.* An inactive stage is skipped silently, and because stages form a chain, skipping one changes what every later stage inherits — the structure and the locked-in forces they start from. This is more consequential than deactivating an ordinary load case. **Load Type:** Classifies the stage's loading for combinations and code checks. It does not change the analysis; it changes which combinations pick the stage up. ## Time Dependent **Time Dependent Code:** The code basis used for the time-dependent calculations. **Time Dependent Elastic Modulus:** Whether the modulus develops with concrete age in this stage. **Concrete Creep Effect:** Whether creep is computed in this stage. **Concrete Shrinkage Effect:** Whether shrinkage is computed in this stage. **Steel Relaxation Effect:** Whether prestressing steel relaxation is computed in this stage. **PT Losses from Structure:** Whether elastic-shortening losses are computed in this stage. {% hint style="warning" %} Each of these must be enabled **both here and on the material** to take effect. Enabling it in only one place is the usual reason a staged model shows no creep or shrinkage at all — and the symptom is simply that long-term results equal short-term results, with nothing to indicate why. {% endhint %} *Engineering influence, all five.* Creep increases deflection over time and redistributes force toward members that creep less, which in a segmental or staged structure changes the final moment diagram substantially compared with the as-built one. Shrinkage produces tension in restrained members and differential strain in composite sections. Relaxation and PT loss both reduce effective prestress over time. Enabling them costs solution time; disabling them understates long-term deflection and, more importantly, misstates the final distribution of force — which is usually the reason for running a staged analysis in the first place. **Creep of Tensile Axial Force:** Whether creep is applied to members in axial tension. Defaults to off. Concrete in tension behaves differently from concrete in compression and is often cracked, so applying compression-derived creep to it is not generally appropriate; enable it only where the tensile creep behaviour is genuinely intended. ## Nonlinear **Nonlinear:** Whether this stage is solved nonlinearly. *Engineering influence.* Needed where the stage involves cables, gaps, one-sided members or significant geometric effects — a cable-stayed erection stage analysed linearly ignores the cable behaviour that governs it. Note this is set **per stage**, so a sequence can solve cheaply where behaviour is linear and nonlinearly only where it matters. **Maximum # of Iterations:** The iteration limit within each step of this stage. Raising it helps a slowly-converging stage succeed; it does not improve the accuracy of a converged answer. **Force Tolerance:** The out-of-balance force accepted as converged. Loosening it eases convergence while leaving residual out-of-balance force in the state that is **carried forward to every subsequent stage** — which is why sloppy tolerances are worse in staged analysis than in a single case. ## Verification * Step through the stages and confirm the structure activating at each one matches the erection sequence, using the 3D view. * Confirm construction days increase along the chain and that the intervals match the programme. * Check that each stage's prior stage is what you intend, particularly for transient-load stages, which should branch off the final permanent stage rather than sitting in the middle of the chain. * Compare the final staged result against a single all-at-once analysis. They **should** differ; if they are identical, the staging is not taking effect. * Run with time-dependent effects on and off and confirm long-term deflections differ. No difference means the switches are not enabled on both the stage and the material. * Check that locked-in forces carry forward: a member's force at the start of a stage should equal its force at the end of the prior one. * Confirm each stage converged rather than hitting its iteration limit. ## Common mistakes * **Time-dependent effects enabled on the stage but not the material** (or the reverse), so nothing happens and long-term equals short-term. * **A wrong prior stage**, silently reordering construction. * **Transient load stages inserted into the permanent chain**, so wind or live load effects are inherited by subsequent construction stages. * **Construction days that do not reflect the real programme**, misstating creep — with early errors mattering most. * **Humidity left at the default** in an environment that is materially drier, understating shrinkage. * **Deactivating a stage** and not realising every later stage now inherits a different structure. * **Loosening the force tolerance**, carrying residual out-of-balance force through the whole sequence. * **Comparing staged results against a one-shot analysis and assuming the difference is an error.** The difference is the point. # States \[FEA] A Structure State declares what is **present** at a given point in the construction sequence, and in what capacity. It associates an element or a group with a stage, and says whether that element contributes **stiffness**, **weight**, or both. This separation is the essence of staged analysis. A segment being lifted contributes weight but not stiffness; wet concrete loads the structure without stiffening it; falsework contributes stiffness but no permanent weight. States are how each of those is expressed. States **control activation** and can **generate load** through their weight factors. They add nothing themselves. ## Data **Load Case:** The case — normally the stage's case — this state applies in. A state with no case assigned takes effect nowhere. **Object:** The specific object whose presence is being declared. **Group:** The FE Group whose members are being declared present. Using a group is the normal approach for anything larger than a single element, because it keeps the state definitions to a manageable number as the model grows. *Engineering influence, both.* Together these are the **connectivity** side of the object: they select what is being activated. A group that resolves to nothing activates nothing, and the stage proceeds with less structure than intended — usually visible as a mechanism, a singular matrix, or deflections far larger than expected. Check the group's object count. **Has Stiffness?:** Whether the activated elements contribute to the stiffness matrix. *Engineering influence.* This is the parameter that distinguishes "load" from "structure". Setting it **off** while applying weight models material that is present but not yet structurally effective — wet concrete in a deck pour, a segment suspended from a crane, or ballast. The load reaches the structure while the element itself carries nothing. Setting it **on** brings the element into the load path from this stage onward, and from that point it attracts force according to its stiffness. **When** an element becomes stiff is decisive in a staged analysis: a deck made composite early carries a share of subsequent dead load, while the same deck made composite later does not, and the resulting stress distributions differ substantially. An element that never has stiffness in any state contributes only weight and never carries anything. **Weight Factor X / Y / Z:** Multipliers on the activated elements' self-weight in each global direction, for this state. *Engineering influence.* This is how the element's own weight is introduced at the right moment in the sequence. In a Z-up model, a factor of **−1** in Z applies full self-weight; **0** applies none. Getting these right is the most common source of error in staged models, in two directions. Applying weight in **more than one** state double-counts it — the element's self-weight is applied every time a state with a non-zero factor activates it, so a segment declared in several stages is weighed several times. Applying it in **none** leaves the element weightless for the whole analysis. Fractional factors have legitimate uses: applying part of a segment's weight as it is progressively lowered onto its bearings, or splitting a pour across stages. ## Verification * Step through the stages in the 3D view and confirm the active structure at each one matches the erection sequence. * Sum the reactions at the end of the sequence and compare against the total weight of the completed structure. A total that is too high means weight has been double-counted in overlapping states; too low means an element was never given a weight factor. * Check the object count of each group used by a state. * For an element intended to be present-but-not-stiff, confirm it carries essentially no force in that stage while its weight still appears in the reactions. * Confirm that composite action begins in the stage you intend, by checking when the deck starts attracting force. * Compare deflections at the end of the sequence against expectation; a member that never became stiff shows up as an unexpectedly flexible region. ## Common mistakes * **Applying self-weight in more than one state**, weighing the same element repeatedly. The total-reaction check is the only reliable way to catch this. * **Never applying self-weight**, leaving an element weightless throughout. * **Activating stiffness too early**, so a deck or a closure carries load it did not carry in reality. * **Activating stiffness too late**, leaving the structure unstable for a stage. * **A group that resolves to nothing**, activating no structure at all. * **Sign error on the weight factors**, applying self-weight upward. * **Forgetting the wet-concrete condition** — modelling a deck pour as immediately composite, which understates girder stress at the most critical moment in its life. # Loading \[FEA] A Loading entry attaches an existing load case to a construction stage, so that its loads are applied at that point in the sequence. It is the mechanism for everything beyond self-weight: erection equipment, temporary counterweights, superimposed dead load, barrier installation, and any load that belongs to a specific moment in the build. Loading entries **generate load** by scheduling an existing case. They define no loads of their own. {% hint style="info" %} The load's magnitude and distribution live in the **Analysis Case** it points at. This object only decides *when* that case is applied and *at what factor*. A case with no loads in it contributes nothing here. {% endhint %} ## Data **Construction Stage:** The stage the load is applied in. *Engineering influence.* This is what makes staged analysis meaningful: the load is applied to the structure **as it exists in that stage**, not to the completed structure. The same superimposed dead load applied before and after a deck becomes composite produces materially different girder stresses, because the section resisting it is different. Applying a load to a stage before the structure that should carry it has been activated puts the load onto an incomplete structure — sometimes producing enormous deflections, sometimes a mechanism, and sometimes just a quietly wrong distribution. A Loading entry with no stage assigned schedules nothing. **Case:** The analysis case whose loads are applied. *Engineering influence.* The **connectivity** parameter. Any case can be scheduled, which means a case can be applied in more than one stage — legitimate for a load genuinely applied repeatedly, and a double-count otherwise. **Factor:** The multiplier applied to the case in this stage. *Engineering influence.* Scales the case linearly. Its most important use is **partial application**: applying a fraction of a load in one stage and the remainder in a later one, which is how a progressive operation — lowering a segment onto its bearings, staged removal of falsework, a phased pour — is represented. The default is **0**, which means a Loading entry created but not given a factor applies **nothing**. This is a frequent and completely silent failure: the entry exists, the stage runs, and the load is absent. When splitting a case across stages, be clear whether your factors are **cumulative** or **incremental**. Applying 0.5 in one stage and 1.0 in the next applies a total of 1.5 unless the second is meant as the remaining increment — this is the same trap as staged cable stressing and it is worth writing the intended totals down before entering them. A negative factor removes load, which is how falsework release or the removal of a temporary counterweight is modelled. ## Verification * Sum the reactions at the end of the sequence and compare against the total load that should have been applied. This catches both the zero-factor trap and double-counting. * Confirm each Loading entry has a non-zero factor. * Step through the stages and confirm each load appears in the stage you intend, applied to the structure as it exists then. * Where a case is split across stages, add the factors and confirm the total is what you intend. * For a load applied before composite action, confirm the stress goes into the bare section rather than the composite one. * Check that removal operations (negative factors) reduce the reactions by the expected amount. ## Common mistakes * **Leaving the factor at its default of 0**, so the scheduled load does nothing at all. This is the single most common problem with this object. * **Scheduling the same case in several stages** unintentionally, multiplying the load. * **Confusing cumulative with incremental factors** when splitting a load across stages. * **Applying a load before the structure that carries it is active**, producing a distribution that is quietly wrong. * **Applying superimposed dead load in the wrong stage** relative to composite action, putting stress into the wrong section. * **Forgetting to remove temporary loads**, leaving falsework or counterweights in place for the rest of the sequence and into the final state. * **No construction stage assigned**, so nothing is scheduled. # Prestressing \[FEA] A Prestressing entry schedules a tendon stressing operation **at a specific construction stage**, so the analysis reproduces the real jacking sequence and the losses that depend on it. It uses the same underlying object as **Prestressing Loads** — the difference is context. In staged construction the stage decides *what structure* the prestress acts on and *when* in the timeline it is applied, both of which change the result substantially. Prestressing entries **generate load**. The magnitude comes from the **Tendon**; this object decides when it is applied, from which ends, and whether elastic-shortening loss is included. {% hint style="info" %} Staging is what makes prestress analysis realistic. A tendon stressed against a bare precast girder produces very different stresses from the same tendon stressed after the deck is composite, because the section resisting it differs. Only the stage assignment expresses that. {% endhint %} ## Stressing **Load Case:** The stage's case the prestress is applied in. *Engineering influence.* This places the stressing operation in the sequence, and it is the parameter that matters most on this object. Stressing a tendon in a stage before the concrete it acts on has been cast, or before it has gained the strength the design assumes, is not physically meaningful — and the analysis will not object. Stressing later than intended leaves the member unprestressed for loads applied in between, which is often the most critical condition for a precast girder. The stage also fixes the concrete **age**, which determines the modulus and therefore the elastic shortening, and the starting point from which creep and relaxation accumulate. **Tendon:** The tendon being stressed. With none assigned, nothing is applied. **Stressing at Start / Stressing at End:** The proportion of the tendon's jacking force applied from each end in this operation, **entered in this sheet as a percentage**. {% hint style="danger" %} **These are proportions, not yes/no switches.** Enter `100` (or `100%`) to stress fully from an end and `0` not to stress from it. The sheet divides what you type by 100, so entering `1` applies **1%** of the jacking force from that end — a 100× under-application that produces no error and quietly leaves the member almost unprestressed. {% endhint %} *Engineering influence.* Friction loss accumulates away from a stressing end, so one-end stressing gives an asymmetric force profile with its minimum at the far end, and both-end stressing gives a symmetric profile with substantially more force delivered to the far end. On a long tendon this materially changes the prestress at midlength. Anchor-set loss is applied at each end actually stressed. Intermediate values are how a **staged jacking sequence** is expressed — taking a tendon to part of its force in one stage and the remainder in a later one. Be clear whether your values are cumulative totals or increments. Setting both to 0 leaves the tendon unstressed in this stage. These must be consistent with the Tendon's own Jacking Method and jacking forces; nominating an end that carries no jacking force delivers nothing from it. **Instantaneous Elastic Shortening Loss:** Whether the immediate loss from the member shortening under compression is included. *Engineering influence.* In a staged, multi-tendon member this is a sequence effect: each stressing operation shortens the member and relieves strain in the tendons already stressed, so tendons stressed **early** lose the most and the last one stressed loses nothing from itself. Ignoring it overstates the prestress remaining, which is unconservative for serviceability tension checks and for camber. The effect grows with the number of stressing operations, so it matters most in heavily post-tensioned members. ## Verification * Step through the stages and confirm each tendon is stressed in the intended one, on a structure that exists and has gained strength. * Open **Prestressing Details…** on the tendon and confirm the force profile, including the anchor-set dips at the ends actually stressed. * Check the member's camber after each stressing stage; it should increase as tendons are stressed. * Confirm the concrete stresses at each stage stay within the allowable limits **for the age at that stage** — the critical check is often at transfer, not at service. * Compare the effective prestress at the final stage against a hand loss calculation. * Toggle elastic shortening loss and confirm the effect is a plausible percentage. * Confirm prestress carries forward into subsequent stages rather than being re-applied. ## Common mistakes * **Stressing in a stage before the concrete exists or has gained strength**, which the analysis accepts without complaint. * **Entering `1` in a stressing cell to mean "stress this end"**, applying 1% of the jacking force. The cells are percentages — enter `100`. * **Both stressing ends set to 0**, so the tendon is never stressed in that stage. * **Scheduling the same tendon in more than one stage** unintentionally, applying its prestress twice. * **Ignoring elastic shortening loss** in a member with several stressing operations. * **Checking stresses only at the final stage**, missing the transfer condition where a precast girder is most highly stressed and least mature. * **Stressing ends inconsistent with the Tendon's jacking definition**, delivering less than intended. * **Assuming one-end stressing is adequate on a long tendon**, leaving the far end under-stressed. --- [Next Page](/llms-full.txt/1)