Save, organize and restore your calculations.
Keep sync and organize your saved records.
Compose the whole plant as one ordered chain of unit operations. Every run closes the stage and whole-plant water and salt balance, derives concentrate TDS by salt conservation — never assumed — and derives membrane product TDS from salt rejection. Every output is labelled input, derived or missing; a blank field is never presented as 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.
01
Where the design stands and what is outstanding. The plant flow below is the authoritative diagram of the whole plant, and the report prints that same projection.
The real water path through your design: source, pumps, every stage you configured in process order, and the permeate/concentrate split. Every node and stream is generated from the same engineering model that drives the requirements, sizing, schedule, BOQ and report — nothing here is a picture. This is the same projection the report prints. Select any item to see its duty, its basis and what is still required.
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.
9 complete, runnable starting bases — open one, then Run the design to see the full intake-to-product chain calculate. Each case fills only your own input fields; every number that follows is computed by the same engines this page always uses. The figures are an illustrative starting basis to replace with your project data — not a reference design, a vendor recommendation or a compliance case.
Want to compare them before you open one? See every case with its engineering basis in the Demo Gallery.
Design control center
Read from the engineering model. Nothing here is estimated, and no item is counted as done because a field is merely filled in.
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.
Where the design actually stands, area by area. The overall state is the worst area, so one missing input can never be hidden behind many calculated ones. Nothing here is a readiness guess: each state is decided from values and checks the engineering model already produced.
Every outstanding item in the model’s own words: what is wrong, why it matters, which engine produced the underlying value, and what is required next. This is a deterministic reading of the engineering model — there is no AI inference here, and nothing is estimated to fill a gap.
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 design case is the intent this plant was sized to. An operating case is the point it is actually held at — a seasonal feed, an availability the site can really deliver, a recovery the operators can really achieve. The pair reports each fact's deviation from the design basis and its direction. It does not score, rate or approve the operating point, and EngiMetric holds no plant operating data: every operating figure below is one you enter.
02
What has to be true before anything can be sized. Every figure here is stated by you; nothing on this band is inferred, defaulted or assumed.
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.
03
The water path itself: which processes exist, in what order, on what stated basis, and what the mass balance then conserves. This is where the engineering happens.
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.
Where you configure the design: which processes exist, in what order, and on what stated basis. Read this while you are choosing processes. The plant flow earlier in this workspace is the single diagram of the result — the real water path through the equipment — and it projects the same mass balance this train is built from, so the two cannot disagree.
All three are inputs to one process graph. Every flow, quality, duty and equipment quantity shown anywhere in EngiMetric derives from it, so the mass balance, hydraulics, equipment schedule, BOQ and report can never disagree. Nothing here is a second plant model.
Build the plant as an ordered process graph. Add, reorder or remove any pretreatment, RO pass or post-treatment step. Flows and qualities are carried from one step to the next by the existing engines — a step is never fed an invented value. A step with no validated basis in EngiMetric is shown as Preliminary and reports Engineer Review rather than claiming a performance number.
What each configured process needs in order to be designed, and the engine that does the work. Use Configure on a step in the configuration above to enter them. Values belong to the process, not to a row position, so reordering the train cannot move a design input onto the wrong stage.
A factory-integrated package plant changes how the design is procured and delivered, not how it treats water. Mark the configured steps that ship inside the package, and record the envelope figures you have. Every figure stays yours: EngiMetric holds no container geometry, no skid frame weight and no transport data, so anything you have not supplied is reported as Required Input rather than estimated.
Specialized stage data for the membrane technologies that have their own sizing engines — UF, NF, RO and IX. These cards appear only for a technology that is actually configured in the train above. Leave a field blank to mean not requested: EngiMetric then reports a Required Input and names exactly what is missing, rather than assuming a standard.
Each blank field simply means that size is not requested — EngiMetric then reports not applicable and never assumes a standard. Fill one field of a group and the whole group becomes data required, naming exactly what is still missing. Every figure below is produced by an existing platform engine: tank storage, media-filter sizing, antiscalant dosing, and pipe sizing.
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.
04
What the project has to hand over. Each artefact is built from the model above and carries its provenance back to the calculation that produced it.
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.
Every assumption the current design relies on, with the owner role, the basis/standard it is bound to and its review standing. An existing or hybrid item or a stated stream value is an assumption with no verification record attached until the engineer signs it off — stating it never makes it verified.
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.