Engineering Toolbox for Desalination Mega-Projects

Process engineering starts after the process design. The latter is usually done with a help of free software for the UF/RO membrane selection and performance prediction, data normalization, and the re-hardening sizing. All three calculator types are specific to water treatment.

Calculators for process engineering are generic; they are valid in any industry. To build such calculators, the engineer should leave the "comfort zone" of water treatment and dive into the pool of disciplines ranging from hydraulics to electrical circuits. As this task is beyond the core desalination business, process engineering toolbox is still a dream come true.

In practice it is replaced with a set of conservative assumptions leading to subsystems with mismatch of capacities in excess of 30%.

These hidden reserve capacities are not evenly distributed; there is always a single bottleneck defining the plant production rate.

Every mega-project I participated in, had been upgraded later to add extra 10 – 20% output (thanks to initial conservative assumptions). Without much exaggeration one may state the following.

In projects pivoted around subsystems integration engineering calculators may boost the plant output by 10-20%.

Calculators mentioned are not XLS spreadsheets, and toolbox not a simple collection of calculators.

"Calculator" can be defined as algorithms that validate the primary information (input) and deduce the derived (secondary) information. They address the information ambiguity and even partial lack of it – they may mend some holes.

"Toolbox" is the collection of calculators that may talk to each other. It may chain calculators so the output of predecessor is the input of the successor.

In other words toolbox is based on some structure and calculator's communication protocol. Crenger.com makes one step further. Its calculators may talk to P&ID items as well.

What does primary information mean for an engineer? The usual answer is some numbers like the tank height and diameter if we need to calculate the volume.

Crenger.com models engineering "numbers" with objects containing over 20 attributes. They address the information status, completeness, modifications, errors, etc.

How does the engineer interact with such sophisticated calculators? In most cases the interaction is script-based. It is not a mistake. Instead of numbers, the engineer uses words to describe the task. "Select the piping for this pump discharge" is enough to make calculations. Calculator extracts the fluid type, its pressure and flowrate from "this pump" and uses the "discharge" directive to select the proper velocities and sizes. The "suction" word produces absolutely different results!

Advanced calculators (which we may call smart ones) do not need any directives. The engineer does not use them explicitly. They lurk in the background and once the information is ready, they do their job.

"Job" and "calculation" differ. The latter is finite, its purpose being to get output. Job means repeated calculations for the whole project with the purpose to create secondary information for its next phase. Job is iterative and may be initiated by the project update.

Initiation starts from data validation - calculators are the project auditors. They ruthlessly block the project progress if some piece of information is corrupted. In real life auditors are the most experienced designers.

In other words, smart calculators are precursor of human-aided engineering and IOET – internet of engineering toolboxes.

The first 3 "pillars" on which the crenger.com toolbox rests deal with piping (PP), pumps (PU) and hydraulics (HY).

#1 Piping sizing (PP)

The PP's core implements procedures described extensively in the "Piping Sizing" guidelines prepared by me for real mega-project. As PP is tied to the P&ID context and has access to the database, it does not require from the user any input. She/he may ask PP to size the accompanied devices like valves, meters, blind flanges, static mixers, etc.        

When the user presses the reset button, PP fetches its suggestions, which the user may edit. Normally the "reset" means returning the dialog state to the beginning or no-data state. As process engineering does not have no-data state (it is replaced with intuitive assumptions mentioned earlier), it turns into logical hurdle for engineering software architecture.     

Crenger.com treats RESET as a moment for voicing some auto-generated engineering solution deduced from the project context. This solution is called "auto-completion".

#2 Pumps selection (PU)

The reader may wonder why to invent the wheel if all leading pump manufacturers have online pump selectors? The same auto-completion.

PU has two core parts – the curves' reader and the curves' math. The former turns the scanned curves into digital ones. The curves' math is driven by so-called splines and handles all math operations like summation, deduction, multiplication, and so-called "drooping" curves – special case in the pump theory.

These core parts are general – they may be applied to any curve type. It is an illustration of the engineering thinking evolution– to excel in some specific domain of knowledge, one should master general ones (during higher education time). 

Pump specifics related to desalination include a number of points.

Unlike general-purpose industrial pumps, the desalination ones are built for efficiency. But it comes at a price: the higher the efficiency the narrower the preferred operation range is. The narrower the operation range of the pump the less the number of potential customers is.

The manufacturers' marginal interest topped with the requirements for hard-to-handle corrosion-resistant materials like superduplex, hastelloy, and silicon carbide makes the selection of desalination pumps non-trivial at all.

So cornerstone principle of desalination pumps selection is their reusability. In other words, the desalination plants should be engineered around near-fixed capacities of the high-pressure feed pumps (installed before RO membranes).

This principle explains the selection of the sample mega-project names by Crenger. For instance, the S2300 plant is built around the 2300m3/h pump for Seawater.

Crenger recommends the following fixed capacities available in the market: 300, 750, 1000, 1800, 2300, 2800. Each entry has roughly equal aggregate volume of sales – quantity multiplied by capacity.

Most of the desalination pumps are driven by variable frequency drives to extend their operation range. This option became a default.

Similarity in SWRO plant configurations and pump names (low pressure booster, ERS booster, high pressure pump) makes it possible to select the pump based not on its requested head, but its service. Here the objective is to accelerate the bid preparation and implement the "reset" mode.  

For example, if the user is in doubt regarding the pump head, she/he may select "ERS booster" service and PU will retrieve all the pumps used as ERS booster and matching the requested flowrate.

When the uncertainty is high due to "for information" data, the input may be complemented with by "around the head" or "near flow" entries. They do not requires the service definition.

Once the P&ID has been sized, crenger.com automatically selects the pumps and inserts the summary into bidding documents. The beauty of auto-completion.

The current pumps database contains 114 pumps with proven records in desalination.

#3 Piping hydraulics (HY)

In piping hydraulics scrupulous accounting of trifles – local resistances - makes perfection, but perfection is not a trifle.

Results are often unexpected. For example, the losses in manifolds of the RO membrane vessels may reach 8 – 15 meters, losses in the membranes being of the same order. Poorly selected tee (after high pressure pump) may lead to the pressure drop of 2 meters, 12" control plug valve before SWRO membranes may add 8 meters. Over 20-year operation the last figure will turn into US$350.000 of revenue losses.

Building HY is not a simple task as selection of the correct hydraulic "image" of the P&ID item depends upon the engineer experience and the database of "use cases".

For example, to assess the pressure drop in the plug valve with full-size port one may use published data labeled as "general valve", or "butterfly valve" or "ball valve" and accidentally hit the nail on the head.

Current crenger.com "use cases" library includes over 50 entries. It may be viewed here.

The next problem is that the input to HY comes from two sources - P&ID and the isometrics sketch – mechanical view of P&ID. It provides the needed piping profile and all the accompanied fittings list. (Fitting cannot be not shown on P&ID.) Crenger.com ties both sources together: every element of isometrics is linked to P&ID item containing information on geometry.

The user may select between "fast" and "detailed" calculations. To execute fast option, the user draws the line crossing the P&ID items of interest. Crenger does the rest without isometrics. 

For detailed option the isometrics sketch shall be prepared. The user builds a sequence of hydraulic resistances with varying flowrates. It may include the pump and be chained to another sequence. This sequence may be merged with PU calculator as well to build so-called "installed pump characteristics".  

HY is in permanent extension, new use cases being adapted from Handbook of Hydraulic Resistance (I.E. Idelchik). It is a real treasure box containing hundreds of them and waiting its time for digitization.

This task is a once-in-life opportunity to make a mark. Can you take it over?