A process converts a set of raw materials,
r
_{
1
}
r
_{
2
}
... etc to one or more products,
p
_{
1
}
p
_{
2
}
... 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 finetune. 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 coproducts or byproducts. 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.
ChemceptDesign 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 ChemceptSimanopt.
The optimization employs a large number of integer variables to define the
structure. To complete the optimization, ChemceptDesign discretizes all
variables to give a fully integer optimization. An allinteger optimization is
more efficient than a mixedinteger 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
This stream is represented in ChemceptDesign as a single integer number. All
the flow rates and temperatures within every stream are discretized so that
each can be represented by an integer. In principle, the streams could simply
be number as: 1 = the first stream we locate, 2 = the second stream we locate
etc. However, this approach would require us to check every stream that arises
against the full list of streams that we have to date. Instead, we use a
simple algorithm that generates a number directly from the stream composition
etc. The algorithm is designed to give a very high probability that there will
be a unique number for each stream. It is then only necessary to check that
any stream we already have with the same number is, indeed, the same stream.
In a typical optimization, we may generate millions of different streams. The
algorithm (known as a hashing algorithm) that generates a nearlyunique number
then reduces stream search time by a factor of millions.
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 (purecomponent 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 maininput
stream
r
_{
1
}
.
We consider all the operations that we could perform on
r
_{
1
}
. 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
_{
1
}
S
_{
i
}
. The total list of potential process steps is then
S
_{
1
}
S
_{
2
}
... 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
_{
1
}
> a
_{
i
}
with process step
S
_{
i
}
and cost
q
_{
i
}
.
In a separation step, we may have:
r
_{
1
}
> 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 lookup 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 mixedinteger optimizations (such as
ChemceptSimanopt), 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.