Krska Chronicles Part 3: Balance the Mass Balance

Late design change is always problematic, so test them thoroughly. Poor modelling can obscure the consequences. Read the bold highlights if you are not technical.

Unfortunately, a lot of our revenue comes from investigating and fixing poor designs. In this case the impact of a late design change was masked by the manner in which the process simulations were constructed.  The process was in fact inoperable with no clean solution.

Like any offshore platform the aim was to produce a stabilised oil.  Disposal of the condensate was initially recognised as a potential problem.  It was part of the original design to re-inject the condensate into the reservoir. In order to cut costs this idea was revisited during the infamous ‘value engineering’ phase and removed.

On start-up the gas compression KO drums flooded due to the accumulation of condensate recycling around the compressors.  John was asked to review the design and suggest possible ways forward.

Sample analysis confirmed the well stream compositions corresponded to those used in the design.  However, the steady state process simulation model provided was very slow and difficult to converge. This is generally a warning sign.

The model convergence appeared to be due to excessive use of ‘recycle convergence blocks’.  Each recycle was independently configured a dedicated convergence block.

Checking the overall component mass balance also showed the cumulative effect of each recycle blocks convergence criteria produced small but significant discrepancies in the mass balance of some key components.  Rationalising the convergence blocks significantly reduced their numbers and scope for errors.

The revised model was still difficult to converge, requiring manual intervention, it did however now show a substantial increase in the condensate recycles sufficient to overwhelm the compressor KO drum condensate level control valves and drain lines.  After start up it wasn’t practical to increase the valve and drain line sizes to the required values.

Reconfiguring the scrubber drains and purging some light condensate to flare, whilst relaxing the crude TVP and export gas specifications provided a less than ideal solution. In other words an offshore process had been built that simply didn’t work.

The problem arose due to not recognising a potential issue when a model is difficult to converge.  Each use of a convergence block introduces convergence criteria that either compounds the error in mass balance or stops the model from converging.  In this case, the errors were sufficient to mask the problem of removing the condensate injection.

Models that don’t converge easily can usually be put down to one or more of four causes:

  • Convergence blocks are incorrectly or inefficiently placed.
  • The model contains ‘Adjusts’ that iterate some operating conditions to provide a solution to some desired criteria. ‘Adjusts’ are unreliable, especially when nested.
  • The process has significant issues that must be resolved. These may be manifest by slow convergence and relative large changes in the flow rate of some streams when relatively small changes to temperature and pressure specifications are made.
  • The simulation package contains an error.

We expect the process simulator to provide a perfect mass balance (Input = Output), they don’t. There are usually some small insignificant imbalances.  In models that have several recycle convergence blocks and/or high recycle flow rates the imbalances may become significant.

If a steady state model is indicating convergence problems, investigate the cause.

 

Krska’s Chronicles Part 2: Model it All

This is a story about completeness. As the old adage says ‘Short cuts can lead to long delays’.

In this story, mistakes were made in the initial design that created safety issues requiring investigation.  As all too often happens the investigation unearthed still more concerns. The effect of production turndown was found to produce awkward ‘unexpected’ consequences.

The offshore platform was required to produce a stabilised oil which was stored in a gravity-based structure prior to tanker loading.  The original design therefore routed the compression knock out (KO) drum drains in a manner that wouldn’t elevate the stabilised oil TVP (True Vapour Pressure). The design simulations had indicated that the liquid quantity to be discharged from the HP compressor KO drum would be negligible.  The drain was therefore routed to the closed drains under on/off level control.  In practice the drain valve was found to open more regularly than expected.  The temperature drop across the drain valve caused drains to block with ice and produce external ice.  I was then asked to investigate the issue and determined a safe route for this drain that would still provide a stabilised oil.

The company’s initial view was that the well fluids were different from the original design.  Fresh well fluid sampling and analysis determined that this wasn’t the case.

A review of the original design’s heat and mass balances and simulations highlighted a key discrepancy.  The fuel gas take off wasn’t considered in the simulations.  Installing the fuel gas take off in the simulation produced a significant amount of condensate in the HP KO drum, although the amount of gas feeding the KO drum had reduced by the fuel gas take off.

The extra condensate in the HP KO drum was due to the LP KO drum drains recycling to a point downstream of the fuel gas take-off.  The fuel gas was therefore leaner than the gas feeding the compressor.  As the produced gas/fuel gas ratio decreased the compressor gas also became richer as the low MolWt components were preferentially routed to fuel gas.

The current problem of the HP compressor drain icing up was relatively simple to fix, requiring a simple reroute of the HP KO drum drain.

The problem of the fuel gas take-off producing a richer compressor gas was more problematic.  Further simulations of turndown showed that the amount of condensate recycling through compressor and drains would significantly increase as there were insufficient low MolWt components to carry the condensate through to gas export.  This created the awkward situation that the compressors would need to be larger to move less gas.  The condensate drain lines would also need to be a lot bigger to cope with the recycling condensate.

Left as it was, the KO drums would have flooded, and it would have been necessary to flare a significant portion of the gas to purge condensate from the system. The problem was resolved by rerouting some other condensate returns.  This produced a richer fuel gas which required some reconfiguration of the gas turbine controllers.

Missing out the fuel gas take off from the design simulations was a significant design error, especially as effort had clearly been given to routing the condensate to maintain the oil TVP.

The moral? This moral is twofold. We mustn’t assume that lower production rates produce lower internal flow rates.  It is almost inevitable recycles will increase and recycles produce unintended consequences. Is it worth trying to save a few coins by neglecting to model part of the process?

Krska’s Chronicles Part 1: Check and Check Again

Boiler Feed Deaerator Doesn’t Work

What is most concerning in this story is that several investigations spread over a period of five years missed the obvious.  This was a very early experience in my career; the lesson served me well on several occasions and many years later.

I was initially hired in to my first post-graduation job to develop the company’s cold water deaerator designs for oil field water injection.  This was very successful and it made the company the world leader in this small but significant market.

In spite of this achievement I still wasn’t considered a fully-fledged engineer, even though I might have thought I was at the time.  My manager and mentor decided I needed more hands on experience so I was despatched to a refinery to assist a field technician to investigate a long running problem with one of our boiler feed deaerators.

The boiler feed deaerator had never functioned properly; it barely reduced the dissolved oxygen concentration requiring copious amounts of scavenging chemicals be added to prevent corrosion.  Non-condensables (nitrogen) in the steam also impaired the steam utilisation.  The boiler feed pumps also suffered numerous failures.

The deaerator system consisted of a water header tank, simple spray deaerator, steam ejector to reduce the deaerator pressure, an extraction pump and a pressure control valve downstream of the extraction pumps which regulated the supply pressure to the boiler feed pumps.  The extraction pump was a suction head controlled pump that uses low NPSH to regulate its flow rate.  Incidentally these pumps are very robust but they sound like they already broken as they run with continuous cavitation.  They sound even worse when the discharge is over restricted.

With so few components, it seemed odd that this one should be so problematic, whilst there were hundreds of similar units out there that worked just fine.  It had perplexed everyone who had looked at it over the past five years.

My only thought was that the pressure control valve was blocked or too small as it was operating fully open.  The back pressure was so great it caused the deaerator level to back up over the top of the spray bars.  That seemed to be too obvious, after all, several people had looked at this over the past five years.  It was explained to me that this had been considered several times and investigated.  Eventually, they were persuaded to open the globe valve up one more time.  With very limited experience looking at control valve internals, I still thought the globe and disc looked small.  Like those before me I looked at the data sheet which matched installed internals.

I phoned the manufacturer, yes we did have phones back then, and asked that they confirm the valve sizing. They phoned back a few minutes later saying the data sheet valve size matched the installed size.  But they hadn’t answered the question; I asked they check the valve sizing not the data sheet size.  Meanwhile a quick calculation of the flow through an orifice showed the disc orifice to be far too small.  The valve vendor phoned back about half an hour later.  The valve had been sized incorrectly.

We now had the problem of how quickly we could get a replacement plug and disc for our valve.  We conducted a search of the refinery’s spares stock and found the correct size of plug and disc.  These were fitted and the deaerator started to work properly, but (there is always a ‘but’), the extraction pumps now kept tripping on high power.  It turned out that the extraction pump’s motor high current set points had been set too low.

What about the boiler feed pumps, they had failed numerous times?  As the pressure control valve was too small the boiler feed pumps had been running with insufficient NPSH. Unlike the extraction pumps, boiler feed pumps don’t fair well when starved of NPSH.  The short operating life of the boiler feed pumps was fixed by the correct pressure control valve trim.

The refinery’s Engineering Manager was very grateful for the zero-cost fix, even though it had taken 5 years to get there.

Something simple and basic, everyone had failed to do. They didn’t go back to the source data, instead they relied on derived information without checking it.  It seems they missed the obvious because it was too obvious.

Then there’s the ‘but’. Fixing one problem often exposes another. Don’t walk away without checking the whole unit operation.

Krska’ s Chronicles: Introduction

Krska’s Chronicles are intended to share hard won experience from many years as a process engineer. If companies struggle with corporate memory perhaps they will help.

I’ve been a Process Engineer for nearly 40 years.  I’ve worked on every type of equipment used in upstream oil and gas, covering a broad range of technical roles: conceptual and detailed designs, green and brown field projects, trouble shooting, commissioning, debottlenecking, optimising production, energy utilisation, environmental protection, process control, safety systems, operating procedures, advanced steady state and dynamic simulations and other computer software development.  I have worked in senior roles with equipment and service suppliers, design companies, EPCs, large and small operating companies and consultancies.  I’ve worked on over 90 assets across more than 20 countries; I have recruited and built large and small teams and mentored several engineers to become chartered.

So, you might expect that I have learnt a thing or two across the years.  Well yes, I have, and I’m not done learning yet.  I find it both sad and frustrating that there appears to be little or no corporate memory. I keep coming across the same mistakes, poor practices and missed opportunities time and time again.  To be frank, I see even more fundamental mistakes made today than say 10 years ago.

Experience isn’t something we get by doing the same narrow thing over and over again.  Mowing the grass every week for 20 years won’t make a person a master gardener no matter how big the lawn is.  It’s a well-used phrase ‘you don’t know what you don’t know’.  There are millions of would be football managers tuned into the TV every week that could do a better job, or so they say.  There will be a significant number who genuinely believe it, because they have no idea what it takes.

I think that our business is reluctant to acknowledge the issue of  limited experience. Experience can’t be reliably represented in a person’s résumé or list of hyped job titles. It needs to be tested and proven, but who by? Would you be recruiting the experience if you had it? Valuable experience is expensive, perhaps it just easier to just gloss over the issue with a  CV on file.  Isn’t it time we started trying to address this apparent lack of corporate knowledge and pass on some key experiences?

There is a history of terrible avoidable consequences.  We sit up and take notice of these and strive to avoid them happening again.  But it isn’t that simple, many of these tragedies don’t have a single cause and it is the smaller details that line up like holes in Swiss cheese that make these happen. How about the near misses and less tragic ones we don’t hear about?  Many of these are hugely expensive to business, yet they keep being repeated.  If we pay attention to those, we will also avoid many of the larger tragedies and financial disasters.

We now have technology at our disposal that can reach previously unimaginable audiences.  The best tools we had when I was an undergraduate were a slide rule, pen, piles of stuffy books, and don’t forget the triangular graph paper.  It is astounding how we managed with these tools.  If you have a spare weekend, have a go at doing a three-phase multi-component flash calculation using a basic non-programmable pocket calculator.  Seriously, don’t try it; it will be a weekend you may never get back.  It is very impressive what we can now do with computers and how quickly that technology has developed. I think I’ve kept pace with these developments reasonably well.  I’m passionate about what can be achieved with process dynamic simulation as a ‘life of asset’ tool (rather than a project after thought), remote working, new business models and sharing experience.  This is balanced by a recognition of what we have tried before; I’ve seen a few business models come and go, then come around again.  Change for change sake doesn’t imitate progress.

We need to be careful how much trust we put into computer programs, they can be a short cut to making more serious mistakes.  They reduce the requirement for thought and it often seems they have removed it altogether.  It isn’t enough to be able ‘crank the handle’ and build a simulation; having an understanding as to what is expected from it is way more important.  Today there are numerous simulators and computer software tools at our disposal.  Unfortunately, I haven’t seen one that isn’t flawed in some way.  As their complexity grows, so does the scope for them being wrong.  In some cases the errors and omissions have been significant and dangerous.  I firmly believe that having a deeper understanding of the fundamentals and a clear expectation as to what the computer output should be is essential before turning it on.

For example, I think I will cry if I see one more dynamic simulation that has auto tuned level controllers on a separation train.  The separators are supposed to absorb flow disturbances not pass them on.

Similarly, why do we see so many compressors with inoperable suction pressure controllers? Suction pressure is not always the best master controller and often they are inappropriate, there is this thing called degrees of freedom.  Just because it is the default controller and the compressor vendor wants it, doesn’t make it right for the process.

With the chronicles I propose to pass on some of my experiences, by way of case studies, concentrating on the myths, mistakes and missed opportunities I see being repeated.  Hopefully these ‘war stories’ will be valued and their moral made clear. Here’s Part One to get you started.

Experienced practitioners might well think I’m ‘teaching my granny to suck eggs’, but trust me these are genuine and often repeated.  They clearly aren’t so obvious to all, otherwise they wouldn’t be repeated.  They can have serious economic and safety consequences, so let’s pass them on.  I would rather you groan at how obvious these may seem than have them happen again.

Sucking eggs made simple from an 1890s Punch magazine cartoon:

“You see, Grandmama, before you extract the contents of this bird’s egg by suction, you must make an incision at one extremity, and a corresponding orifice at the other.” Grandmama’s response is to the effect, “Dearie me! And we used to just make a hole at each end.”