Part V, Validation Elsewhere — 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 exported	What to do in the receiving program
Pipe sizes and material properties	Enter them.
Bends, tees, valves, flanges and reducers	Listed as omitted; add them.
Rests, springs, hangers, stops and gaps	Minimal 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 definitions	Load-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.

Every desktop output surface refuses current exact-route pressure-1 and pressure-source-1 results, including their load/reference-state cases. Both identities remain readable with the Rust product reader’s verdict and standing. The former load-reference-1 and load-reference-source-1 identities are retired with pressure v2. Current Python AnalysisRun and stress-neutral paths accept the current exact identities under their own checks; that does not open a desktop output surface. Fresh desktop report packages remain unavailable. Historical result readability does not grant current, rule, report or export eligibility.

Retained-precision F2a D1 remains registered development/test work without a public production caller. 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. 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.

Subject	What to expect
Shear deformation	Exact-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.
Bends	The 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. Arc governing stress maxima remain withheld (Status).
Pressure	The current exact contract is v3; v2 and legacy pressure are retired. V3 admits realized bends with entered k and the bounded untied-joint pressure law. 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 basis	The 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).
Modulus	The code range uses its required reference modulus; hot reactions use the appropriate hot material basis. Model 0.5.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 hangers	A 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 supports	Friction results depend on the solution path and on how each program treats the sustained case. Compare runs without friction first.
Code stresses	The 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