Save, organize and restore your calculations.
Keep sync and organize your saved records.
Model the whole plant as one ordered chain of unit operations — raw intake, then each stage in process order, then product and waste. The underlying plant mass-balance engine closes the stage and whole-plant water balance on every run, derives concentrate TDS by salt conservation (never assumed), and derives membrane product TDS from salt rejection. Every output is labelled input, derived or missing; blank fields never pretend to be verified.
Software Guide — single source of truth
The first question is the product requirement: required product water flow, target product TDS, plant recovery target, operating hours, availability and the end use. From the product flow and recovery, EngiMetric derives the raw plant intake (product ÷ recovery) — you do not have to invent it. Where a value cannot be derived it is reported as data required, never assumed. Derived product TDS is then checked against your target.
Feed and product rates in m³/h and L/s, the per-unit allocation across duty trains, and the source-capacity verdict are derived from your product requirement. Recovery is engineer-supplied — it is never assumed. Product flow, recovery and operating hours are captured once in step 1 and reused here.
Each of the twelve stages shows a real state: not started, in progress, complete, needs data, needs engineer review or needs recalculation. A stage is not complete merely because you opened it — completion depends on its own inputs, its calculation and its checks. If you change an upstream input, the affected downstream stages are flagged needs recalculation instead of remaining falsely complete. The bar also tells you what to do next.
INPUT is yours. DERIVED is calculated by EngiMetric. MANUFACTURER DATA is verified external technical information. MISSING / DATA REQUIRED means a value was not supplied. PRELIMINARY means calculated on a stated basis but not verified. COMMERCIAL DATA is a price you entered. ENGINEER VERIFICATION REQUIRED marks a decision the software cannot finalise for you.
Model the raw-water source: source type, installed / duty / standby wells, well diameter, static and dynamic levels, drawdown, pump setting, tested well yield and specific capacity, source temperature and TDS. A required per-well duty flow is an allocation from the plant demand — it is not a confirmed well yield. Drawdown and dynamic level are derived when only the other is given, and derived specific capacity is yield ÷ drawdown. The capacity verdict is adequate, insufficient, or requires verification — the last always applies when no measured/confirmed pumping-test data is supplied.
Enter the common desalination feedwater ions (Ca, Mg, Na, Cl, HCO₃, SO₄) with pH, temperature and measured TDS. The panel reuses the platform's water-analysis engine to derive hardness, cation–anion balance and, when TDS is present, ionic strength and LSI/RSI saturation tendency. A blank field is skipped, never assumed to be zero; measured TDS feeds the design basis and the treatment-train salt checks.
Add each unit operation in process order: e.g. Pretreatment / UF → First-pass RO → Second-pass RO. Each stage needs a name and a recovery (%). Optional per stage: external make-up flow, feed TDS, product TDS, and a membrane salt rejection (%).
Qw·Cw = Qf·Cf − Qp·Cp), never assumed.Cp = Cf × (1 − R/100), membrane stages). Entered product TDS always takes precedence.You may continue without every value. Blank optional fields are reported as Missing and only disable the checks they feed; the plant water balance still runs and any entered data is never overridden. The software never fills a critical value and pretends it is verified.
Every figure is labelled: Input (engineer-entered), Derived (computed here, e.g. stage flows, concentrate TDS, membrane product TDS), or Missing (not supplied). Nothing silently looks verified that was not.
Stage and whole-plant water balances close automatically with each run. When TDS is supplied for every stage, the whole-plant salt check also runs. Diagnostics tell you what was verified, what was derived, and what still needs engineer confirmation (e.g. derived concentrate TDS against solubility / scaling data).
Save Result keeps the exact inputs and outputs. The Workspace panel under the calculator lets you reopen a saved run with its inputs restored intact — including the stage list. A reopened run is marked for engineer review.
It does not select equipment, vessels, pumps or vendors; it does not price anything; it is not an IFC/approved-for-construction package and it cannot stamp or certify. A design with missing or preliminary values is a preliminary design and must not be presented as final.
The treatment-selection ladder lists the process drivers that shape a desalination train (fouling, biological activity, scaling, colloids, membrane damage risk, chemistry). Each driver names the platform calculation surface that produces the evidence for that driver's decision. Selecting a membrane technology stays an engineer decision supported by this evidence — the ladder never auto-decides a technology on your behalf.
After a run, the panel lists the engineering requirements derived from this design (e.g. raw-water transfer pump from the design basis, well submersible pump from the source-well allocation) with the calculation and stage that produced each. A requirement is DERIVED when a duty basis exists and DATA REQUIRED when engineer duty/head input is missing — no value is invented. No product candidates are attached without verified catalog data, so this handoff stays honest until a catalog is connected.
Use Find equipment on a requirement to review candidates from the verified manufacturer catalog. Matching shows the evidence for every criterion — flow, head, installation, pressure, rejection — against the manufacturer’s published data, and never an opaque score. Missing engineer data is reported as insufficient data rather than guessed. You select the product; the software never selects for you. Your selection then flows into the equipment schedule, the BOQ (every unpriced line is marked price unavailable — prices are never fabricated) and the engineering report, which carries the full traceability chain from BOQ line back to the originating calculation.
Tell us what is blocking your engineering work. Only the tool, the workflow section and the app version are attached — never your design values, client or location.
Optional engineering project attributes. Nothing here is required, and no personal or account data is stored. Saved locally in this browser.
Designs are stored in this browser only. There is no account and no cloud sync — clearing site data removes them, so export anything you need to keep.
The current design state at a glance. Every value is either supplied by you, derived by an EngiMetric engine, verified manufacturer data, missing, or awaiting engineer review — nothing is defaulted.
Every check the engines already perform, collected in one place with its source and next action. No check is recomputed here.
Test a change to the product requirement without touching your base design. The scenario re-runs the same engines and shows what moves downstream. A scenario is not the approved design.
The first engineering question is what you are required to produce. From the required product flow and the plant recovery target, the raw intake the plant must abstract is derived — you do not have to invent it. Where a value cannot be derived it is reported as data required, never assumed.
Model the raw-water source: well count, duty/standby split, pumping levels and pumping-test data. A required per-well duty flow is never a confirmed well yield — without pumping-test data the capacity outcome is requires verification.
Optional feedwater chemistry, evaluated with the platform’s existing water-analysis engine (hardness, charge balance, TDS by summation, ionic strength, LSI/RSI). Left blank, the fields simply skip the derivation they would enable — a blank is never assumed to be zero. The measured TDS below flows into the design basis and the treatment-train salt checks.
The derived hardness, charge balance and saturation indices reuse Water Analysis & Treatment Selection — the same engine, on one page. Use that surface for a full ion analysis; the fields here cover the common desalination feedwater ions (Ca, Mg, Na, Cl, HCO₃, SO₄).
Feed and product rates, the per-unit allocation and the source-capacity verdict are derived by the design-basis engine from your product requirement in section 01. Recovery is never assumed, and the plant intake is checked against the derived feed demand.
Product flow, recovery and operating hours are captured once in section 01 — Product / project requirements and reused here. There is no second place to enter them.
Optional pump hydraulic basis for the raw-water transfer and per-stage feed pumps. Every component is optional: a missing value stays missing — head is never assumed, and no pipe length, diameter, roughness, elevation or pressure is fabricated. The RO high-pressure pump duty uses the feed pressure you enter on the RO stage row in section 06.
Friction loss is computed by the existing Darcy-Weisbach engine when pipe geometry is supplied. Total dynamic head composes static head + friction + minor losses + discharge pressure via the existing pump-head engine. Motor power uses the existing pump-power engine. No hydraulic formula is re-implemented here.
The platform’s treatment-selection ladder maps observed water-quality drivers to candidate unit operations that already exist here. It is a starting point for verification — with the engineering step that must be confirmed (jar test, pilot, membrane projection, governing standard) — never a thresholded diagnosis. Cross-check the full surface at Water Analysis & Treatment Selection.
Reverse osmosis separation
Brackish and seawater desalting is an RO application space. Confirm feed characterisation, recovery target and concentrate disposal route with the owning authority and a membrane projection.
Ultrafiltration as upstream protection
Assemble UF ahead of RO in the treatment train, then verify SDI/turbidity performance with pilot or full-scale data and the membrane supplier.
Thermodynamic check and antiscalant dosing pathway
A scaling indication flags the need to manage the concentrate thermodynamics — antiscalant, acid or softening route selected against the actual salt system, not a rule-of-thumb.
Disinfection contact-time (Ct) accounting
Validate the disinfectant and its contact-time capacity against the governing potable water standard for the jurisdiction.
Nanofiltration or ion exchange separation
NF and IX are application-specific separations; confirm the target constituent and the resin/membrane specification with laboratory or manufacturer data.
Plant-level mass balance and design path
Develop the plant-wide water and salt balance first, then iterate stage recovery and make-up against the verified feedwater analysis.
Ordered unit operations from intake to product. Add a stage, then verify or replace the illustrative example values. Recovery and name are required; TDS / rejection entries enable the salt checks.
This is the whole-plant mass-balance view. For a connected stream-port train with validated feed–permeate–concentrate links and automatic downstream recalculation, use the Treatment Train surface.
The whole-plant water and salt balance, derived by the plant mass-balance engine after every run. Concentrate TDS is derived by salt conservation — never assumed.
The bridge from calculation to equipment. Each requirement is derived where a duty basis exists and data required where engineer input is missing — nothing is invented.
Find equipment against a requirement using the verified manufacturer catalog. Matching shows per-criterion evidence and never an opaque score. The engineer explicitly selects; the software never selects on your behalf.
The schedule of engineer-selected products, each row traceable back to the requirement it satisfies.
A quantity schedule derived from the selected equipment. Prices are never fabricated: every line is price unavailable until the engineer records a real quotation or published price.
The report data contract and the end-to-end traceability chain (BOQ → schedule → product → requirement → calculation). Full PDF generation is integrated with the existing report architecture; this section establishes the data foundation and the audit trail.
Each stage’s feed starts from the raw intake and becomes the next stage’s feed
(feed = previous product + optional make-up). Stage flows come from
product = feed × recovery/100 and waste = feed − product.
Concentrate TDS is derived by the stage salt balance
Qw·Cw = Qf·Cf − Qp·Cp, and membrane-stage product TDS from
Cp = Cf × (1 − R/100). Plant recovery is final product ÷ raw intake.
The whole-plant water check closes intake + make-up = product + waste. No threshold,
standard or performance value is invented here: recoveries, TDS and rejection are engineer-supplied
inputs, and defaults are illustrative examples — never recommendations.
Engine: plantDesigner.ts (this surface) over plantMassBalance.ts and the
platform salt.ts permeate-TDS helper. A plant with missing salt data passes its water checks
but is not a verified salt balance.
Workspace
Saved calculations in this browser can be reopened with their inputs intact.
No saved calculations yet
Use the Save Result button above and your calculation will appear here for quick reload, ready to be attached to a project or included in a report.