> 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/box-culvert-workflow/loading-bc/live-load-through-fill-bc.md).

# Live Load Through Fill \[BC]

Live Load Through Fill applies the design truck axle and the design lane load to the top slab after they have spread through the fill, following AASHTO LRFD 3.6.1.2.6.

The tyre contact patch spreads outward with depth, so the axle arrives at the top slab as a pressure over an enlarged footprint rather than as a wheel line. The two wheels of an axle spread independently while their footprints are still apart, and merge into one rectangle carrying the whole axle once they touch — the interaction depth described in 3.6.1.2.6 and MnDOT LRFD 12.2.3, Figures 12.2.3.2 and 12.2.3.3. Both cases are generated and the applicable one is used for the entered fill depth.

Dynamic load allowance follows 3.6.2.2 for buried components, `IM = 33(1 − 0.125·D_E) ≥ 0`, so impact reduces with cover and vanishes beyond about 8 ft.

> Below 2 ft of fill, 3.6.1.2.6a directs that live load be distributed as for a bridge deck rather than by spreading through fill. This object always spreads, so check the cover before relying on it at shallow depths.

## General

**Box Culvert:** The culvert barrel this load is applied to. A selection is required. The spread footprint is applied to the barrel's top slab.

**Stage:** The construction stage this load is activated in. Leave it empty for a model that is not staged.

**Fill Data From \[Inputs/Culvert Fill]:** Where the fill depth comes from — this object's own field, or the Culvert Fill registered on the selected barrel. See Vertical Earth for the full behaviour.

**Fill Depth Above Top Slab:** The cover depth, which drives the spread footprint, the wheel interaction check and the dynamic load allowance. Shown only when Fill Data From is set to Inputs, where a value is required.

**Design Axle Load:** The axle load spread through the fill. The default is the 32 kip design truck rear axle.

**Design Lane Pressure (0.64 klf over 10 ft):** The design lane load expressed as a pressure — 0.64 klf distributed over a 10 ft lane width. It is applied uniformly to the top slab rather than spread, since a distributed lane load does not have a contact patch to spread.

**Live Load Distribution Factor Through Fill:** The rate at which the tyre patch spreads with depth, per 3.6.1.2.6. The value must lie between 1.0 and 1.15; 1.15 applies where the fill is select granular material and 1.0 otherwise.

**Multiple Presence Factor (Single Lane):** The multiple presence factor from Table 3.6.1.1.2-1. The default of 1.2 is the single-loaded-lane value, which usually governs a culvert because one axle centred over the barrel produces the highest local pressure.

**Wheel Gage Across the Axle:** The transverse spacing between the two wheels of the axle, measured centre to centre. It determines the depth at which the two spread footprints touch and merge. The default is the AASHTO 6 ft design gage. Must be positive.


---

# 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/box-culvert-workflow/loading-bc/live-load-through-fill-bc.md?ask=<question>&goal=<user_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.
