When did you last take a good look at your initial pool property estimates? A good first approximation should put your optimization on a good path and save you some recursion passes. Recursion Monitor is a useful tool for checking out your starting qualities; you can compare first to last pass values and check them for internal consistency. See Note #31) Recursion Monitor for instructions on how to save and view a pass by pass record of property values.
 

When I’m checking the property values for a model – a good annual house-keeping practice - or when confronted with numerous infeasible initial passes, I usually go to the properties tab, select a pool, and then arrow down through each property in turn.  I’m looking for any first pass value that is noticeably different from its final value. It is important to work from a run that did finish on a good solution, of course   Your first goal is to spot errors and typos - properties that have been mistakenly entered as 0 or with some placeholder value that no one ever remembered to go back and tidy up, or in something in the wrong units e.g. wt% instead of ppm, or as in this case, fraction instead of percent.

     33 PercentNotFrac

You might also identify items where the value, although not ridiculous, is not a good match to the final, and so could be improved. You need to be looking at a good solution to of course, and consider what is typical – whether qualities are likely to be stable over a range of configurations and specification seaons, or whether it is something for which a compromise is required, or even case specific values.


You can also spot bad values by looking at sets of related properties. For example If you have % distilled or Evap at Temp numbers for a pool, are they in sequence?

33 EvapsNotInSequence 

Compare related pools too. For example, in the volume demo model the reformer feed pool should be almost the same as the heavy naptha pool, since it is the principle component.

 33 PoolsNotSame

Having tidied up your initial values, you are, of course, hoping that the model will run better - but with non-linear optimization like SLP, there is no guarantee. Changes might just bump the model into a different solution (See Note #19) SLP and Chaos)  You are looking for better behaviour on balance and that means multiple runs. Multi-starts based on the old and new initial values is a one way to check this. To get a 181 with the initial values in it, run the model for just one pass. (See Note  #7: Effective Use of a 181 File).  And you should also test with a different set of case data than you analysed with, to make sure you aren’t just tuning the model to solve a particular scenario.A crude evaluation loop is also a good test set-up – do your new estimates produce more good solutions than your old ones.  (You might also find my old conference paper on “Are Things Getter Better”…… useful in thinking how to decide if you have improved the model or not)  

 

 
From Kathy's Desk
  26th March 2018.

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 so that you are notified via e-mail when new articles are posted.