Flare System Modelling for Dummies

FLARE systems are the big pipes that take all your problems away, separate the vapour and the liquid in a drum, and burn them at the end of a big stick with a flame on the end. 

Another (perhaps more pragmatic) view is that flare systems are an integral part of the safety systems on an installation, and need to be designed and modified with care. There should be nothing complicated lurking within a flare system, it is just pressure and flow in pipes, which every chemical engineer has studied from an early age. The complexity lies in the number of inputs and the different combinations of flows that can enter the system.

It is very difficult to cover every aspect of flare system design and modification within one article but hopefully this will provide a good starting point. 

It’s also worth noting that  many of the same principles apply to vent systems throughout the chemical and the pharmaceutical industries, not just oil and gas.

Options, options, options

In order to model flare systems, it's not uncommon for engineers to use a software package. Many of these software packages have options on how the solver will process the information and provide answers. This could be defining ambient temperatures, which vapour-liquid equilibrium methods are to be used, how the model calculates the flow through relief devices, which pressure drop method is suitable to use and so on. The list isn’t endless but it can be long. It is advised that users resist the urge to immediately start inputting pipes and fittings, and to first get the underlying key options understood and set up correctly. The options chosen need to reflect the actual installation, so will be different from asset to asset rather than just copied and pasted from previous models. A good example is ambient temperature: would you choose the same value for sites in Alaska or in Trinidad?

Header or tailpipe?

Another key decision to make at this point is how to define headers and tailpipes. On the face of it this decision doesn’t sound a hard one to make. Headers are the big pipes, and tailpipes are the ones connecting into it. The difficulty arises when two tailpipes meet and then go on to the main header: is this a sub header or just a bigger tailpipe?

Some engineering judgement needs to be made on these ambiguous cases.  Take the example above in Figure 1 where a relief valve and a depressuring line are arranged as shown. It isn’t too much of a leap to say that the green pipes are tailpipes – they only receive flow from a single device. Likewise, it shouldn’t be too controversial that the blue pipe is considered as a header. However, from experience, a discussion around whether the red section is considered a header or a tailpipe can become quite vigorous.

Before deciding, it is important to realise why this distinction between tailpipe and header is even worth spending time on. If the engineer is following API 521 guidance, the flowrate that should be modelled varies between tailpipe and header, even for the same source. This approach can be thought of as a compromise between absolute worst-case scenarios (which may result in an over-designed system) and steady state only scenarios (which may result in an under-designed system).

Pop action and spring operated relief valves can be considered to act as their names suggest – when the time comes, they go from fully closed, to fully open, with little to no middle ground. This results in, at least instantaneously, the full-rated capacity of the device being discharged to the flare system, which must be designed for this flow so that excessive back pressure (among other things) does not compromise the effectiveness of the relief device. Since most of the resistance to flow comes from the generally small diameter tailpipes, this full-rated flow should be modelled in these sections.

For headers, the resistance to flow for a single relief flow is likely to be small. Also, the sizing basis of headers is more influenced by scenarios where multiple feeds to the flare header are active at the same time. What is the likelihood that all of these devices are providing their rated capacity at the same time? Probably fairly low. Therefore, the pragmatic approach taken is to model the required relieving rate in the flare header, which represents the sustainable steady-state case.

For different devices, this advice changes depending on the manner in which inventory is discharged to the flare header. API 521 describes it as shown in Table 1. Clearly though, this table should be a guide, and edge cases always exist – nothing is a substitute for competent engineering judgement.

So, should the red section of pipework in the above example be a tailpipe or a header? The answer is still likely to be – it depends. Each situation should be judged within its context. Are the two relief sources ever going to feed the flare system at the same time? If so, then maybe there is a case to call it a header (or at least a sub-header). If they can only relieve individually, then it could be argued it is a tailpipe, just with two different and separate duties.

Other setup considerations

Without getting too in-depth, the flare network software is solving large matrices of data based on the inputs, in order to generate the results. A major time-consuming step in a rigorous model is to solve the vapour-liquid equilibrium at each point in the network (which will need to be solved at each iteration, to generate consistent results). The more chemical components entered into the model, the bigger the matrix becomes, and the longer it takes to solve. Roughly, the time to solve is proportional to the number of chemical components squared.

In the interest of time, it is often prudent to carry out mapping from the full chemical component list to a carefully chosen cut-down list for the flare model. For example, mapping heavy hydrocarbons that are present in trace amounts, say C10+, to a single representative heavy component, say C12. This will have negligible impact on the results, but a significant impact on the time to solve. Combining non-condensable gases such as N₂, CO₂ and H₂S, which are present in small amounts, into a single component (say N₂) is also a way of cutting down on running time, but solubility effects could impact when this mapping is valid.

Which pipes are included can also change depending on the type of input to the flare system. For relief valves, modelling from the outlet of the valve is generally an acceptable method. However, for rupture discs, the point where the relief pipework meets the protected equipment should be the starting point, with the bursting disc included in the flare model as an appropriate restriction or pressure drop fitting (through use of a vendor-provided K factor, for example). This is because it is the pipework that usually forms the main restriction to flow for a bursting disc, rather than the device itself.

Scenarios

Flare systems are very rarely sized to cope with the maximum flow through all of the inputs simultaneously, because it is very unlikely to happen, and it would make the flare system very expensive. However, the engineer does need to know what can credibly flow into the system and ensure it is suitable for the entire range of possible operations. 

Flare systems tend to have three categories of flows: emergency relief; emergency depressurisation; and operational flows. The key to this stage is to determine the credible cases within each of these categories and then any possible combinations.

The first step is to identify all of the inputs into the flare system. This is best done on the process flow diagram level (PFD), as one of the issues with reviewing flare systems from P&IDs is the number of P&IDs the flare system touches. Once all the inputs are known it is then a case of identifying scenarios which will cause flow into the system. Some typical scenarios to consider are:

• flow from a single source (eg one relief valve lifting);
• fire affecting multiple items of equipment;
• loss of utilities in an area;
• loss of utilities affecting the site;
• flaring during startup, shutdown or maintenance etc.

A recommended method for analysing this problem and recording the results is to create a matrix, with the inputs along the top and the possible scenarios down the left hand side. It is important to remember that the flows through an input can vary in composition, temperature, and flow depending on the scenario occurring. For example, one input (say PSV01) may have several scenarios which are applicable in different circumstances.

Warning

Many flare system simulation packages will produce warnings as they iterate through the model and the scenarios. The amount of warnings can be overwhelming and there will be a temptation to simply ignore them: the computer has an answer, why worry? The reality is that many of the warnings can be ignored as they are artefacts of the solver and nothing to worry about in a practical application. However, there can be warnings that do require attention and rectification. Therefore, the engineer needs to review the warning list, understand what the warning means, and decide whether it needs attention.

Simple checks to avoid meaningless results

To some extent, the warnings that the software spits out for you are the easy ones to deal with (once you understand what the often cryptic wording actually means). It is the solver failures that remain hidden that can really cause problems. These errors could have a big effect on the overall result of the model and so models should be sense-checked to ensure that the results are realistic and, in some cases, even thermodynamically possible.

A 'checklist' of other errors that we have seen includes:

• If a model accounts for kinetic energy effects – for compressible flow, ensure that the velocity along a pipe increases and also gets colder;
• Watch out for places where the calculated overall/total pressure increases – this is like creating energy within the system (although this is allowable if two streams are combining);
• Ensure that calculated mach numbers are not greater than 1;
• Pressure drop and Joule Thompson effect across relief sources – does it look sensible or has the model solved to an unrealistic place?;
• Negative gauge static pressure – is it an error or a real effect – for example, local to the piping where a choke occurs. If real, these could be potential air ingress points; and
• If the model is solved by defining flowrate and (normally) outlet pressure (atmospheric at the flare), then there is a possibility that back pressure on a source in order to pass the specified flow is greater than either the allowable back pressure, or the set pressure. Such situations should be assessed for both validity and potential impact on relief sizing calculations.

Back to the start?

So, you have a working model, you understand the warnings and the results, and it has been hard work and many hours to get to this point. Unfortunately it is not the end. The results from the flare system model may have an impact on the flowrates calculated for the flare source inputs. For example, back pressure on a balanced bellows valve may alter the back pressure correction factor (Kb) which will change the flowrate through the valve.  So before the champagne (or prosecco) is opened celebrating completion of the model, these factors need to be reviewed, the model altered if required, and so on until everything ties together.

Another iteration that may need to be considered is different ambient temperatures if the installation is in a region with hot summers and very cold winters. Different ambient temperatures can affect how the flare model predicts the flow and phase within the pipework, so in winter there will probably be more liquid than in the summer. How does this increase in liquid affect the hold-up time in the knock-out drum and the temperatures and pressures in the pipework?

Conclusion

The individual calculations and components of flare system modelling are relatively simple.  The difficulty is often due to the number of inputs, and this generates complexity, which is when the modelling ceases to be easy. Just like DIY, it is the preparation time that gets underestimated or missed and it makes the job much harder. The complexity of the system also makes understanding the result difficult due to the amount of output from simulators.