> For the complete documentation index, see [llms.txt](https://docs.openbrim.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openbrim.org/templates/openbrimfea/loads-fea/live-loads-fea/influence-surfaces-roadways.md). # 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 places each unit load on the element it finds, whatever the Type. Type does three things on top of that: it gives a new path sensible **defaults** (a Line starts with one 12 ft design lane of width instead of zero), it files the path under **Influence Lines** rather than **Influence Surfaces** in the analysis-case list, and — for a Line only — it moves unit loads that fall beside the lines onto them (below). 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. A grid point within an FELine's section width lands on that line directly. With Type set to **Line**, a grid point **beside** the lines — the path is usually wider than the section — is moved onto the **nearest line**, at the foot of its perpendicular on the member's own axis (end offsets included), and its offset from there is kept as a moment on the line (a torque for a wheel to one side). The load the line receives is statically the same as the unit load where the grid put it, so every wheel of a vehicle loads the line, wherever it stands across the path. The rules for which line takes it: * Only lines the vehicle travels **along** are candidates: within 25° of the path's direction at that point (the nearest segment of its centreline, so a curve drawn as straight segments keeps every segment) and within 15° of the path's plane. Pier columns, caps, cross-frames, and end and pier diaphragms on supports skewed up to 65° are not candidates. Still, keep the Loaded Group to the lines the traffic rides on: a parallel line above or below the deck (a truss chord) is a candidate too. * A line farther from the point than the path's full width is not taken. * Past the **free end** of the line a point stays unloaded — the vehicle is off the structure. Past an **interior joint** (the outside of a kink where a curve is drawn as straight segments) it goes onto the joint, with its offset along the line kept in the moment. A joint counts as interior only where another candidate line carries on from it within 25°; a second line on the same two nodes, or a member meeting it at an angle, leaves the end free. * With several lines in the group (a grillage of FELines), a point between two girders goes wholly to the nearer one, and a point exactly midway is shared equally between them. Model a deck if the load must be shared by the lever rule. Give such a path an increment across of at most half the girder spacing, or a girder between the path's centre and its edges gets no row of its own. With Type left at **Surface**, nothing is moved: a point that misses every element loads nothing, which is right on a deck (the point is off it) and on the library's spine and girder-only workflows. 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. * **Draw the path along the lines, one lane wide for a girder line.** Grid points past the end of the line stay unloaded. Every row of a Line path loads the line in full, so a path two lanes wide puts two lanes on the one line — right for a spine standing for the whole deck, wrong for a single girder analysed with distribution factors. The compile log says so when a Line path fits two or more lanes; paths set to Line before this default was one lane were seeded 24 ft wide and keep that width. A Line path must be at least as wide as its narrowest design lane — if no lane fits, the compile stops and names the lane, instead of returning zero live 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 reads zero on a Surface path, or goes to the nearest loadable girder on a Line path. 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.* Each unit load is still placed on the element it lands on. A **Line** also moves the unit loads that land beside the lines onto the nearest line (see above), and starts with a usable path width — one design lane — instead of zero, which is the difference between an influence line that works and one that silently places no load. Type also decides 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openbrim.org/templates/openbrimfea/loads-fea/live-loads-fea/influence-surfaces-roadways.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.