SWBPIPE · The open manual
Part V · Validation ElsewhereV–1

Part V

Validation Elsewhere

A. Design here, validate there

SWBPIPE helps readers develop a design: route the line, arrange supports, try alternatives and understand the behavior. It does not judge code compliance or vouch for its results. When the design needs validation, it goes to the program your industry accepts. The code check is made there under your engineer’s judgment.

One seat of the accepted program can support validation of work developed by several designers. Current .mbf output is a bounded interchange smoke subset, not a complete or qualified transfer. Target version, record-family coverage and direct stable-ID carrying remain open. Other export packages also have their own bounds.

Part V · Validation ElsewhereV–2

B. The export today

The desktop .mbf panel renders a bounded smoke subset. It emits node coordinates, pipe connectivity and references, minimal support records, and load-case IDs/types. The text carries target IDs and load kinds; the sidecar maps source IDs to target IDs. It omits component records and does not carry the full physical model. Each package includes a sidecar ID map, loss report and diagnostics. Target version and record-family coverage remain unresolved; the package does not establish CAEPIPE compatibility.

Not yet exportedWhat to do in the receiving program
Pipe sizes and material propertiesEnter them.
Bends, tees, valves, flanges and reducersListed as omitted; add them.
Rests, springs, hangers, stops and gapsMinimal support records are listed as approximated. Do not infer detailed target behavior from them. Delete each approximate support and model the real support in the receiving program.
Temperatures, pressures, weights, forces and physical case definitionsLoad-case IDs/types are written, but full physical definitions are absent. Enter the operating conditions and build the physical load cases there.
Today

The current panel converts node coordinates to millimeters and records a conversion witness for each coordinate. This corrects the earlier US-coordinate label defect (Status). Until the transfer carries a qualified whole model, treat the file as a starting point. Examine the receiving model row by row. A desktop output gate can refuse the package even when a result remains readable. Stop that handoff if its output is refused. Read the route and standing finding before continuing.

1.Other exports.

Other surfaces prepare a straight-run PCF subset, native packages, CSV or JSON result exports, centerline geometry and local-detail handoffs. These packages have different input, loss and eligibility conditions. A package’s presence does not establish target compatibility or professional validation.

Current exact-route pressure-2 and pressure-source-1 results can reach three desktop outputs: result JSON, stress-neutral CSV/JSON and user rule checks. The native reader must admit the source and numerical standing. Pressure-source results with load/reference states remain ineligible; ordinary pressure-2 load/reference-state results can qualify. Reports, model-transfer packages and the other exact-route handoffs remain refused. Fresh report packages remain unavailable for all current results. Stored or copied source-result bytes alone do not supply the required live invocation binding (Status).

The separate retained-precision successor method remains dormant and is excluded from v0.1. Saved or copied result bytes do not supply the live native capture required by prepared successor policies. Prepared result JSON and stress-neutral policies admit a successor only with eligible standing and a live native capture. These preserved policies do not make it a current workbench feature. Other successor output surfaces remain refused.

2.How the export will be checked.

A complete interchange check must compare three representations: the defined problem, a model built by hand in the receiving program, and the exported model. Each feature must be identified as exact, approximate, omitted or untested. A file that opens does not establish faithful transfer. Current smoke-subset checks screen package structure and disclosed losses; they do not establish complete target execution or equivalence (Part VI).

Part V · Validation ElsewhereV–3

C. What changes when you validate

Equivalent models can give similar movements and loads in two programs, but their results need not be identical. Differences can arise from each program’s assumptions and implementation. Understanding those choices helps reconcile the results.

Compare the models before their results. Compare geometry, sizes, materials, support types and directions, and load cases, row by row.

SubjectWhat to expect
Shear deformationExact-contract straight members select Timoshenko or Euler–Bernoulli; new authoring defaults to Timoshenko. Realized arcs and pressure-free members remain Euler–Bernoulli. Compare the selected beam theory and shear factor with the receiving model. Omitting shear flexibility can increase stiffness and loads in short, heavy legs.
BendsThe validating program takes k and the SIFs from the code you select. Enter the same values here, or expect differences at every elbow. Today the ordinary route and pressure contract 3.0.0 support explicit curved_bend_macro_element mode with entered k; legacy mechanics_geometry_only uses the chord. Supported arc maxima now carry a declared enclosure; missing bounds and incomplete coverage remain withheld (Status).
PressureThe current exact contract is v3; v2 and legacy pressure are retired. V3 admits realized bends with entered k and the bounded joint pressure law with optional elastic tie rods. Explicit regions, closure transfer, E/ν and pressure basis are required. Compare represented pressure strain and thrust effects; Bourdon opening and pressure-dependent flexibility remain excluded (Status).
Section basisThe exact route uses nominal wall for stiffness and pipe-metal mass, reduced wall for the pressure bore, and separately identified nominal and reduced stress rows. Match the intended basis in the receiving model. The pressure-free route retains one effective-wall basis (Status).
ModulusThe code range uses its required reference modulus; hot reactions use the appropriate hot material basis. Model 0.6.0 records the selected material and thermal states explicitly. Solve comparable physical and material states before comparing results. Mixed-modulus mechanics combinations are withheld.
Springs and hangersA validating program may design hangers, select them from catalogs and apply preload. Compare only after entering the same rate and cold load, and note that SWBPIPE does not yet apply the preload (Status).
Friction and nonlinear supportsFriction results depend on the solution path and on how each program treats the sustained case. Compare runs without friction first.
Code stressesThe validating program computes the sustained stress, the displacement stress range and the occasional stresses, and compares them with allowables. SWBPIPE computes none of them.

1.A reconciliation order.

  • Weight only, with every support rigid: support loads should agree closely.
  • Thermal only, without friction and with nonlinear supports held in one state: movements and anchor loads should agree within the effect of shear deformation and bend modeling.
  • Then add pressure, springs, friction and nonlinear supports one at a time. Explain each change in the difference before adding the next.

Where the programs still disagree, the model in the validating program is the design basis under your engineer’s judgment.

Contents · Part IV · Part VI · The program: swbpipe.com · MIT license