Most complex facilities, such as refineries and chemical plants, use some form of linear programming (LP) software to plan feedstocks, unit conditions and even future investments. These models optimize a system of linear equations against a set of constraints, given an objective function that is usually profitability.
Specialized LP engineers maintain and update the linear, and in some cases nonlinear, models the solvers use. The end user is usually less experienced with the model itself and spends more time analyzing its outputs and turning them into actionable plans. To deliver the most value to the organization, both need to be aware of the issues that reduce the model's fidelity. I was one of the latter, an LP user, but I spent time in the model to understand how it worked, because I was often asked to explain in detail why a feedstock was or was not attractive to run.
A former colleague of mine liked to say, "All models are wrong. Some models are useful." I believe he was quoting someone else, and either way it is a good line for keeping planning models in perspective. What matters is how we use them, and knowing their limitations and pitfalls.
Hidden limits in the case files
An LP will always tell you it has reached an optimal solution, if it converges. That solution may be a local optimum. More insidiously, and probably more often, another user has buried a one-off limit somewhere: a unit capacity, a quality or a supply limit, set deep in the case files or even built into the model. These one-time overrides can quickly create a web of unintended limits that lead to strange optimum solutions.
Recognizing that this has happened is difficult. Apart from finding the limits by chance while investigating some strange behavior, the best prevention is to keep models and case files organized and to review them periodically.
Units linearized around one regime
Another issue is the operating regime the process unit models were tuned to. Unit models are usually centered on a small range and linearized there, so that the economics of that regime are easier to model and optimize. That works well unless the unit has an optimum, or a severe nonlinearity, with respect to feed qualities and operating conditions. We see this in conversion units such as fluid catalytic crackers (FCC), hydrocrackers and reformers, and in chemical units such as steam cracking furnaces.
There are well-documented methods and technologies to work around this and include some or all of the nonlinearity. They usually come at a cost in model stability, accuracy or runtime, which starts to erode the model's usefulness for its original purpose. Even where nonlinear approaches are in place, the LP engineer usually has to decide how to bias the model to match plant data as model mismatch is identified, which is where the line about all models being wrong applies again. It is best to be aware of the limits of the model and of the problems it was designed to solve: for instance, which crude or feed to buy, and not necessarily exactly what conversion to run.
Feed qualities that are already out of date
Inaccurate quality data on feeds to the plant is another problem for LP models. Crude assays are notoriously wrong the minute they are completed, because of contamination in the supply chain and field decline. Naphtha and gas oil data are usually out of date and represent a few marker qualities that existed at some point in the past. An accurate assessment needs the actual qualities provided by the trader.
Even within a refinery model, naphtha qualities can be significantly off when it comes to reforming yields and benzene. This is harder to fix, because it goes back to the crude assay and to how fractionation is represented in the model. Be careful with feed qualities when you get granular with the model output.
Where the plan and real-time optimization overlap
There is an inherent conflict, or overlap, between the LP and real-time optimization, because the two can arrive at different solutions for the same period. Offline kinetic models and LPs cannot have accurate feed qualities around the clock in some operating environments, and they may not match the process well in certain operating regimes. The plan is built on a snapshot of feed and unit behavior. In practice, it depends on recurring decisions made every shift by different people with different information.
What we see on the units
At Imubit I lead the Economic Engineering team, which analyzes optimization opportunities for our clients and how their plants are operating. In that work we see our deep learning models identify these different operating scenarios in real time, without feedstock information, and arrive at a better solution that can be implemented minute to minute. Seeing the technology work in this dynamic environment has put into perspective how static and approximate an LP planning model is.
That technology is Imubit's Deep Learning Process Control® (DLPC®). It learns a nonlinear dynamic model of each unit from the unit's own operating history, guided by first principles, and writes targets to the existing APC or DCS, inside limits set by plant engineers. DLPC® complements the LP. The plan still decides which crude or feed to buy, and closed-loop control pushes each unit toward its economic optimum as conditions move between plans.
