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.

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.

All desktop output surfaces refuse load/reference-state results, including load-reference-1 and load-reference-source-1. The result remains readable. Fresh desktop report packages are unavailable. Historical precision-1 results remain readable but are not Current, rule-, report- or export-eligible.

Retained-precision F2a D1 remains registered development/test work without a public production caller. Prepared result JSON and stress-neutral policies admit a successor only with eligible standing and a live native capture. This policy preparation does not activate the successor. 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 deformationThe ordinary SWBPIPE frame uses Euler–Bernoulli bending without shear deformation. A receiving program may include shear deformation. For the same imposed movement, omitting shear flexibility can increase stiffness and loads, especially 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 supports explicit curved_bend_macro_element mode with entered k; legacy mechanics_geometry_only uses the chord. Arc governing stress maxima remain withheld (Status).
PressurePrograms differ on pressure elongation (the Bourdon effect) and on the longitudinal pressure formula. Today nonzero legacy pressure is refused. The exact straight route requires its explicit contract, regions, terminal ownership, material pair and pressure basis; it excludes fitting/arc composition (Status).
ModulusThe code range uses its required reference modulus; hot reactions use the appropriate hot material basis. Model 0.4.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