A process converts a set of raw materials, r ₁ r ₂ ... etc to one or more products, p ₁ p ₂ ... etc.

In traditional Process Design, designers start with what may be perceived as the most important step. For example, they may consider first any reactor. They then look at the likely product spectrum from the reactor and plan any separation and recycle steps. Eventually, they come to a feasible design, which they can simulate and fine-tune. However, in nearly every case, there are millions of alternative feasible designs. Reactions and separations can be considered in alternative sequences, alternative separating agents can be considered, alternative energy integration schemes can be considered, and even alternative sets of co-products or by-products. Some of these alternatives can be radical improvements. For example, they can eliminate waste streams or expensive items of equipment. There are methodical ways of generating alternatives exist. However, they tend to be very labour intensive and still generate only tens of alternatives, where tens of millions can be shown to exist.

Chemcept-Design provides an automated method of generating and evaluating large numbers of alternative flowsheets. The optimization concentrates on generating promising structures. Thus, the priority is to generate promising choices of separation trains, promising choices of extracting agents, promising choices of reaction step, promising choices of recycle streams, and promising choices of places to return the recycle streams. It is not concerned with a close optimization of real variables such as temperatures, flow rates, diameters and lengths. This closer design is the realm of optimizers such Chemcept-Simanopt. The optimization employs a large number of integer variables to define the structure. To complete the optimization, Chemcept-Design discretizes all variables to give a fully integer optimization. An all-integer optimization is more efficient than a mixed-integer optimization in which some variables are integer and some real numbers.

The optimization starts by discretizing all streams. Thus, a stream such as r1 would be described by parameters such as:

• Composition
• Total Flow Rate
• Temperature
• Pressure
• Heat Content

The optimization starts by identifying all possible input and output streams and allocating them unique numbers from the hash algorithm. The user also specifies all the possible recycle streams (pure-component streams are potential recycles by default). These streams are also hashed and assigned unique numbers. We then start with the main input stream (a stream without which we would be considering another process entirely). Call this main-input stream r ₁ .

We consider all the operations that we could perform on r ₁ . The operations could be separation, reaction, heating, cooling, pumping or pressure reduction, or mixing with a recycle or second feed. (For reasons of efficiency, some operations are always combined. For example, we only consider heating or cooling in association with another operation that requires a cooler or warmer stream. This constraint avoids trivial processes that alternately heat and cool until they have accumulated sufficient cost to discount them). Call the process step "i" that operates on r ₁ S _i . The total list of potential process steps is then S ₁ S ₂ ... etc up to the number of possible steps. Each operation incurs a capital and running cost. It may also incur an environmental cost where our optimization covers minimization of environmental impact. We then have, for one process step:

r ₁ --> a _i with process step S _i and cost q _i .

In a separation step, we may have:

r ₁ --> a _i1 + a _i2 + a _i3 + ... , with process step S _i and cost q _i .

We restrict the steps so that the output streams ai etc map exactly onto our list of potential process streams. We achieve this mapping by restricting the properties of the stream (component flow rates etc) to fall exactly on one of the preset discrete values. In this way, we do not have to predefine every stream that might occur in the process.

For each potential operation, the total cost (financial or environmental) of processing the main feed stream to desired, or acceptable, products is obtained as follows. We sum the cost of the single operating step and the minimum cost of processing each of its outputs to acceptable products.

The optimization is thus recursive. Initially, we do not know the cost of processing any output streams to acceptable products. However, we perform an exactly similar operation on each of the output streams to obtain the missing costs. Thus, for each potential output stream in turn, we consider all the steps that could operate on it. (It will be a different set of steps than operated on the first stream). We continue the recursion until we do reach an acceptable output stream. At that stage, we step backwards to fill in the missing cost. We then step backwards and forwards until we have costed every stream and found the minimum cost of processing the main input stream.

The total computation is considerably reduced because, once we have found the minimum processing cost for a stream, we store it. When the stream arises next time, we used the stored cost instead of repeating the whole recursion. Using this look-up table drastically reduces the amount of computation. The basic algorithm is a form of Dynamic Programming, which is very efficient for such problems. Run times are further reduced by comparing the cost of the current operation on a stream with the least cost so far. When the cost is exceeded, the recursion is truncated at that point. Further exploration of processing steps will only add to the cost and cannot lead to a lower cost process.

The optimization includes many more refinements in order to handle recycles and energy integration efficiently.

All such integer optimizations are computationally NP complete, which means that run times increase at least exponentially with number of integer variables. However, we limit the computation by defining, in advance, the maximum number of streams that can arise in the optimization. We can then show that run time is limited by a bound proportional to N ^1.58 , where N is the permitted maximum number of streams. Having tabulated all the streams, and listed the optimal operations performed on them, we can generate the complete optimal process. The optimization is efficient at generating and evaluating a large number of process variants. For example, allowing 1000 streams allows over a million process variants to be evaluated. Allowing one million streams (modest by current computer capabilities) implicitly evaluates millions upon millions of process variants.

Note that, unlike conventional mixed-integer optimizations (such as Chemcept-Simanopt), each step of the optimization only simulates one operating step, not a complete process. Thus, we can generate a complete optimal process without having once simulated it as a complete process.

A further substantial benefit of the approach is its ability to generate multiple processes. Thus, we can generate all process options within a preset margin of the optimum. This ability is important. A cost and environmental optimization cannot simultaneously evaluate process operability. That needs to be checked for each of the potentially best processes. Furthermore, the inevitable uncertainties in cost estimation make it impossible to guarantee that the "optimal" process is indeed optimal. The additional 2nd best, 3rd best etc process variants are generated at negligible additional computational cost.

We can claim to be the leading exponents of this type of Process Synthesis. We have an extensive refereed publication record and a patent application for a process generated by the optimization. There are now competitors, but we originated the approach.

Development of this program has been underway for some years. Work was suspended to complete TomorrowsPrices and Flaresign. However, it is expected to recommence work early in 2005. Potential customers or collaborators are welcome to discuss developments.