> 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/concrete-u-girder-bridge-workflow/load-rating-cug/concrete-girder-load-rating-cug.md).

# Concrete Girder Load Rating \[CUG]

## General

**Load Rating Template**: This parameter can be used to assign a previously generated Load Rating Template.

**Girder**: This parameter can be used to specify the girder for which the load rating will be processed accordingly.

**Station**: Specify the station for which the load rating will be performed.

**Design Section w Rebars(or Tendons) \[Section from 3D/Override Section(NonComposite)/Override Section(Composite)]:** Selects the section used for load rating. **Section from 3D** derives the section from the 3D girder model; **Override Section (NonComposite)** uses the override section without the deck contribution; **Override Section (Composite)** uses the override section with the deck included.

**Override Design Section (Noncomposite):** Section used for load rating when Design Section w Rebars (or Tendons) is set to an Override option. The section may be imported or chosen from previously defined sections under Properties > Sections.

**Override Design Section**: If the "Design Section w Rebars (or Tendons)" parameter is specified with an option other than "Section from 3D," this parameter can be used to specify the section to be overridden. The section to be used for load rating can either be imported or chosen from previously defined ones under Properties > Sections.

**Stages for Stress Checks**:

* **Stage**: Specify a stage to be used for stress checks.
* **Loss Computation Time Frame \[Segment Erection/Between Transfer and Deck Placement/After Deck Placement]**:

**Station**: This parameter can be used to specify the station at which the code check will be performed.

**Relative Position (readonly)**: The relative position of the code check station, based on the total length of the girder, will be presented to the user.

**Effective Web Width**:

**PDF Name (Export):** This parameter allows the name of the code check document to be modified when saving it as a PDF. When renaming the file, special attention must be given to the text characters on the [linked](https://docs.openbrim.org/faq/general/faq-illegal-chars) page, as certain characters may interfere with parametric equations and lead to unexpected results.

## Shear Reinforcements

**Shear Reinforcement Data \[Use Girder’s Rebar Data/ Override Rebar Data]:** Users can specify whether to use the rebar data previously defined in the girder object or to override the shear reinforcement data with the parameters below for use in code checks.

**Rebar Profile:** If the shear reinforcement data is to be overridden, the rebar profile can be specified using this parameter.

**Rebar Spacing:** This parameter can be used to specify the spacing between rebar elements.

**Number of Legs:** This parameter can be used to define the number of rebar legs in the shear reinforcement.

**Transverse Rebar Material:** This parameter can be used to specify the material used for the shear reinforcement.


---

# 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/concrete-u-girder-bridge-workflow/load-rating-cug/concrete-girder-load-rating-cug.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.