Subtitle: If A Human Can't Find It, The Result Is Unexpected
Computers are sometimes discussed as slaves to their programmers; that is, they produce only the results the programmer wanted when he (or she) wrote the software that runs in that computer. I have discussed this before on other forums, and this article addresses some of my experience in this arena.
My qualifications to discuss computers and software programming are as follows: software development, design, debugging, and various sorts of computer programming since 1971 (44 years at this time), from simple BASIC, Hewlett-Packard's programming on HP-35 pocket calculator, FORTRAN of various vintages (starting with FORTRAN 66 on IBM mainframes), Artificial Intelligence software in LISP and neural networks, Lotus 123 and MS Excel (tm), to html and similar programming on modern internet applications. Computing platforms covered a variety, such as IBM mainframes, CDC machines, programmable pocket calculators, desktop PC (personal computers), and modern laptops.
The primary purpose of my programming efforts has been related to chemical engineering tasks, where very large databases from a process plant running 24/7 provide information that must be retrieved, analyzed, processed, and results returned in a timely manner for appropriate decision-making. Also, very complex oil refining, petrochemical, and inorganic chemical process unit simulations (including kinetics in reactor systems) were developed and enhanced - including various forms of optimizers (e.g. LP, successive LP, and open-equation). In short, computers and software are merely tools to the chemical engineer, not our reason for living. We have real problems to solve in the real world, with (at times) hundreds of millions of dollars at stake (or more). There are almost always time constraints in the problems that require a quick solution, such that a program that runs too long is totally useless even if it provides the correct answer. The process unit conditions will have changed far too much for an answer to be useful. Time frames for computer solution can be measured in hours, but often a few minutes is required, and on rare occasions, a few seconds.
So, do the computers we use provide predictable, unsurprising results? Are they truly slaves to their programmers? No. Chemical engineers know very well that our software provide unexpected results on many occasions. This is a hard concept for many to grasp, perhaps because they have been conditioned to believe that a computer merely adds 1 plus 1 to obtain 2, but does it very, very quickly. And, I agree that computers can and (sometimes) do add 1 plus 1 to obtain 2. And, they do that very, very quickly.
Examples of unexpected results follow. One arena is in optimization of complex process units. Another is recognition of patterns, such as "this event X always happens after that event Y occurs, but only after Z time passes from event Y."
Complex process unit optimization.
Process modeling and optimization is sufficiently important in chemical engineering that, for example, a session at an AIChE conference was held recently (see link), with the session description as:
"Modeling is the art of simplification of complex physics underlying the chemical processes to account for observed phenomena and make falsifiable predictions. A good predictive model provides the basis for optimization of objective function in a multi-parameter space. This session invites talks that elucidate the practice of model building, the challenges involved in optimizing validated models and reduction of optimized results to practice."
In addition, a major division of AIChE is devoted to computing and optimization, the CAST division (Computing And Systems Technology Division) (see link). Their description reads:
"The CAST division provides relevant programs for AIChE members who share interests in computing and systems technology, especially in the analysis, design, and control of process and management systems. CAST also coordinates the Institute's activities with other societies active in this field."
Many other conferences, seminars, webinars, books, etc. are devoted to optimization in chemical engineering (see link).
The unexpected results occur when the process model, or process model with an optimizer produce a solution that a human could not have produced, especially within the timeframe required. Some may argue (and many have) that this is a matter of semantics, that the computer's results are within the realm of possible outcomes that the programmer allowed the computer to explore. The argument appears to be that, given enough time, even a human could have found the same solution. However, that defeats the purpose when, by definition, a solution is worthless if not produced within the required time constraints.
One personal experience follows, of an unexpected result in a simulation of a petroleum refining process unit; a vapor-recovery process for a Fluid Catalytic Cracker (FCC) unit in a large, integrated and complex refinery in the US. There was no chemical reaction in this process, merely five inter-connected towers with vapor-liquid equilibria, mass-transfer, heat-transfer, mass recycles, heat recycles, and absorption, all constrained by the typical issues of pumping capacity, compression capacity, heat exchanger capacity, and tower diameters. The goal, or objective function, was to maximize unit throughput without undue loss of valuable components to a fuel gas system. The process unit was simulated on an industry-standard process flowsheet software, then optimized with the internal optimizer. Manipulated variables included the lean oil flow rate into the primary absorber, sponge oil flow rate into the sponge absorber, total feed rate, pressures, temperatures, and various heat inputs and removals.
In this particular case, conventional, prior "wisdom" held that the lean oil flow rate was to be minimized - reduced to zero - because the lean oil material consumed energy due to being recycled. However, the simulation and optimizer showed that the energy savings were very small while the value of increased feed rate due to a non-zero lean oil rate was many times greater, indeed, extremely valuable. The solution was implemented with the predicted results being measured and then confirmed. (note the "... falsifiable predictions" wording above; this lean oil optimization certainly qualified). So, was this an "unexpected result?" I maintain that it was, because the then-existing management believed the path they had followed was optimal until the new operating paradigm was presented and implemented. They were quite impressed when the FCC unit was able to process a significant increment of feed (approximately 10 percent more per day).
Other examples of unexpected results are very common, almost too many to mention. Another refinery used a computerized kinetic simulation and optimizer on their FCC plant and found they could increase feed rate and conversion to a much more profitable state. The same has been done many times on other process units.
Pattern Recognition
As mentioned above, process plants, including oil refineries, have databases with large amounts of data. A process engineer routinely extracts data from the database and performs analyses to follow the progress of the unit. There may be catalyst deactivation, heat exchanger fouling, distillation efficiency reduction, among many other parameters that change rather slowly over time. Other changes are more rapid, sometimes requiring only minutes or even seconds to appear in the data. Where a pattern can be recognized, a good engineer can and should determine the cause. Indeed, it is fairly simple in these days to use a data-mining software to rapidly evaluate thousands of variables in pairs and other combinations to determine the extent of any correlation. In engineering, especially chemical engineering, linear fits are possible, but the physics of the process dictate that many times, a log or exponential, or quadratic fit are indicated.
An example from personal experience follows. In a complex oil refinery that processed heavy oils in a Delayed Coker Unit (DCU), and processed the virgin and cracked gasoils in a FCC, data analysis found a pattern: the cyclical production of heavy coker gasoil created an undesirable cyclical change in FCC operation. Simulation and optimization on the FCC showed that a better operating strategy was to store the coker gasoil for a short time rather than pump the coker gasoil as it was produced into the FCC system (note, there was a gasoil hydrotreater upstream, as usual). A steady flow of coker gasoil allowed the FCC controls to more easily optimize the unit; in effect, the control system was always "hunting" for the optimum as the coker gasoil rate fluctuated. This result was contrary to the established "wisdom" that it was more profitable to minimize all storage, and run intermediate streams between process units right away rather than into storage and back. The solution was presented, then implemented with great success. The result was unexpected in the eyes of the then-existing refinery management.
(Note: this is entirely consistent with my career as a process consultant; many times the conventional "wisdom" was false, based on invalid original assumptions, or the previously valid assumptions had changed materially. One refinery with a Hydrocracking Unit told me and my colleagues that their unit was optimized, thus there was no need for us to examine it. I asked when the latest optimization had been performed, and the reply was "a few years ago after startup." That refinery made a substantial increase in profit after being shown why a Hydrocracker Unit optimization should be performed on a periodic basis.)
Conclusion
It has been shown that unexpected results from computer software indeed exist, both for complex process unit optimization and for pattern matching. Other categories also exist, which may be the subject of future articles.
Roger E. Sowell, Esq.
Marina del Rey, California
copyright (C) 2015 by Roger Sowell
Sunday, June 7, 2015
Unexpected Results From Computers
Labels:
AIChE,
CAST,
delayed coker,
FCC,
hydrocracker,
optimization,
pattern matching,
unexpected results
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment