Mechanical Design Standards in NeqSim

NeqSim catalogs standards that may be relevant to process-equipment design. Catalog inclusion is not a statement that every requirement or calculation in a published standard has been implemented. The matrix below reports the calculation evidence that currently exists in NeqSim.

Maturity definitions

Maturity	Meaning
`CATALOGUED`	Standard identity, edition metadata, category, and equipment applicability are available, but no standard calculation is exposed.
`SCREENING`	A preliminary engineering calculation is available with the boundary stated in the matrix. It is not a conformity assessment.
`VALIDATED`	The stated calculation range has independent numerical validation and controlled regression evidence.
`QUALIFIED`	A controlled implementation and evidence package has been released for a stated use. Accountable engineering approval is still required.

No current entry is classified as VALIDATED or QUALIFIED. Existing calculations remain useful for preliminary screening, but project criteria, purchased standards, vendor data, and engineering review remain governing.

Current support matrix

The table between the generated markers is produced by StandardSupportAudit.generateMarkdownTable(). A regression test fails if the published table and the source catalog diverge.

Typed standard selection

New code can select an explicit current edition without depending on the registry’s process-wide version overrides:

StandardSelection selection = StandardSelection.strict(StandardType.API_521);
mechanicalDesign.setDesignStandard(selection);

StandardSelection.strict(...) requires a publisher-verified current edition and an exact typed kernel. It fails closed with a StandardSelectionException when the lifecycle is unverified, the edition is superseded or not current, the exact kernel is missing, the equipment context is missing, or the standard is not listed for that equipment type. The exception exposes a machine-readable reason so applications do not need to parse its message.

Use StandardSelection.historical(...) only for a controlled compatibility calculation whose exact non-current edition is implemented. It retains applicability and kernel checks but makes the historical basis explicit. StandardSelection.strictRegistry(...) is the transitional factory path; it verifies the current lifecycle, implementation maturity, registry connection, and applicability without claiming an edition-specific typed kernel.

Executable strict and historical selections reject project amendments until the selected kernel or requirement pack explicitly implements them. StandardSelection.legacy(...) can retain amendment metadata during migration, but doing so does not apply the amendments to a calculation.

StandardRegistry.assessApplicability(...) provides the applicability decision without creating a standard.

StandardSelection.legacy(...) is available for migrations that need an explicit edition while retaining the permissive factory behavior. It may create a metadata-only DesignStandard; it does not add calculation support.

Process-global setVersionOverride(...) and clearVersionOverrides() are deprecated. New code should retain a StandardEdition in each StandardSelection, then call StandardRegistry.requireDesignKernel(selection) when an executable implementation is required. The require call distinguishes missing kernel support from an unsupported edition. See the typed-kernel migration guide for a staged compatibility path.

Consolidated design kernels

EquipmentDesignKernel<I, O> extends the existing typed engineering-calculation contract with the implemented standard, audited maturity, and structured applicability. Kernels must not mutate their input or a ProcessSystem. Compatibility adapters defensively copy legacy mutable calculators.

StandardRegistry.getDesignKernel(...) returns an explicit lookup status. API 617, API 610, API 521, API 526, API 12J, API 2000, NORSOK M-506, ISO 5167-2, DNV-RP-C203, DNV-RP-F105, DNV-RP-F101, DNV-RP-F104, DNV-RP-F109, DNV-RP-F110, DNV-RP-F114, and DNV-ST-F101 have connected adapters and return IMPLEMENTED; standards that have not been adapted return NOT_IMPLEMENTED, never an empty or implied success. Each kernel returns an immutable assessment snapshot and always requires engineering review because its maturity remains SCREENING. Unsupported editions fail closed as EDITION_NOT_IMPLEMENTED until separately implemented and validated.

API 521, API 2000, NORSOK M-506, ISO 5167-2, DNV-RP-C203, DNV-RP-F105, DNV-RP-F101, DNV-RP-F104, DNV-RP-F109, DNV-RP-F110, DNV-RP-F114, and DNV-ST-F101 currently have both a publisher-verified current lifecycle and a matching exact kernel. API 526, API 617, API 610, and API 12J adapters implement legacy edition labels that do not match the current catalog editions; they are available only through an explicit historical selection until current-edition kernels and independent benchmark evidence are added.

The API 521 adapter defensively copies the mutable protected-item basis, requires at least one complete credible scenario, selects the governing rate, and records the sizing and accumulated pressure checks. The API 526 adapter accepts an explicitly unit-tagged required area and reports an inadequate result when a single standard orifice cannot cover it. These adapters do not establish scenario completeness or qualify valve construction, installation, reaction loads, flare-network effects, or vendor certification.

The API 2000 adapter aggregates caller-controlled normal movement, thermal, and other demands, compares them and an externally established total emergency demand with rated capacities, and screens corresponding rated pressures/vacuum against tank limits. It does not embed licensed API demand equations or tables, size a vent, derive scenarios, or qualify installation. See the API 2000 tank-venting guide.

The API 617 adapter defensively copies a compressor-casing configuration before evaluating pressure containment, hydrotest, flange-rating, nozzle-load allowance, and thermal-growth screens. The API 12J adapter uses explicitly unit-tagged cut diameter together with K-factor and liquid residence time. Passing either result is not a package, vessel, or performance certification.

The ISO 5167-2 adapter makes liquid versus gas/vapour service explicit, iterates the existing Orifice discharge-coefficient correlation, and blocks conditions outside its single-phase, full-pipe, subsonic, non-pulsating numerical envelope. ISO 5167-1 remains the separately catalogued companion requirements basis. Installation attestations are caller evidence, not checks performed by NeqSim; uncertainty, calibration, inspection, and custody-transfer acceptance remain external.

The DNV-RP-C203 adapter evaluates a caller-controlled single-slope or continuous bi-linear S-N curve, explicit stress-range factors, spectrum bins, design fatigue factor, and Palmgren-Miner utilization. NeqSim does not select or embed DNV curve tables. Curve/detail selection, structural stress, environment and thickness basis, SCFs, load combinations, rainflow counting, inspection, and conformity remain controlled external work. See the DNV-RP-C203 fatigue guide.

The DNV-RP-F105 adapter evaluates a simply supported Euler-Bernoulli first mode with externally derived effective mass and axial force, then reports current/wave frequency ratios, reduced velocities, and Keulegan-Carpenter number. Caller-controlled response triggers only indicate when the project workflow requires detailed analysis; they are not DNV limits or acceptance decisions. Soil and span-shoulder stiffness, interacting spans, response amplitudes, direct wave loading, ULS/FLS, fatigue, monitoring, and intervention remain external. See the DNV-RP-F105 free-span guide.

The DNV-RP-F101 adapter evaluates the public isolated longitudinal metal-loss equation under internal pressure using verified geometry, inspection sizing, characteristic ultimate tensile strength, pressures, and caller-controlled depth allowance and pressure factor. It does not select licensed partial factors, assess interactions or complex profiles, combine longitudinal compression, or issue a fitness-for-service decision. It is independent of and does not replace DNV-ST-F101 original-design checks. See the DNV-RP-F101 corroded-pipeline guide.

The DNV-RP-F104 adapter screens caller-controlled CO2 and water composition margins and an ordered pressure-temperature profile against externally verified single-phase pressure boundaries, MAOP, and design temperatures. It does not infer a phase boundary from the pure-CO2 critical point or embed publisher composition criteria. Phase-model qualification, fracture/decompression and crack arrest, DNV-ST-F101 structural design, materials, corrosion, construction, safety, operation, and requalification remain external. The companion requirement pack maps related NeqSim capabilities without claiming clause coverage. See the DNV-RP-F104 CO2 pipeline guide.

The DNV-RP-F110 adapter compares effective force, longitudinal strain, global displacement, and required feed-in response from an external global structural analysis with caller-controlled allowable or available values. These response-envelope identities do not calculate critical buckling, initiation, prevention, pipe-soil springs, triggers, buckle sharing, local capacity, or DNV-ST-F101 acceptance. See the DNV-RP-F110 global-buckling guide.

The DNV-RP-F114 adapter compares externally established vertical, axial, and lateral design-action magnitudes with caller-controlled resistance magnitudes for named route locations and design situations. It does not derive soil parameters, penetration or burial response, load-displacement curves, characteristic values, factors, or structural actions. Adjacent DNV-RP-F109, DNV-RP-F110, DNV-RP-F105, and DNV-ST-F101 assessments remain separate. See the DNV-RP-F114 pipe-soil interaction guide.

Cross-equipment requirement packs

Some standards express requirements across equipment, calculations, documents, and lifecycle activities and cannot honestly be represented by one DesignStandard subclass. Immutable StandardRequirementPack records make the existing NeqSim calculation and review capabilities discoverable without copying licensed standard text or implying complete conformity.

StandardSelection selection = StandardSelection.strictRequirements(StandardType.NORSOK_P_002);
StandardRequirementPack requirements = StandardRegistry.requireRequirementPack(selection);

Each capability declares whether it is a calculation screen or a review workflow, its implementation class, and its engineering boundary. Packs currently map NORSOK P-002, NORSOK S-001, NORSOK M-001, API 520 Part 1, API 650, API 660, DNV-ST-F101, DNV-RP-F104, DNV-RP-F109, DNV-RP-F110, DNV-RP-F114, ISO 10418, IEC 61511, and IEC 60534. Strict lookup still fails when the lifecycle is unverified; IEC 60534 therefore remains discoverable in the audit but cannot be selected as a verified current requirements basis.

Requirement packs are navigation and orchestration metadata. They do not contain publisher requirements, prove coverage, execute every mapped capability, or replace a project requirements register and independent conformity assessment.

How to interpret the registry

StandardRegistry.createStandard(...) remains backward compatible. The factory class shown in the matrix records what it currently creates; it does not prove that the resulting class implements the selected edition. StandardRegistry.getMappedImplementationClass(...) allows applications and audits to inspect that mapping without constructing equipment or accessing the design database.

The API 610 pump screen remains available through PumpMechanicalDesign. The consolidated PumpApi610DesignKernel is a pure adapter over the same calculator, so existing callers are not removed or redirected. The generic legacy factory still creates a base DesignStandard; executable kernel support is exposed explicitly through StandardRegistry.getDesignKernel(...).

Engineering boundary

Treat CATALOGUED entries as discovery metadata only.
Treat SCREENING results as preliminary design information with the stated boundary.
Do not infer certification, code compliance, vendor acceptance, or construction readiness.
Record the purchased edition, project amendments, input provenance, and accountable approval outside the current legacy registry.
Use the standards implementation program to prioritize current-edition kernels, benchmark evidence, and requirement coverage.

See the engineering capability statement for the broader process-to-engineering workflow and its qualification boundary.