33) Using Recursion Monitor to Review Initial 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 something in the wrong units e.g. wt% instead of ppm, or as in this case, fraction instead of percent.

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?

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.

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)