In many markets there are seasonal variations in refinery product specifications. Maximum vapour pressure for gasoline is usually reduced in the summer while cloud point for diesel needs to be colder in winter. Where such properties are constraining, the differences will have an impact on refinery operations and blending, and should, therefore, be taken account of in planning models. GRTMPS offers a specific feature for defining seasonal variations in product specifications so that you can use the same product codes all the time but indicate the season by period
The specification looks like this:
“ALL” is the hard-coded name for specifications which apply in any season. Where specifications change with season, they are listed under the season codes that have been defined for the model – here WIN and SUM.
The Season for each period is selected on the Periods Panel by listing the days for which it would apply.
If the days assigned to seasons don’t add up to the duration, the model will pro-rate them. (If you can’t see any season columns, look at the bottom for the “Show Seasons” boxes and tick.) If you are using seasonal settings, you don’t put any days in ALL. The season codes themselves are defined for the model on the Seasons tab. You may list as many as you like. If you are distinguishing gasoline and diesel blends you can use distinct seasons for them. If using table-based input, the seasons are assigned to the periods in TABLEs 002.0/002.1 whose columns define the season codes. The specifications in the product point 4 tables will have seasonal columns just as they do on the panel input shown above. Note that any specification that does not have a value for all the seasons that are active in the period will be ignored (with a warning).
As the product always has the same code, it’s easy to set up your price and demand data, and to sum over or compare periods and cases. However, many modellers prefer to set up multiple products with distinct names, selling the one(s) that are required in each period, even though the model will be bigger and the input data more complex. Why would you do that? Mostly it relates to handling multiple seasons in the same case – between and within periods.
Averaged Specifications:
If you split the time in the period across more than one season, then GRTMPS will calculate an average pro-rated specification.
– you will end up, for example, with something between the winter and summer vapour pressure.
This is something of a mathematician’s approach – the assumption that the impact of changing the specification is linear so that producing all the product to an average spec is the same as blending the same proportions of it to each. From an economic and monthly average production point of view that might be an workable assumption. Over-optimisation relative to the harder seasonal requirement will be balanced by some under-estimate of the relief you get from the easier one. I have had a client point out to me that their refinery does gradually shift from one target to another for cloud, which is determined by cut point and crude selection, so an average is a reasonable driver for their monthly planning.
But I do have doubts about an average being a sensible assumption all the time. If the specification is highly constraining and becomes increasingly difficult to meet as you move towards its more extreme value, the over-optimization for not having to meet it may well outweigh the under-optimization from not allowing the lowest value. Another client, observing that their model was making unrealistic amounts of product (and therefore money) when effectively given a margin on the summer LPG and Gasoline specifications, has switched to using the most difficult season for each product in their annual budgeting cases as a more conservative assumption – which ends up being summer for gasoline and winter for diesel and fuel.
One Season Per Period
You can avoid average specifications by separating them into different periods, each with one season, as in the example above. Instead of setting the periods by the calendar, set them by the seasonal changes. You may need to break up your plan into smaller parts, to get a single spec in each time frame for both gasoline and diesel as they don’t always change at the same time when they are not synchronized. – so Summer+Summer, Summer+Transition1, Winter+Transtion2, etc. While your first instinct might be to use a multi-period model, you can sometimes run these as individual single period cases and add up the results – a virtual “Total” case in the Report Generator is useful for this. Bearing in mind also that each period is like adding another copy of the model to the matrix and run times are super-linear to size, this really is a useful option -not only will the individual cases by faster than a big one, you can use the multi-core option to run them all at once. This is quite a good approach for long term budget planning. However, sometimes you do have to set up a multi-period model. If you have limits on purchases/sales/emissions etc. that need to be applied over the whole of the planning timeframe they need to be in one case. Also, if storage management is an optimization issue for your business and/or if the time periods are short enough that inventory represents a significant proportion of the total material, then you will need to make a multi-period model. If you do end up with something big and difficult to solve - remember that you can solve the individual periods as separate cases, and use those 181 files as a warm start for the multi-period as it is likely that many of the details of those solutions will still apply even in the bigger picture.
Things become more complicated, though, if there will be product made in one period but sold in another which has a different season. This is because the product will be made to whatever specification applies at the time it is blended and then simply assumed to be on spec. Is that a problem for your planning? It depends. If you are moving to a less constraining limit, then your inventory is still valid product, just with giveaway. If you are going from the easier to the harder spec though, then the model is getting away with making off-spec product – and if there is any incentive to do so, it will take advantage of the opportunity, distorting your results to some degree.
Mulitple Product Codes
Multiple stream names allow you to be more specific about blending to each spec within a single period. You can have three diesel grades, for example Diesel:Summer, Diesel:Intermediate and Diesel:Winter. The specifications would be all be given under the ALL column – identical except for those elements determined by the season. Periods would not have seasonal assignments. Instead, you control which products are blended, normally by what you sell – although you can also control blend quantities. You will need to put some limits or the model will, of course, just make the easiest specification. You could limit by quantity (individually and/or as a group). Alternatively, if you want to leave the amount open you could set a ratio between grades. Below I show the membership for limiting the percentage of Summer specification diesel sold. The Winter % control has the same structure, but the 100 is on DSW instead. If both of these are set for a period, the portion of transition is implied,
Period M1 is configured to sell Winter specification product only. Period M2 is a 70/30 split between summer and transition with Winter blocked.
If a product would be off-spec if stored for the following period, then you can block it from inventory, but you could allow the model to blend ahead of time to the coming specification and store it for sale in a later period. Of course, you will have to make some effort in your reporting and post-solution analysis to add up over the streams, or line them up for comparison. One trick I have seen to help with this is to configure the products as pools, and then combine them into a single stream in the required proportions for selling. Inventory would be the individual pools to maintain the information about which season it was made for.
There are some downsides to this multi-stream approach that you need to consider. One is model size. That won't be a significant concern if you are running a single site and just a few periods – but if you have a big corporate model covering multiple sites, the replication of the products does have a noticeable impact. Product screening (PRDSCRN. See Generate Matrix tab in g5) can be used to remove the ones that are not sold –
but in a multi-period model where all the seasons are involved at some point, then they will all remain active. (If you are working with Table based input, you do have a bit more control as you can use the blend exclusions in 014.0 / 015.0 to turn products off by period by connecting the entries to those in 002.0/002.1)
Multiple product models can display recursion instability from the swapping of components between blends that are essentially very similar from pass to pass. Gasolines already often have issues because the standard grades typically differ only on octane which is not necessarily constraining these days, given other limits on emissions and drivability. Diesel grades tend not to have many different components – being cut to spec and then desulphurised so the risk with them is the “teaspoon-effect” – where the component pool has to be made to meet the most difficult specification, regardless of how little of it is made. To avoid giveaway on the easier seasonal grade, the model needs to have distinct source pools, which in turns implies blocked operation on the DHTs etc, and possibly even on the crude tower in order to capture the differentiation that the refinery can achieve by adjusting feed mix and cut point. At this point, you might start wondering why you don’t stick to a single season per period!
Seasons or Multiple Grades? Which is better? As you can see, there are pros and cons for each. You need to think about the number of periods you would need to model and whether product inventory is significant. Is the model small and quick or large and slow? Are your demands easy to predict or very open? Balance out the impact of the seasonality on your operations with the time/complexity impact of the modelling method and choose.
From Kathy's Desk 21st June 2022.
P.S. In case you are wondering, in the large multi-site model I've been working on this last year, I started out arguing for separate products but then switched to seasons, when it became clear that model size and data management were more significant considerations than inventory in this instance. Fortunately working in the g5 database input system made it very easy to update the description of the product codes we kept and delete the obsolete ones with just a few clicks on the Stream panel in each refinery model.
Comments and suggestions gratefully received via the usual e-mail addresses or here.
You may also use this form to ask to be added to the distribution list to be notified via e-mail when new articles are posted.