A model represents the pipe centerline, with sizes, materials, components, supports and loads attached. SWBPIPE does not supply missing engineering inputs. A required value that is absent stops the solve. The diagnostic identifies the missing input.

1.Units and geometry.

Every quantity has an entered unit. Consumed values are converted to SI for the solve. The node table defines the model geometry, and the drawing follows those rows.

Put nodes at every change of direction, support, component and branch. Also put nodes at every change of size, material or temperature, and wherever you want a result. Long straight runs need no intermediate nodes for accuracy under the exact beam assumptions of end loads and consistent span loads. Intermediate nodes provide intermediate results.

2.Pipe sizes.

Each pipe has its nominal outside diameter and wall thickness, entered directly or through a defined section. For weight, give pipe, contents and insulation densities, and the insulation thickness. For the exact route, the allowance definitions also determine the pressure bore and contents area; identify the section basis below.

3.Materials.

Material inputs depend on the selected model contract. The ordinary route uses entered elastic and shear moduli and thermal expansion data. Enter these properties at the temperatures you need. When an ordinary case selects a temperature basis, it uses one named point or supported interpolation. It never extrapolates.

Exact pressure and model 0.6.0 load/reference states require explicit elastic modulus E and Poisson ratio ν. These routes derive the shear modulus.

Model 0.6.0 selects each member’s actual material basis explicitly. It uses base properties, an exact point or supported temperature interpolation. It refuses extrapolation. Installation, operating temperature and thermal/fit definitions are explicit states. Recorded shear modulus and expansion data do not substitute for E/ν. For a code range, the reference modulus basis is the value required by that code (Part II D).

4.Open, save and reopen.

The native desktop opens a model document through File > Open Model Document. A solve request containing separate model and material objects is not a desktop model document. File and shape checks refuse unsupported documents by name. A refused file or cancelled chooser leaves the session unchanged. Browser preview cannot open model files.

1. Open the model document. Resolve any named file or shape refusal before solving.
2. Check geometry, quantities, components, restraints, material states and load sources.
3. Select the solver mode and solve. Read the standing, coverage, diagnostics and solve proof.
4. Save the document as a local project. Examine the stored project and revision before any requested replacement.
5. Choose Replace, Save as a new project, or Cancel. Cancel keeps the stored project.
6. Reopen the saved project. Check its model and result standing before continuing.

Saving the same project needs no replacement prompt while its stored revision still matches this session’s last open or save. Another writer’s change requires a prompt. The store checks that revision and writes the project in one transaction. A further change before Replace is refused and prompts again. A timed-out write fails visibly.

Save as a new project assigns a new project ID. Its model hash changes, and the old ID’s solved run is not carried over. Opening a document adopts its entered data without filling missing engineering values. Saving can apply the declared persistence normalization. Reopening saved results does not establish current numerical eligibility.

Model each support as built, with its actual physical behavior. A shoe on a steel beam is a rest with friction. Lugs may also make the shoe a guide. A rod hanger carries tension only. A trunnion on a beam is a stub from the centerline to the support point, with a rest at its end.

A model needs enough restraint to prevent rigid-body movement in every direction. When numerical checks detect a mechanism or insufficient restraint, the solve is blocked. Diagnostics identify the detected problem. A solved result does not prove physical stability. Examine the largest movement and rotation in every case. Read the numerical admission and coverage limits.

Build the basic loads first. Then construct the cases needed for the code check. The following tables describe a line with one operating condition.

Each operating condition has its own OPE case. The expansion range is formed between the extreme states. Part II C and D explain this distinction.

SWBPIPE supplies no code tables. Enter flexibility factors, SIFs, component dimensions and allowables from the applicable codes and catalogs. For the B31 codes, use ASME B31J for SIFs and flexibility factors. Use owner and manufacturer data for components and hangers. The classical forms in Part II E provide a comparison for entered data.

The realized curved-bend mode uses k in stiffness and accepts a separately entered directional SIF pair for its intensified bending measure. It supplies no code-derived factors. Geometry-only bend markers and tee/branch records retain their equal-factor measure on supported adjacent straight ends; tee/branch ends must match the declared header or branch pipe reference. Each row uses its declared member section basis.

A realized bend uses its own directional measure on the arc; its presence does not add the geometry-marker measure to its straight neighbors. Neither measure multiplies stress by k or supplies a code stress. User formula criteria can evaluate intervals, but a formula gate is not standards approval. SWBPIPE supplies no built-in code classification or allowable. The code check is made in the program used for validation (Part V).

You can keep material, section, component and hanger data in private libraries. You can keep projects in a local store. These local data remain on your machine.

Check the model before reading its results. Short diagnostic runs can reveal model errors.

Read the numerical standing and coverage with the result. Nonlinear convergence is followed by a separate confirmation; cases that pass can publish checked member and support rows. An unestablished support state or missing member bound keeps Sensitive with a named reason. Convergence alone cannot produce checks passed (Status).

The Rust product reader supplies result interpretation and numerical standing to native, WebAssembly and Python consumers. Check the current model, selected mode and reader findings. A saved result, copied hash or readable historical record does not establish current standing. Captured-source routes, including pressure-source-1, require their captured invocation and validation of the exact result bytes. Retired v2 result identities are refused.

1.Memory and interrupted solves.

Ordinary desktop solves use capped local worker processes. The shared pool defaults to 75% of physical RAM. Each worker’s budget defaults to the smaller of 12 GiB and the pool. Lower budgets are allowed; larger worker budgets remain unqualified. The pool belongs to one app process.

Read the memory panel’s pool, budget, reservations, queue and refusal reason. Admission and worker growth need current free-memory headroom and normal memory pressure. Unknown or stale host information can prevent admission. A loaded machine can refuse a solve that previously ran. A resource refusal does not change the requested solver mode or numerical route.

Cancel a queued job to prevent its worker from starting. Cancelling a running job terminates its worker. Wait for the job’s cancellation status; reservations release after the worker exits and is reaped. Session reset also abandons jobs and releases retained results. A cancellation request alone does not establish completed cancellation.

A finished solve can still lose its result if publication cannot obtain result memory or retention space. A refused result handoff keeps the result retained. Delivered-byte custody remains reserved until disposal. This accounting does not measure webview heap. Other model commands lack the solve ingress bound, and the packaged CLI self-test runs outside this pool. These controls do not guarantee whole-app memory use.

Worker footprint checks run at intervals. Memory outside the counted heap can exceed the reservation until the next check and worker termination. A larger pool does not expand numerical scope or activate retained desktop solving (Status).

2.Engineering checks.

• Movements first. Look at the largest displacement and rotation in every case. Meters of movement or whole radians of rotation indicate a possible mechanism or unit error. Investigate these values (Status).
• Weight balance. In the weight case with every rest acting, the vertical support loads add up to the total weight entered.
• Free growth. Hold the line at one anchor only and apply the thermal case. For uniform unconstrained thermal strain, each node should move by αΔT times its position vector from the anchor. Member forces should be zero. Other restraints, nonuniform strain or imposed boundary motions change this expectation.
• Order of magnitude. Compare the thermal load on a leg with the guided-cantilever estimate of Part II A. A result ten times larger or smaller needs explaining.
• Support states. In each nonlinear case, read which rests have lifted off, which gaps have closed and which shoes slide. Ask whether the line would behave that way.
• The validating program. The final check is the model in the program you validate in, compared result by result (Part V C).