How to Organize MBS Reaction Data into a Usable Table

A reaction print is a list. A usable table is a contract: every row is a support, every column has a name, units are visible, and a reviewer can find uplift without hunting. PEB jobs stall when foundations receive a screenshot, a PDF with wrapped headers, or a spreadsheet that still contains trial cases. Organizing MBS reaction data is the step that turns How to Read and Use MBS Column Reactions into something another discipline can check.

The table does not have to be fancy. It has to be stable. Grid marks should match the CAD plan. Interior frames and endwalls should not share unlabeled rows. Compression and uplift should not share a cell. If you automate the extract, the table schema is what the parser writes into; see How Engineering Automation Can Process MBS Output Files. StruTools MBS Reactions exists to produce that kind of reviewable table rather than another unmarked export.

This guide proposes a column layout, a grouping order, and a few rules about envelopes. It is not a code-prescribed format. Your office may already have a foundation handoff sheet. If that sheet already carries units, cases, and grid marks, keep it and use this article as a checklist. If the current 'table' is a paste from a report, replace it before the next approval issue. PEB Reaction Data Workflow: From Software Output to Engineering Review then uses this table as the object that gets signed.

Group rows the way the building is grouped

Sort order is a review tool. If the table jumps from grid A1 to an endwall post to a crane column, nobody will notice a missing support.

• Group by frame line, then by grid along that line.
• Keep left-hand and right-hand columns of a clear-span frame on consecutive rows.
• Put all endwall posts in their own block.
• Put crane-bay columns in their own block if the building has a crane.
• Keep a trailing list of supports that did not map, and treat that list as a defect until it is empty.

One row, one case—or a labeled envelope pair

Wide tables that put every combination in extra columns become unreadable. Long tables that repeat the support ID for each case stay checkable.

Preferred layout: each row is support + case. Filters then show 'all uplift cases' or 'gravity only' without destroying coincident shears and moments. If you must issue an envelope, use a separate pair of columns—governing compression and governing uplift—each with a case-name column beside it. Never replace coincident components with three unrelated maxima in one row.

Service and strength values belong in separate tables or in a clearly marked column group. Mixing them is a foundation error waiting for a busy afternoon.

Headers must carry units, signs, and axes

A header that says 'R' or 'F3' is not a header. Write the engineering name, the unit, and the positive direction.

Example header language

Use plain language your foundation group already speaks, then map it to the MBS component once on the cover: 'Fz (kN), compression positive, global vertical' is usable. 'F3' is not.

Sign convention block

A two-line note above the table is enough: positive axial, positive shears, moment sense. Copy the same note onto the approval sheet that reprints the table.

Sanity columns worth adding

A few extra columns catch errors before they leave the analysis group.

• Tributary gravity estimate versus modeled gravity axial, as a percentage or a flag
• Uplift flag when vertical force reverses
• Pinned/fixed base as modeled
• Notes for supports that were added for analysis only and do not exist on the foundation plan

What not to put in the working table

The working table is for handoff. The calculation book can hold everything else.

• Every unused combination the solver printed
• Member forces that are not support reactions
• Color formatting as the only way to show uplift (colors die in print and in PDF)
• Merged cells that break sorting and parsing
• Hand-typed overrides without a note and a date

From table to drawing and from table to tool

CAD should read this table, not a second informal list. If you use a dedicated extract tool, the tool should write this schema, not a private layout.

StruTools MBS Reactions is meant to land in a reviewable table rather than leave you retyping. After review, the same table feeds From MBS Output Files to PEB Approval Drawings. If a later automation step parses the table, merged headers and hidden columns will break it—keep the schema boring on purpose.

Building the first table on a job

Do this once with a typical interior frame before you process the whole building.

1. List supports on the current grid and mark interior, endwall, and special.
2. Choose the load cases the foundation standard actually uses.
3. Create headers with names, units, and sign notes.
4. Fill one frame by hand from the issued extract and sanity-check gravity.
5. Fill the rest, by tool or by controlled copy, using the same headers.
6. Clear the unmapped-support list or write why a support is analysis-only.
7. Issue the table with source file and reviewer name in the header block.

Engineering tips

• Keep an unmapped-support list until it is empty.
• Use data validation on the case-name column so 'W' and 'Wind' cannot both exist.
• Print a PDF of the table for the calculation book; do not rely on a live workbook as the only record.
• If you convert units, keep original values in adjacent columns during review.
• Name the file with project and analysis issue, not 'reactions final final'.

Common mistakes

One cell that says 180 / -40

Compression and uplift in one cell cannot be filtered, cannot be parsed, and will be misread on a phone. Two rows or two columns.

Sorting by magnitude and calling it a review

The largest number is not necessarily the governing foundation case. Review by support, then by case.

Deleting rows that 'looked unused'

If a column exists on the plan, it stays in the table even if its reaction is small. Missing rows are how supports disappear.

Reaction table acceptance checklist

A table that fails this list is not ready for foundations or CAD.

• Every plan support has at least one row.
• Grid IDs match the CAD plan.
• Interior, endwall, and special frames are labeled.
• Headers include units and sign convention.
• Each row has a load-case name.
• Uplift is not hidden in the same cell as compression.
• Source file and analysis issue are in the header block.
• A gravity sanity check exists for a typical column.
• Unmapped supports are resolved.
• Reviewer name and date are present.

Frequently asked questions

Should moments be omitted for pinned-base PEB frames?

Only if the model is pinned and the office standard omits them. If the model was fixed, the moments belong in the table until someone changes the support definition and re-runs.

Is a separate table required for each load combination?

No. A long table with a case column is usually easier. Separate sheets are fine if your foundation group insists, as long as headers stay identical.

Can we keep the table only in CAD?

CAD can display it. The record copy should still live with the calculations so it can be revised when the model changes without opening twenty drawings.

How does Excel automation fit?

Use Excel as the review surface. Let StruTools MBS Reactions or a tested parser fill it. Avoid a second hidden parse inside the workbook.

Boring tables survive reviews

The best reaction table is slightly dull: stable IDs, visible units, one case per row, and an audit header. That dullness is what lets foundations and CAD check the same object.

Read the values with How to Read and Use MBS Column Reactions, then move the signed table through PEB Reaction Data Workflow: From Software Output to Engineering Review.