MBS Output Quality Checks Before Using Results in Design Workflows

Pretty reports are not checked reports. An MBS run can print member sizes and column reactions while still carrying the wrong eave height, a missing wind case, or a support that was never applied. Quality checks exist to catch those problems before the numbers enter a foundation sketch, a reaction table, or an approval elevation. Skipping the checks is how a trial model becomes 'the design' because it was the file that was open on Friday afternoon.

This article is a gate, not a tutorial on clicking through every report. It assumes you can already name the output families in Understanding MBS Output Files for PEB Engineering and can read a reaction in How to Read and Use MBS Column Reactions. The checks are ordered: completeness first, then geometry, then loads, then supports, then a small numerical sanity test. Failures stop the handoff. They do not get a footnote on the transmittal and a hope that CAD will notice.

Automation does not replace this gate. A parser such as StruTools MBS Reactions should refuse incomplete extracts, but it cannot know that the architectural plan changed yesterday. People still compare geometry against the current plan issue before anyone copies a force. After the gate passes, the signed package moves into PEB Reaction Data Workflow: From Software Output to Engineering Review and, if sheets are next, into From MBS Output Files to PEB Approval Drawings.

Completeness: did this run actually finish?

The first check is boring and it catches more bad handoffs than any later numerical trick.

• Solver or diagnostic messages were read, not assumed clean.
• The reports you require for issue all exist: geometry, loads, members, reactions.
• The files sit in the issued folder, not in a scratch directory.
• Software version on the cover matches the version that wrote the files.

Geometry: is this still the building on the current plan?

Architectural issues move. Models lag. The quality check is the moment you notice.

Compare width, length, eave height, roof slope, bay spacing, and crane locations with the drawing issue this output claims to support. If CAD already changed a bay and analysis did not, you do not have a package. Either the model updates or the drawing rolls back. Do not split the difference in a mark-up cloud.

Confirm interior versus endwall frame types. Confirm that openings you see on the plan were either modeled or explicitly excluded in a note. Silent omission of a large opening is a load-path error, not a detailing preference.

Loads and combinations: what was actually applied?

Read the load list from the output, not from memory of what you meant to apply last week.

• Dead, collateral, live or roof live as required by the basis of design
• Wind cases, including uplift-producing combinations
• Snow or rain if the site and code require them
• Seismic if required, with the same edition as the calculations
• Crane cases if a crane exists on the architectural issue
• Service versus strength combinations labeled so they cannot be mixed later

Supports and reaction coverage

A complete run can still have the wrong supports. That error shows up as moments you did not want or as columns that never appear in the extract.

Support definition

Pinned versus fixed versus otherwise restrained must match the intended base-plate and foundation scheme. Unexpected moments at a 'pinned' base are a stop.

Coverage

Every column on the current grid has a reaction row, or a written reason it is not a foundation support. Use How to Organize MBS Reaction Data into a Usable Table as the coverage test, not a glance at the print.

A short numerical sanity test

You are not re-doing the analysis by hand. You are asking whether the output is in the right world.

• Gravity axial on a typical interior column versus a tributary-area estimate.
• Uplift present on windward or roof-uplift cases if the building should see it.
• Left and right columns of a symmetric gravity-only frame in the same order of magnitude.
• Units consistent with the cover sheet; a 1000-times error is usually kN versus N or kip versus lb.

Who signs, and what happens on fail

A checklist without an owner is decoration. Name the reviewer and name the action.

The engineer who owns the model signs that the checks passed for a stated drawing issue. Failures go back to modeling, not to CAD with a warning. File the signed checklist with the output package described in How Engineering Teams Can Organize MBS Files and Project Outputs.

If you use StruTools MBS Reactions, run it only on output that passed this gate. Parsing a failed run just industrializes the failure.

Running the gate on every issued model

Same order, every job, so reviewers do not skip the dull steps.

1. Open the issued folder and confirm the cover lists version, date, and intended drawing issue.
2. Read diagnostics; abort if the run is incomplete.
3. Compare geometry with the current architectural and CAD grid.
4. Read the load-combination list against the basis of design.
5. Check support types and reaction coverage.
6. Run the short numerical sanity test on a typical frame.
7. Sign the checklist or return the model with a written fail reason.

Engineering tips

• Keep the checklist one page so it actually gets filled.
• Compare geometry from the output, not from your memory of the model screen.
• If two people must sign—analyst and checker—say so. One name is the minimum.
• Treat a changed crane capacity as a failed geometry/load check, not as a CAD note.
• Store failed runs in a trial folder so they cannot be re-issued by accident.

Common mistakes

Checking only member ratios

A tidy design ratio on a rafter does not prove wind was applied or that the eave height is current. Ratios come after completeness and geometry.

Using last project's checklist without the crane line

Checklists have to match this building. A warehouse with a crane fails a checklist that never mentions crane cases.

Signing after CAD has already issued

The gate is before the handoff. A signature on a package that is already in the client's inbox is theatre.

MBS output quality-check list

Print this with the output cover. Unchecked means not issued.

• Diagnostics read; run complete.
• Required reports present (geometry, loads, members, reactions).
• Software version recorded.
• Width, eave, slope, and bays match the cited plan issue.
• Interior and endwall frame types confirmed.
• Load list matches the basis of design, including crane if present.
• Service and strength combinations are distinguishable.
• Support types match intended bases.
• Every plan column has a reaction row or a written exception.
• Gravity sanity test recorded for a typical column.
• Reviewer name, date, and drawing issue on the cover.

Frequently asked questions

How long should this check take?

On a typical rectangular PEB, long enough to compare geometry, read the load list, and sanity-check one frame—not long enough to re-analyze the building by hand. If it takes all day, the output package is disorganized.

Can the CAD lead do this check?

CAD can help confirm grid and eave height. Completeness, load list, and support definitions remain engineering checks.

What if only reactions changed and members did not?

Still run the gate. Support and load changes can move reactions without a dramatic member-size change. Issue a new analysis package.

Does a parser replace the gravity sanity test?

No. A parser confirms the extract is complete. The sanity test asks whether the numbers belong to this building.

The gate is the product

MBS output becomes design input only after someone proves the run is complete, the geometry is current, the loads are the intended loads, and the reactions cover the plan. Everything after that—tables, CAD, foundations—is a copy of a checked package.

When the gate passes, file the package as in How Engineering Teams Can Organize MBS Files and Project Outputs and continue with PEB Reaction Data Workflow: From Software Output to Engineering Review.