NeqSim Engineering Guide

This guide describes the recommended engineering path for a ProcessSystem or multi-area ProcessModel. It focuses on what must be defined, executed, checked, and retained at each gate. For API detail, follow the linked specialist documentation rather than treating this page as a replacement for discipline methods.

Choose the workflow

Starting point	Recommended route
Confirm what is implemented now	Review Current Engineering Capabilities
Learning or method evaluation	Run the focused engineering notebook
One tagged process system	Use the Process-to-Engineering Simulator
Several process areas or shared systems	Use the Process Model to Engineering Workflow
Controlled-pilot facility qualification	Use the Engineering Production Vertical Slice
Exact method and production-readiness qualification	Use Industrial Method Qualification and the production-readiness workflow
Full offshore facility example	Run the Complete Offshore Engineering Study
Open-ended engineering study with research and reporting	Use Solve an Engineering Task

Gate 1: Establish a trustworthy process model

Begin with a tagged, converged model whose thermodynamic basis, feed definition, operating conditions, equipment topology, recycle behavior, and unit conventions are explicit.

Minimum evidence:

• stable equipment and stream identities;
• mass and energy closure at the required tolerance;
• converged normal operation with no silently ignored unit failure;
• documented fluid characterization, equation of state, mixing rule, and property package;
• comparison against plant, laboratory, published, or controlled reference results; and
• a record of assumptions and known model limitations.

Do not begin sizing from a model that merely completes a run. Numerical convergence, physical closure, and benchmark agreement are separate checks. See Numerical Health and Engineering Closure.

Gate 2: Define controlled design cases

Create executable cases for the conditions that can be represented by steady process simulation, normally including normal operation, maximum production, minimum turndown, relevant feed compositions, and hot/cold or high/low pressure conditions. Each case should retain:

• a stable case identifier and type;
• the controlled source for every changed input;
• units and applicability limits;
• priority or governing intent; and
• acceptance criteria for convergence and constraints.

See Design Cases and Governing Envelopes for case construction, metric direction, acceptance limits, status handling, and coverage review.

Startup, shutdown, compressor trip, settle-out, fire, blocked outlet, and depressurization are not made credible by renaming a steady-state case. Represent them with the appropriate dynamic or safety-scenario model and link the approved hazard-review basis.

Gate check: every design variable and calculated load can be traced to the case that governs it.

Require EngineeringCaseRunReport.isComplete() before using the envelope as a closed design basis. Completeness and acceptance are separate: isAccepted() additionally requires configured limits and no violations. Workflows that must stop on incomplete coverage can select EngineeringCaseFailurePolicy.THROW_WITH_PARTIAL_RESULT; the thrown exception retains the partial report for diagnosis and audit.

Gate 3: Run isolated cases and create governing envelopes

Run cases on independent copies. This prevents one case or design update from contaminating another and preserves the original process model as the controlled physics source.

Review:

• convergence and unit-level run status for every case;
• maximum and minimum pressure, temperature, flow, duty, power, liquid inventory, and composition as relevant;
• case-to-case discontinuities or unexpected phase changes;
• the governing case for each equipment item, line, valve, instrument, and safety load; and
• numerical warnings, extrapolation, and missing input evidence.

The Engineering Simulator Foundations describes the case runner, readiness, provenance, and uncertainty contracts.

Gate 4: Close the process/design loop

Use EngineeringDesignLoop through explicit discipline modules, or use an EngineeringAutoConfigurationPolicy that is itself controlled and complete, to:

1. calculate candidate sizes and ratings from the governing envelope;
2. select discrete dimensions, schedules, drivers, ranges, or standard sizes;
3. apply the selected physical variables to an isolated design copy;
4. rerun hydraulics and process cases;
5. re-evaluate constraints; and
6. continue until both design variables and process results are stable.

Typical loop variables include separator diameter and length, pipe inside diameter, valve Cv, driver rating, exchanger area, instrument range, pressure rating, and preliminary relief or blowdown targets.

Discipline modules declare upstream module IDs through EngineeringDesignModule.getDependencies(). EngineeringDesignDependencyGraph validates missing IDs, duplicate IDs, self-dependencies, and cycles, then evaluates deterministic topological levels. Updates from one level are selected and applied before the next level is evaluated, so downstream modules consume current-iteration design state rather than an accidentally alphabetical or one-iteration-old value.

Two modules may not silently overwrite the same design-variable key. The default REQUIRE_UNIQUE policy throws EngineeringDesignConflictException with the module IDs, units, and proposed values. A genuinely shared upper- or lower-governing variable must declare the same explicit GOVERNING_MAXIMUM or GOVERNING_MINIMUM rule on every proposal. Unit or rule disagreement still fails closed, and the selected state’s sourceModule retains the governing owner.

Gate check:

• all cases converged after the final design update;
• physical and process-value changes satisfy declared tolerances;
• every declared constraint passes;
• no hidden screening default was used;
• all selected values retain method, units, governing case, and input evidence; and
• the module dependency graph is valid and every shared-variable selection has an explicit governing rule;
• the source process model remains unchanged.

See Process-to-Engineering Simulator for configuration patterns, extension points, and result contracts. The current implementation includes separator, inventory, compressor, pump, heat-exchanger, rated-capacity, line/network, valve, instrument, material, pressure-equipment, process-safety, and relief-device modules. See Current Engineering Capabilities for the design-loop and higher-assurance interfaces.

Gate 5: Complete discipline verification

The common design loop coordinates shared inputs and dimensions; each discipline must still review its governing methods, assumptions, and interfaces.

Discipline	Principal checks	Documentation
Process	heat and material balance, equipment loads, operability, utility demand	Process Design Guide
Mechanical	design pressure/temperature, material class, thickness, weight, nozzle and equipment constraints	Mechanical Design
Piping	diameter/schedule, velocity, pressure drop, rating, relief inlet loss, vibration and stress screens	Topside Piping Design
Rotating	operating envelope, driver margin, surge/stonewall or NPSH, temperatures, recycle and transients	Compressor Design Feasibility
Valves and instruments	Cv/opening, choked or flashing service, range, uncertainty, response, failure action	Instrument Design
Electrical	motor/VFD, cable, transformer, switchgear, load list, hazardous area	Electrical Design
Materials	fluid exposure, corrosion/degradation mechanisms, material class and operating envelope	Mechanical Design Standards

Record unresolved assumptions as actions. Do not convert a screening correlation into an approved discipline method by omitting the warning.

For higher-assurance evidence, the production-readiness layer has independent typed gates for distributed piping transients, compressor protection and machinery, valve/instrument response and installation, detailed mechanical integrity, and flare radiation/dispersion/noise. A passing numerical constraint remains CALCULATED_REVIEW_REQUIRED until method, standards, evidence, vendor, and accountable-review requirements are met.

Gate 6: Verify control, safety, and abnormal operation

Connect the designed process to the control and safeguarding model. Depending on scope, verify:

• control-loop response and actuator travel;
• compressor trip, anti-surge recycle, settle-out, and restart constraints;
• ESD isolation and safe-state timing;
• PSV capacity, inlet loss, backpressure, and two-phase method selection;
• blowdown duration, minimum metal/fluid temperature, hydrate risk, and flare concurrency;
• HIPPS or SIS voting, bypass/degraded modes, PFD/PFH, and proof-test assumptions; and
• consequence, escalation, and facility-response assumptions where required.

Credible scenarios, simultaneous-event groups, fire zones, safeguards, SIL targets, and acceptance decisions must come from the controlled safety lifecycle. NeqSim can calculate and retain evidence; it cannot approve that evidence.

Start with Safety Documentation and the safety integration section. Use the HAZOP and LOPA to Draft SRS Handoff for traceable hazard-study flow, and the P&ID Design Synthesis workflow when preparing governed nodes and deviations for review.

Gate 7: Compile and review the engineering package

Compile deliverables from the designed process copy and canonical engineering graph. A coordinated package can include:

• process design basis and case matrix;
• governing envelopes and calculation evidence;
• equipment, line, valve, instrument, I/O, alarm, trip, and relief registers;
• equipment and PSV datasheets;
• utility, materials, flare, and blowdown summaries;
• DEXPI PFD/P&ID exchange files and validation reports;
• unresolved-action, external-evidence, revision-impact, approval, readiness, and qualification-plan registers; and
• package manifests, schemas, content hashes, and the integrity-protected NeqSimModelPackage manifest.

Review package consistency before issue: tags, units, revision, governing cases, calculated values, graph identities, and unresolved actions must agree across artifacts. See DEXPI Engineering Generation and Engineering Deliverables and Handover. Use the DEXPI Engineering Guide to select and qualify the correct exchange profile.

Gate 8: Manage revisions and stale evidence

When the process model, design basis, method, or evidence changes:

1. issue a controlled change event;
2. compare the new model/package with the approved baseline;
3. traverse dependencies to identify affected calculations and deliverables;
4. invalidate stale validation and approval states;
5. rerun only the justified scope while retaining unchanged evidence; and
6. issue a revision-impact report with accountable actions.

Use Model Change Events and Model Impact Analysis for the lifecycle workflow. For a multi-area ProcessModel, ProcessModelEngineeringSimulator.runIncremental(...) reuses an area only when its model, policy, case, shared-stream, and shared-system fingerprints remain valid.

Current qualification ladder

Contract	Implemented meaning
Case result	CALCULATED, CALCULATED_WITH_METRIC_FAILURES, CALCULATED_NOT_CONVERGED, FAILED, or SKIPPED
Closed design loop	Design variables and process values are stable, cases converged, and declared constraints passed
Controlled vertical slice	Nine preflight/execution gates can establish qualifiedForControlledPilot=true
Production readiness	NOT_READY, EXPERIMENTAL, VALIDATED_PRELIMINARY, or QUALIFIED_FEED_SUPPORT
Package integrity	Schemas, references, manifests, and SHA-256 artifact hashes passed validation
Accountable approval	Supplied external decision receipts and controlled document hashes passed structural and scope checks

These contracts are cumulative evidence states, not synonyms. In particular, QUALIFIED_FEED_SUPPORT does not grant FEED approval, construction release, or operating authorization.

Review-ready versus construction-ready

Status	Meaning
Calculated	A method executed and produced a traceable result
Internally validated	Numerical, benchmark, and consistency checks passed within the declared scope
Review-ready	Inputs, methods, findings, warnings, and actions are organized for accountable engineering review
Approved	The authorized discipline or safety-lifecycle role accepted the controlled evidence
Fit for construction	All required detailed design, vendor, independent, regulatory, and construction-authority gates are closed

NeqSim engineering outputs should normally be treated as calculated, internally validated, or review-ready. The package must fail closed rather than infer approval or fitness for construction from successful simulation.

Final checklist

• Process model is tagged, converged, closed, and benchmarked.
• Design and abnormal cases are explicit, controlled, and correctly modeled.
• Governing cases are retained per calculated quantity.
• The process/design loop converged on an isolated copy.
• Discipline methods, assumptions, units, and constraints are traceable.
• Control and safety scenarios have controlled credibility and acceptance bases.
• Deliverables agree on tags, values, revision, and evidence state.
• Missing vendor, independent, HAZOP/LOPA/SRS, authority, or approval evidence remains visible.
• Model changes invalidate and regenerate the correct dependent evidence.

Return to the Engineering documentation hub.