20.01.2013 Views

LP Modeling - Past, Present and Future

LP Modeling - Past, Present and Future

LP Modeling - Past, Present and Future

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Introduction<br />

<strong>LP</strong> <strong>Modeling</strong> – <strong>Past</strong>, <strong>Present</strong> <strong>and</strong> <strong>Future</strong><br />

By<br />

Michael A. Tucker, Senior Staff Consultant<br />

KBC Advanced Technologies, Inc., Houston, Texas<br />

Over the last 20+ years, we’ve seen tremendous changes in computing power. Our <strong>LP</strong><br />

systems have moved from mainframes to PC’s. In the old days, we submitted <strong>LP</strong> runs<br />

for overnight mainframe batch processing <strong>and</strong> then waited to pick up stacks of “high<br />

speed” printer output the next morning. Today, we solve substantially more complex <strong>LP</strong><br />

problems in mere seconds on our desktop PC’s.<br />

The <strong>LP</strong> modeling systems have changed substantially. Non-linear distributive recursion<br />

techniques have been enhanced in the <strong>LP</strong> systems. Swing cuts (for cut-point<br />

optimization) have been semi-automated. Multi-period <strong>and</strong> multi-refinery modeling<br />

capabilities have been enhanced. The linkage of crude assay data into the <strong>LP</strong> assay<br />

tables has been enhanced <strong>and</strong> semi-automated. Reformulated gasoline blending<br />

capabilities have been incorporated into the systems. And, or course, the latest<br />

versions of our favorite spreadsheet programs have always been available for<br />

preparation of our <strong>LP</strong> model data.<br />

<strong>LP</strong> model structure has also changed substantially. We have moved from non-recursed<br />

yield-driven models with fixed stream properties to recursed property-driven models.<br />

Process unit representations have changed from multiple “mode” type yield structures to<br />

base-delta representations. Now, current <strong>LP</strong> systems offer embedded process<br />

simulation <strong>and</strong> other non-linear representation capabilities to provide even more<br />

accuracy <strong>and</strong> realism for our refinery processing <strong>LP</strong> representations.<br />

The area of <strong>LP</strong> structure, however, seems to lack clarity. In the planning services<br />

consulting business, we see a variety of client models in a variety of modeling systems<br />

from around the world. Most <strong>LP</strong> users have upgraded to the latest, most powerful PC<br />

workstations <strong>and</strong> operating systems. Most <strong>LP</strong> users have also migrated their models to<br />

the latest version of their vendor’s <strong>LP</strong> system. However, the variety <strong>and</strong> types of<br />

modeling philosophy, structure <strong>and</strong> modeling techniques used within these systems is<br />

seemingly endless. There is definitely little “st<strong>and</strong>ardization” of <strong>LP</strong> model structure <strong>and</strong><br />

data representations in the <strong>LP</strong> models.<br />

The commercial <strong>LP</strong> systems (Aspen PIMS, GRTMPS, etc.) offer the users a great deal<br />

of flexibility for representing refinery processing via a variety of modeling techniques. As<br />

CC-01-153<br />

Page 1


a result, individual refinery <strong>LP</strong> model developers have used a variety of methods <strong>and</strong><br />

structure to represent their process unit submodels including: Multiple modes, basedelta<br />

modeling, embedded simulation, pooling <strong>and</strong> distributive recursion. All of these<br />

techniques have been applied to varying degrees in various models.<br />

So, the question is: What’s is the best <strong>LP</strong> modeling method? Why?<br />

In this paper, we discuss the trends <strong>and</strong> industry practices in <strong>LP</strong> refinery modeling.<br />

What has changed in <strong>LP</strong> modeling <strong>and</strong> why has it changed? What are the common<br />

modeling techniques, structure <strong>and</strong> data generating techniques that are being used<br />

today? Where are we headed with modeling structure?<br />

Hopefully, this paper will stimulate thinking about your refinery <strong>LP</strong> model. How does<br />

your model structure <strong>and</strong> data compare with industry best practices? Should you<br />

consider upgrading your <strong>LP</strong> model? What are the possible benefits? What are the<br />

risks?<br />

The goal is clear – what refiners want <strong>and</strong> need are <strong>LP</strong> planning models that accurately<br />

represent the true capabilities <strong>and</strong> limitations of their refining facilities. We want the <strong>LP</strong><br />

model to give us sound advise about crude selection, process optimization, oil<br />

movements, product blending <strong>and</strong> product optimization.<br />

What isn’t always clear is what are the best modeling technologies <strong>and</strong> techniques to<br />

achieve superior accuracy from the model? Also, what is the appropriate degree of<br />

accuracy considering the trade-offs between the desire for simplicity, ease of use, <strong>and</strong><br />

the drive for accuracy?<br />

<strong>Past</strong> <strong>LP</strong> <strong>Modeling</strong><br />

Going back a number of years (15 to 20), we had what I’ll call the Pre-Recursion type<br />

models. These models had no stream pooling <strong>and</strong> no recursion. The crude unit models<br />

were presented by a series of yield structures for each crude. The characteristics were:<br />

• Each cutting scheme (max naphtha, max kerosene, etc.) had a separate yield<br />

structure (mode) for each crude.<br />

• The major side-cuts from each crude (<strong>and</strong> from certain cuts from each cutting<br />

scheme) were unique streams, with unique names <strong>and</strong> unique (fixed) qualities.<br />

• Generally, the crude assay table data was generated by a crude assay system<br />

(containing a library of crude oils). Yields <strong>and</strong> properties from the assay system<br />

were generally those predicted from laboratory TBP distillations. In many cases,<br />

the systems were automated to generate the <strong>LP</strong> crude assay tables in the <strong>LP</strong><br />

assay table format.<br />

CC-01-153<br />

Page 2


The downstream process unit sub-models were also represented by a series of multiple<br />

yield structures. The characteristics of the process unit sub-models were:<br />

• Each feed to a downstream process unit was from a side-cut from a particular<br />

crude.<br />

• Each process unit feed has one or more yield structures (modes) representing<br />

the processing of each unique feed under specific operating conditions e.g. a<br />

particular reactor temperature.<br />

• The products from each mode had fixed qualities. Frequently, each feed/mode<br />

combination would produce streams with different fixed qualities.<br />

• The yields were typically generated using simulation models. Each side-cut from<br />

each crude was processed through the simulator at a particular operating<br />

conditions (e.g. severity) to produce a unique set of yields <strong>and</strong> product properties<br />

for the feedstock. In many cases, the simulators were automated to generate<br />

the necessary yield structures for the <strong>LP</strong> model.<br />

In our efforts to further differentiate one crude from another, we frequently generated<br />

literally hundreds of yield structures for process unit sub-model to represent each<br />

possible crude side-cut at multiple operating conditions <strong>and</strong> multiple cutting schemes.<br />

Frequently, the process unit might be structured to produce anywhere from 4 to 20+<br />

versions of each product stream (each with unique qualities associated with a particular<br />

crude <strong>and</strong>/or cutting scheme).<br />

Models of this type tended to have the following overall characteristics:<br />

• There were generally 3 to 10 times as many individual streams in the model as<br />

there were streams in the “real” refinery.<br />

• There were generally 10 to 20 times as many final product blending options as<br />

there were actual component blending options available in the “real” refinery.<br />

Distributive Recursion Technique<br />

During a Chevron <strong>LP</strong> training class at El Segundo, California in 1977, Bill Hart, a senior<br />

mathematician from Haverly Systems, was working with Don White, a senior <strong>LP</strong><br />

modeler from Chevron. Don’s complaint was that these types of multiple yield <strong>and</strong><br />

mode type <strong>LP</strong> models tended to over-optimize the processing <strong>and</strong> blending of individual<br />

crude <strong>and</strong> their associated side-cuts throughout the refinery. The model frequently<br />

overstated the value difference between individual crudes. Don wanted a better way.<br />

During that class, Bill Hart developed the mathematics for the recursion technique that<br />

became known as Distributive Recursion (DR). Up to that time, some attempts had<br />

been made to use a simple recursion technique. The Distributive Recursion technique<br />

CC-01-153<br />

Page 3


added the critical linkage between upstream changes in pool qualities to the quality<br />

changes in the downstream destinations. Early versions of the DR technique were<br />

slow <strong>and</strong> difficult to work with. Over the years since then, the technique has become<br />

faster, better, <strong>and</strong> more reliable. The technique is increasingly popular <strong>and</strong> is now<br />

widely accepted in the <strong>LP</strong> modeling systems <strong>and</strong> refinery models.<br />

Current <strong>LP</strong> <strong>Modeling</strong> Practices<br />

As mentioned earlier, there is an infinite variety of modeling techniques currently being<br />

used. However, we can, at least, categorize <strong>and</strong> discuss current modeling practices in<br />

the various areas of the <strong>LP</strong> model structure.<br />

Crude Distillation Swing Cuts<br />

Swing cuts are increasing used in <strong>LP</strong> assay tables to represent the refinery’s flexibility<br />

to alter cut-points for optimization of side-cut yields <strong>and</strong> properties. When used, swing<br />

cuts have generally replaced the older multiple “mode” type of yields structures. The<br />

Aspen PIMS system, for instance, has provided a Type 4 swing cut in their CRDCUTS<br />

table. The system will then automatically generate the necessary structure for blending<br />

the swing cut up <strong>and</strong> down. Swing cuts are frequently used for Naphtha/Kerosene,<br />

Kerosene/Diesel cuts <strong>and</strong> for Gasoil/Bottoms cuts as well as others. A majority of <strong>LP</strong><br />

models now employ swing cut architecture in at least some of the crude distillation side-<br />

cuts. In general, the swing cuts are also used along with side-cut property recursion<br />

techniques such that main side-cut yields <strong>and</strong> properties are impacted by the swing cut<br />

blending.<br />

Crude Assay Recursed Properties<br />

Most crude assay tables now include recursed properties for the various side-cuts.<br />

Typically, the side-cuts in the model now match the physical side-cuts from the “real”<br />

refinery, with the exception of the swing cuts. The individual side-cuts generally have<br />

anywhere from 3 or 4 recursed properties to over 20. The average number of recursed<br />

properties in most models is about 7 to 10. The side-cut recursed properties are not<br />

just used for product blending. The properties are now frequently used as product yield<br />

<strong>and</strong> property drivers in downstream process units sub-models (e.g. % Naphthenes <strong>and</strong><br />

% Aromatics for Reformer sub-models).<br />

Commercial Distillation Properties<br />

<strong>LP</strong> crude assay data is frequently generated by using one or more of the vendor crude<br />

assay libraries in conjunction with a commercial crude assay system. The assay data<br />

from these libraries is based on laboratory distillation results. In the past, most <strong>LP</strong>’s<br />

included these laboratory predicted properties, rather than commercial unit properties.<br />

Increasingly, <strong>LP</strong> modelers are interested in getting the commercial unit distillation<br />

results into the <strong>LP</strong>. Right now, there are three main techniques that are in common use:<br />

CC-01-153<br />

Page 4


1. Some modelers “offset” the laboratory properties in the <strong>LP</strong> model to more<br />

accurately match the commercial results. This works reasonably well in those<br />

situations where the crude slate is relatively stable.<br />

2. In recent years, the vendor assay systems have added features designed to<br />

allow a degree of side-cut overlap with associated property predictions. The<br />

systems require the user to supply the parameters for the column tuning. These<br />

parameters have been used with varying degrees of success.<br />

3. Those refiners who maintain a tuned column simulation model (e.g. KBC<br />

Petrofine DISTOP) generally use this column simulation along with an assay<br />

library <strong>and</strong> system to generate the yields <strong>and</strong> properties for the <strong>LP</strong> assay table.<br />

With this system, each of the library crudes is processed through the column<br />

simulation to then predict the yields <strong>and</strong> properties for the side-cuts based on<br />

the tuned column simulator. Multiple runs of the simulator are required to backcalculate<br />

the properties of the swing cuts used in the <strong>LP</strong> model. Systems are<br />

now becoming available to automate the multiple simulator runs <strong>and</strong> the back<br />

calculation processes.<br />

In recent years, the <strong>LP</strong> systems have added the capability to use multiple assay tables.<br />

Hence, it is now convenient to provide customized <strong>and</strong> tuned yields <strong>and</strong> properties for<br />

each of the refinery’s physical <strong>and</strong>/or logical distillation column operations.<br />

Base-Delta Process Unit Sub-Models<br />

Concurrent with the development <strong>and</strong> implementation of DR is the use of base-delta<br />

modeling techniques for major process unit sub-models. The base-delta modeling<br />

technique has the following characteristics:<br />

1. A single base yield structure provides the yields <strong>and</strong> product properties<br />

associated with a typical quality feed at normal operation conditions. This yield<br />

structure is customized <strong>and</strong> tuned to the particular refinery process unit. In some<br />

variations of this technique, multiple base yields are provided at alternative<br />

severities of operation. In most cases, the base yield structure is generated<br />

from a single run of a tuned simulator for the particular process unit.<br />

2. Feed property drivers are used to provide shifts (or correctors) for changes in<br />

feed properties relative to the base feed quality. These shift correctors represent<br />

the linear change in yields (<strong>and</strong> product properties) as a function of changes in<br />

feed properties. These shift correctors are generally calculated by the use of the<br />

process simulators. DR techniques are used to provide the necessary feed<br />

properties from the various upstream sources <strong>and</strong> feed pools.<br />

There are two common techniques used to generate these correctors:<br />

CC-01-153<br />

Page 5


a. The perturbation technique changes each feed property independently (up<br />

<strong>and</strong> down) <strong>and</strong> then calculates the linear shift from the perturbation cases.<br />

b. A multi-variable linear regression technique is used to calculate the linear<br />

shift correctors based on the regressed results for product yields <strong>and</strong><br />

properties from a large number of feed property scenarios when run<br />

through the simulator.<br />

3. Operating variable drivers are provided to shift yields (<strong>and</strong> product properties) off<br />

the base for changes in operating conditions (typically severity). Again, the<br />

process simulators are generally used to generate the delta shifts for these<br />

operating conditions.<br />

4. DR techniques are frequently used to recurse on key product properties. The<br />

base, feed property drivers, <strong>and</strong> operating variable shifts all contain coefficients<br />

that calculate the appropriate recursed product properties. Process unit product<br />

stream properties are either variable (recursed) or fixed. In general, if the<br />

product property remains relatively constant regardless of the feed <strong>and</strong>/or<br />

operating shifts, then the property may be fixed. Otherwise, the property should<br />

be recursed. The use of product stream recursion has eliminated the need for<br />

multiple versions of the same stream (as used in pre-recursion models). Now,<br />

the streams in the <strong>LP</strong> model (represented by pools with recursed properties)<br />

more closely match the streams in the “real” refinery.<br />

5. Many of the major process unit sub-models now use swing cuts for key cutpoint<br />

optimization representations. Multiple runs of the process simulators are<br />

generally used to back-calculate the yields <strong>and</strong> properties for the swing cuts used<br />

in the process sub-models.<br />

6. Most base-delta models now use multiple capacity constraints. Many of the older<br />

models simply had one (maximum throughput) constraint. With base-delta<br />

models using severity shifts, it is now appropriate to include several other<br />

capacity constraints associated with operating constraints <strong>and</strong> variables e.g.<br />

maximum air blower limits on an FCC unit or main fractionator side-cut draw<br />

limits.<br />

Local Optimal Problems<br />

Most of the current <strong>LP</strong> models have some degree of pooling <strong>and</strong> property recursion.<br />

The DR technique requires initial guesses for pool qualities <strong>and</strong> fractional distributions<br />

of the pools to downstream destinations. As with any non-linear technique, there will be<br />

a risk of local optimal solutions i.e. a solution that does not represent the highest<br />

possible objective function. In all local optimal cases, the initial guesses <strong>and</strong> the<br />

subsequent recursion calculations lead to a solution that is not the global optimum.<br />

CC-01-153<br />

Page 6


For models that contain a moderate (or higher) degree of recursion, there are only two<br />

situations:<br />

1. The model users have experienced local optimal problems <strong>and</strong> they know they<br />

exist.<br />

2. The model users don’t know they have local optimal problems (however, they do<br />

exist but they have not yet been discovered by accident or testing).<br />

We’ve found that almost every model that contains a moderate (or higher) level of<br />

recursion experiences local optimal problems (some more than others). This is a<br />

serious problem that can lead to a lack of confidence in the model results. Local<br />

optimal problems in recursed <strong>LP</strong>’s cannot be completely eliminated but they can be<br />

managed. It takes a combination of:<br />

1. Good model structure that avoids unnecessary recursion <strong>and</strong> things like<br />

cascading recursed pools <strong>and</strong> large numbers of downstream destinations for<br />

recursed pools.<br />

2. Attention to correctly setting the initial guesses <strong>and</strong> the recursion control<br />

parameters. The system default recursion control parameters are not always the<br />

best settings.<br />

3. Testing for local optimal conditions <strong>and</strong> then analyzing <strong>and</strong> underst<strong>and</strong>ing the<br />

conditions under which they occur <strong>and</strong> correcting those conditions.<br />

Blending<br />

In the blending area, current <strong>LP</strong> models contain significantly more property<br />

specifications than in the past. The sophistication required for the blending equations is<br />

increasing – as evidenced by reformulated gasoline. Increasingly, the blend<br />

components in the model are nearly the same as those that exist in the “real” refinery<br />

(via recursed pools) <strong>and</strong> the component properties are frequently linked all the way<br />

back (via distributive recursion) to the properties of the side-cuts in the crude assay<br />

tables.<br />

Multi-Refinery <strong>and</strong> Multi-Period <strong>Modeling</strong><br />

There is an increasing use of multi-period <strong>and</strong> multi-refinery modeling by the user<br />

community. Mainly, this trend is the result of faster computers <strong>and</strong> enhanced features in<br />

the <strong>LP</strong> modeling systems for h<strong>and</strong>ling the parameters <strong>and</strong> input associated with multiperiod<br />

<strong>and</strong> multi-refinery. (It’s also the results of all of those mergers <strong>and</strong> acquisitions in<br />

the industry).<br />

There is one caution, however, in that recursed models tend to be unstable (i.e. local<br />

optimal <strong>and</strong>/or non-converged) when attempting to use both multi-period <strong>and</strong> multi-<br />

CC-01-153<br />

Page 7


efinery in the same case. Also, there are limitations on the use of multi-refinery. In<br />

general, no more than about 3 refineries should be attempted with recursed <strong>LP</strong> multirefinery<br />

models. Large recursed multi-refinery models tend to be unstable as<br />

represented in the following graph.<br />

Recursed Pools<br />

600<br />

500<br />

400<br />

300<br />

200<br />

100<br />

1000 3000 5000 7000 9000<br />

Model Maintenance<br />

1<br />

2<br />

Stable<br />

Matrix Rows<br />

3 Refineries<br />

Unstable<br />

This paper is mainly about <strong>LP</strong> model structure. However, there are some important<br />

points to be made about generating the <strong>LP</strong> data <strong>and</strong> maintaining the <strong>LP</strong> model. In the<br />

past, we occasionally (every few months) compared the actual plant process data with<br />

the <strong>LP</strong> predicted yields. We looked at combinations of test run results, historical<br />

process data, <strong>and</strong> yield accounting data when updating <strong>LP</strong> models <strong>and</strong> sub-models. <strong>LP</strong><br />

sub-models were not frequently updated (maybe once every couple of years) <strong>and</strong> the<br />

methodology for updating the <strong>LP</strong> sub-model was not very well defined.<br />

Currently, there are two main best practice methods for monitoring <strong>LP</strong> performance <strong>and</strong><br />

maintaining <strong>and</strong> updating <strong>LP</strong> models. First, an overall refinery backcasting process may<br />

be used to identify overall model weaknesses (e.g. refinery gain higher than actual) <strong>and</strong><br />

profit opportunities. Backcasting is comparing a previous month’s actual results against<br />

the plan <strong>and</strong> against an <strong>LP</strong>-actual case (where the <strong>LP</strong> case attempts to match actual<br />

results). Many refineries conduct backcasting on a regular basis (at least several times<br />

each year). <strong>LP</strong> maintenance activities are frequently based on the backcast results.<br />

The second major activity is for process engineers to monitor their process units on a<br />

weekly or bi-weekly basis. Lab samples, along with plant historian data are used to<br />

compare the actual process unit results (yields <strong>and</strong> properties) against the <strong>LP</strong> predicted<br />

CC-01-153<br />

Page 8


esults for the same snapshot period. Process engineers <strong>and</strong> planners monitor <strong>and</strong><br />

compare the actual against the <strong>LP</strong> predicted <strong>and</strong> decide if the <strong>LP</strong> sub-model needs<br />

updating. In most cases, a process simulator model may be re-calibrated <strong>and</strong> used to<br />

generate the <strong>LP</strong> base <strong>and</strong> delta correctors on an as-needed basis. With this technique,<br />

process unit sub-models may be updated as frequently as several times a year using<br />

plant data <strong>and</strong> tuned simulator models.<br />

<strong>Future</strong> <strong>LP</strong> Developments<br />

The <strong>LP</strong> system vendors are now touting the virtues of the latest major <strong>LP</strong> system<br />

enhancement: simulator interfaces. With the simulator interface, the <strong>LP</strong> system may be<br />

directed to an outside application during each recursion pass. This outside application<br />

may be as simple as a single non-linear equation or as complex as several large<br />

complex process simulation models.<br />

The concept is that model coefficients that were previously static (i.e. unchanged during<br />

recursion) now become dynamic (changing after each recursion pass). For example,<br />

the feed % naphthene <strong>and</strong> % aromatics linear yield shift correctors commonly used in<br />

reformer <strong>LP</strong> models are generally based on particular feed qualities <strong>and</strong> severities.<br />

These linear correctors are calculated externally during the model development <strong>and</strong><br />

then built into the model. These yield correctors are not updated during recursion. The<br />

<strong>LP</strong> model predicted yields become less accurate if the <strong>LP</strong> optimized feed deviates<br />

significantly from the base feed quality assumptions.<br />

With the simulator interface option, these linear feed property correctors may now be<br />

calculated <strong>and</strong> updated during each recursion pass, <strong>and</strong> then used for the next<br />

optimization pass. As the model optimizes the feed quality <strong>and</strong> severity after each<br />

pass, the naphthene <strong>and</strong> aromatics correctors are then adjusted to match the last pass<br />

results. This improves the accuracy since the final converged solution of the <strong>LP</strong> more<br />

closely matches the results of the simulation prediction.<br />

However, the risk of a local optimal solution may increase, since more <strong>and</strong> more<br />

coefficients are recursed <strong>and</strong> the initial starting assumptions for feed quality <strong>and</strong><br />

severity become increasingly important as they may influence the final converged<br />

solution.<br />

A number of refiners have successfully developed useful <strong>and</strong> reliable applications for<br />

the simulator interface. There are a number a relatively simple non-linear applications<br />

being used where previously unsolvable non-linear relationships have now been<br />

h<strong>and</strong>led with the simulator interface. For instance, in one application, we needed to<br />

control the percent of a particular feed to a process unit. In this particular case, the<br />

percent was an unknown <strong>and</strong> the process unit feedrate was also an unknown. This was<br />

previously unsolvable with DR. However, with the simulator interface, it was now<br />

possible to externally calculate the correct percent (based on the first optimized<br />

solution) <strong>and</strong> then update the percent following each recursion pass.<br />

CC-01-153<br />

Page 9


Larger simulator interface applications have also been tested <strong>and</strong> developed using, for<br />

example, embedded reformer simulator models, FCC simulation models <strong>and</strong>, most<br />

recently, crude unit simulation with cutpoint shifts <strong>and</strong> cutpoint optimization (replacing<br />

swing cuts).<br />

Will this be the future of <strong>LP</strong> models? Perhaps. There are a number of issues to be<br />

solved: slow calculations, local optimal problems, complexity of data input, complexity<br />

of model output, etc. History would suggest that these problems can <strong>and</strong> will be<br />

solved. Also, the general trend over the years has been towards the use of additional<br />

non-linear techniques (mostly recursion) driven by the refiners desire for improved<br />

accuracy. Certainly, the simulator interface is a logical step in that same direction of<br />

improved accuracy.<br />

Conclusion<br />

<strong>LP</strong> systems accommodate a variety of modeling technique, structure <strong>and</strong> philosophies.<br />

Your current <strong>LP</strong> model structure is usually a complex function of the particular refining<br />

configuration, the <strong>LP</strong> system, economic drivers, logistical operational constraints,<br />

process unit simulation model availability, initial <strong>and</strong> legacy model structure, <strong>LP</strong><br />

maintenance, backcasting analysis, <strong>and</strong> past <strong>and</strong> current <strong>LP</strong> modeler knowledge <strong>and</strong><br />

experience.<br />

The industry, in general, is trending towards models that use pooling <strong>and</strong> distributive<br />

recursion techniques to provide more realistic <strong>and</strong> accurate representations of the<br />

refinery in the <strong>LP</strong> system.<br />

What are the benefits of <strong>LP</strong> improvements? This has always been a difficult area to<br />

address. The KOA paper from last year’s conference suggests one method. Intuitively,<br />

most refining companies recognize the value of improved accuracy in their refinery <strong>LP</strong><br />

representations <strong>and</strong> the technology has been moving in that direction over the years.<br />

We see improved <strong>LP</strong> accuracy in two areas: absolute accuracy <strong>and</strong> incremental<br />

accuracy. Improved absolute accuracy is achieved by frequent tuning <strong>and</strong> updating of<br />

the <strong>LP</strong> base yields <strong>and</strong> properties. Improved incremental accuracy is achieved through<br />

superior <strong>LP</strong> modeling structure that provides the correct effects for incremental changes<br />

throughout the refinery – from crude to products. Improvements in both of these areas<br />

may lead to millions of dollars of annual profit improvement resulting from plans <strong>and</strong><br />

operating decisions that better utilize the refining asset.<br />

The following table contains a checklist of best practice <strong>LP</strong> modeling features <strong>and</strong><br />

structure (discussed above) that should be considered <strong>and</strong> evaluated for your particular<br />

modeling circumstances.<br />

CC-01-153<br />

Page 10


Every refinery <strong>LP</strong> model situation is unique. Some of these features may not be best<br />

suited for your particular circumstances. However, in general, if your model structure<br />

lacks these features, you may wish to consider the merits of an <strong>LP</strong> upgrade.<br />

<strong>LP</strong> Model Structure Checklist<br />

Streams in the <strong>LP</strong> model generally match streams that exist in the refinery �<br />

<strong>LP</strong> Model uses pooling with recursion on key properties of the pools �<br />

Crude unit side-cut properties are based on commercial distillation<br />

�<br />

performance on individual crude units. Tuned distillation simulation is used<br />

to generate data for the <strong>LP</strong> assay tables.<br />

Swing cuts are used in crude units <strong>and</strong> downstream process unit <strong>LP</strong> sub- �<br />

models to represent cut-point optimization capabilities<br />

Base-delta <strong>LP</strong> structure for major downstream process unit representations �<br />

Tuned simulators used to generate base <strong>and</strong> delta yield <strong>and</strong> properties for �<br />

major downstream process unit <strong>LP</strong> models<br />

Process unit <strong>LP</strong> models include both key feed property drivers <strong>and</strong> key �<br />

operating variable shifts<br />

Multiple, realistic process unit constraints �<br />

Local optimal risk minimized with appropriate structure <strong>and</strong> recursion �<br />

control settings<br />

Testing for <strong>and</strong> correcting local optimal conditions �<br />

Frequent backcasting for <strong>LP</strong> model audit <strong>and</strong> opportunity evaluation �<br />

Process unit routine monitoring, evaluation <strong>and</strong> <strong>LP</strong> process model updating<br />

based on tuned simulation models<br />

�<br />

About the Author<br />

Michael A. Tucker is a Senior Staff Consultant at KBC Advanced Technologies, Inc.<br />

based in Houston, Texas. Mike is currently responsible for providing Planning Services<br />

to worldwide refinery clients, including the management of <strong>LP</strong> upgrade projects. Mike<br />

has 31 years of oil industry experience working, supporting <strong>and</strong> consulting on <strong>LP</strong><br />

planning for Chevron Corporation, Caltex Petroleum Corporation <strong>and</strong> KBC Advanced<br />

Technologies. Mike holds a B.S. in Chemical Engineering from Purdue University.<br />

Petrofine ® is a registered trademark of KBC Process Technologies, Ltd. Aspen PIMS is a registered<br />

trademark of Aspen Technology. GRTMPS is a registered trademark of Haverly Systems, Inc.<br />

CC-01-153<br />

Page 11

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!