Interoperability starts with meaning
AEC Magazine’s BHoM feature describes an approach to exchanging information through common objects and software adapters. For a structural team, this raises a practical question: what meaning survives the journey? A beam that appears in the correct position is only one part of an analytical exchange. The test below is an independent, hypothetical review method, not a claim about any connector’s capabilities.
Build a deliberately small test frame
Use a two-bay, two-storey frame with a short cantilever and one offset member. Give every member a stable review identifier. Record section, material, orientation and intended analytical connectivity in a small reference schedule. Include one intentional difference in end conditions so the test can detect whether it is lost. Select the expected behaviour with the structural engineer responsible for the analysis. A simple model with deliberate edge cases is easier to diagnose than an entire building.
Separate physical and analytical positions
The physical face of a column and the analytical centreline describe different things. Record where the analytical node is expected to sit and how offsets are represented. Check whether intersecting-looking lines actually share nodes. Review member local axes, since an orientation change can affect the interpretation of loads and releases. Do not repair every visible gap by automatic snapping: that can create connections that the intended structural system does not contain.
Read diagram notes
- Identity and geometry
- Objects, units and offsets
- Analytical meaning
- Connectivity, axes and releases
- Change behaviour
- Update, deletion and duplicate checks
Reconcile properties and boundary conditions
Prepare a field-by-field comparison of the receiving model against the agreed reference. Check units, section dimensions, material identifiers, supports, releases and any transferred load information that falls within scope. Mark unsupported fields as unsupported, rather than leaving them silently blank. Distinguish an absent value from an explicit zero. When a tool replaces a section with a nearby catalogue entry, require an engineering decision; a familiar-looking label is not evidence of equivalence.
Test a change as well as the first transfer
Change one section, move one node and remove one member in the source test frame. Exchange again. Check whether the receiver updates existing entities, duplicates them or leaves deleted objects behind. Record how identifiers behave. If the process creates a new analytical model on every exchange, document that constraint and the reconciliation work it requires. A repeatable process should make changes visible instead of asking a reviewer to remember the previous state.
Keep results within the test boundary
Passing this frame does not validate every feature in a future building model. Extend the test when introducing a new element type, material, connection assumption or export version. Store the source and receiving files, mapping settings, software versions and review record together. Treat unexpected analytical behaviour as a reason to stop the exchange for investigation. Numerical plausibility alone cannot demonstrate that the intended structure has been modelled.
A useful acceptance record
For each check, record expected value, observed value, status, reviewer and evidence. Use clear outcomes such as accepted, rejected and outside this exchange scope. The BIM manager coordinates that record; the responsible structural engineer accepts structural assumptions. The practical deliverable is a small, repeatable exchange test with known limits. That is more useful than a general statement that two applications are compatible.