Overview

This guide explains how to make capacity utilization available for any piece of NeqSim equipment by setting design limits on its MechanicalDesign object. It complements the Capacity Constraint Framework, which describes the constraint model and the equipment-specific strategy library.

Why this exists

Many equipment types (compressors, separators, valves, pipelines, heat exchangers, pumps) ship with rich, type-specific capacity constraints. Generic equipment, however, had no uniform way to answer the simple question “how close is this unit to its design limit?”

The mechanical-design bridge fills that gap. You configure the design envelope where it naturally belongs — on the equipment’s MechanicalDesign — and a single opt-in call turns those limits into capacity constraints that surface in:

Works out of the box, fully configurable

The capability is designed to need no configuration to start and to stay fully configurable when you need more control:

The two methods you need

The capability is delivered through two public methods.

On MechanicalDesign:

Method Returns
getDesignUtilization() Map<String, Double> of metric name → utilization (current/limit)
getMaxDesignUtilization() the maximum utilization across all configured design limits, or 0.0
getDesignCapacityConstraints() the derived CapacityConstraint list (used by the bridge)

On every equipment (ProcessEquipmentBaseClass):

Method Returns
applyMechanicalDesignCapacityConstraints() registers the derived constraints and returns how many were added

Supported design limits

Set any of the following on the equipment’s MechanicalDesign. Only limits that are set to a value greater than 0 and that have a finite operating value produce a constraint, so unused limits never create misleading utilization.

Mechanical-design limits mapped to utilization metrics
MechanicalDesign setterUtilization metricUnitOperating value source
setMaxDesignVolumeFlowdesign volume flowm3/hrsum of inlet stream actual volume flow
setMaxDesignGassVolumeFlowdesign gas volume flowm3/hrequipment hook (override getOperatingGasVolumeFlow)
setMaxDesignOilVolumeFlowdesign oil volume flowm3/hrequipment hook (override getOperatingOilVolumeFlow)
setMaxDesignWaterVolumeFlowdesign water volume flowm3/hrequipment hook (override getOperatingWaterVolumeFlow)
setMaxDesignPowerdesign powerkWequipment hook (override getOperatingPower)
setMaxDesignDutydesign dutykWequipment hook (override getOperatingDuty)
setMaxDesignCvdesign Cv-equipment hook (override getOperatingCv)
setMaxDesignVelocitydesign velocitym/sequipment hook (override getOperatingVelocity)
setMaxDesignPressureDropdesign pressure dropbaraabsolute inlet-minus-outlet pressure

Universal vs. hook metrics

Two metrics are computed universally for any equipment that has inlet/outlet streams:

The remaining metrics (gas/oil/water volume flow, power, duty, Cv, velocity) depend on quantities that are equipment-specific or ambiguous in units across the codebase. They are exposed as protected hook methods on MechanicalDesign that return Double.NaN by default. Equipment subclasses (or specialised MechanicalDesign subclasses) may override the matching getOperating* hook to feed a real value — using the documented unit convention (actual m³/hr, kW, m/s). Until a hook is overridden, the corresponding design limit simply produces no constraint, so utilization is never reported on an undefined basis.

Worked example

SystemInterface fluid = new SystemSrkEos(298.15, 60.0);
fluid.addComponent("methane", 0.9);
fluid.addComponent("ethane", 0.1);
fluid.setMixingRule("classic");

Stream feed = new Stream("feed", fluid);
feed.setFlowRate(1000.0, "kg/hr");
feed.setPressure(60.0, "bara");
feed.setTemperature(25.0, "C");

Heater heater = new Heater("heater", feed);
heater.setOutletPressure(50.0);     // 10 bara pressure drop
heater.setOutTemperature(30.0 + 273.15);

ProcessSystem process = new ProcessSystem();
process.add(feed);
process.add(heater);
process.run();

// 1) Configure the design envelope on the mechanical design
heater.getMechanicalDesign().setMaxDesignPressureDrop(20.0);   // bara

// 2) Read utilization directly from the mechanical design
double dpUtil = heater.getMechanicalDesign()
    .getDesignUtilization().get("design pressure drop");        // 10 / 20 = 0.5

// 3) Or surface it as an equipment capacity constraint (opt-in)
int added = heater.applyMechanicalDesignCapacityConstraints(); // 1
double maxUtil = heater.getMaxUtilization();                   // 0.5

Workflow rules

  1. Set design limits first, then run the process. Utilization needs live stream conditions, so call applyMechanicalDesignCapacityConstraints() after process.run().
  2. Re-apply after changes. The call is idempotent — derived constraints use stable names (for example "design pressure drop"), so re-invoking it overwrites the previous values instead of creating duplicates. Re-run it whenever design limits or operating conditions change.
  3. It never throws. If the mechanical design cannot be read, the method registers nothing and returns 0.
  4. Nothing is required. With no design limits set, the feature is dormant and behavior is identical to before — set limits only for the metrics you care about.

Caveat: cached vs. throwaway mechanical design

For equipment that overrides getMechanicalDesign() to return a cached design (separators, pumps, valves, pipelines, heaters, coolers, heat exchangers, compressors), the limits you set persist and the bridge works as shown above.

The base ProcessEquipmentBaseClass.getMechanicalDesign() returns a fresh throwaway instance for equipment that does not cache one. For such equipment, set the limit and read utilization through a single retained reference, e.g.:

MechanicalDesign md = someEquipment.getMechanicalDesign();
md.setMaxDesignVolumeFlow(5000.0);
double util = md.getMaxDesignUtilization();