One of the most common practices during the operation of pipelines is “pigging”. Buildup of solids or liquids in flowlines can result in plugging, cracks, or flaws in the line, all of which could cause severe damage to the line. Pigging operations may be designed with objectives that include cleaning, inspecting of flowlines, or other maintenance operations. Thus, understanding pigging is a necessary for flow assurance engineers to ensure the flow assets continue to run smoothly.
Correctly anticipating the total liquid volumes displaced during pigging operations is very important for operators, as this affects the designing and operations of receiving process equipment, such as separators and slug catchers located at the outlet of pipelines. This discussion will cover how one can run a batch of simulations and analyze the transient liquid response in terms of the pigging displacement volumes and peak liquid flowrates. This analysis can be performed with improved efficiently using evoleap’s flotools software, as compared to traditional methods. We will compare the flotools methodology with more conventional methods using the OLGA GUI and Excel.
flotools gives the ability to build a study consisting of many cases and then immediately process the results. In this discussion we will analyze the pigging displacement volume and peak flowrates in a pipeline system by varying the following parameters:
- Inlet Liquid Flowrate
- Gas Lift Rate
- Inlet temperature
One of flotools most powerful features, its Parametric Studies tool, makes this process very simple and streamlined.
For a study that contains many cases, manually creating the varying cases using the OLGA GUI can be repetitive and sometimes impractical, especially if it is a particularly large case matrix, as the probability of making errors is high. If the OLGA GUI parametric tool was to be used, for every parameter to be varied, a comma separated list of each value for each individual case would need to be provided. Typically, an Excel spreadsheet would be used to organize and visualize how each induvial case’s parameters would look. The parametric studies tool in flotools simplifies this process. After creating a base case with a specific parameter set at a specific value, flotools allows you to create different cases with that specific parameter varied with different values by providing a comma-separated list of those values. For instance, if the base created for a study has the watercut for the inlet liquid rates set at 0.2 and the study requires the watercut to vary between 0.2 and 0.8 with increments of 0.2, a comma-separated list like “(0.2, 0.4, 0.6, 0.8)”, could be provided and then flotools will generate the differing cases consisting of those values.
After defining the study variables, the next important step in generating the cases for the parametric study is defining the naming convention for the numerous cases. flotools provides an easy way to do this by providing an integer index value for every study variable specified while generating the parametric study. An example of the file naming pattern using study variable references is provided in the following figure.
As can be seen in the image above, each study variable has an index associated with it, for example watercut (WC) is linked to %3, the third study variable. Using these indexes to name the cases results with a systematic naming convention for the cases makes each one identifiable. flotools also give you the option to add unlinked variables that can be referenced by other variables. These are potentially useful as they could provide a more descriptive way of naming the cases.
The total number of cases to be generated is indicated as a badge on the generate cases button. Once selected, flotools will create the indicated number of cases in a location specified in your file system. The cases are then available to be ran.
Post processing the results of the study using the OLGA GUI was time consuming due to limitations with the GUI. When using the OLGA GUI to extract the results, the number of cases that can be loaded into the GUI simultaneously is limited. We found that only 47 of the completed cases could be loaded into the OLGA GUI simultaneously. Also, when extracting trend and profile data, only data at one specific simulation time could be considered; what if we wanted to obtain the maximum value during the simulation instead of the value at the last time step? Overall to get the full data set for this project, 4 separate extractions were required.
However, using flotools made this process much more streamlined. The cases just needed to be loaded into a flotools workspace and then the results are available for plotting.
After obtained the data, the next step with the traditional method is to use Excel to create plots of the pig displacement volumes. For each case, the pig exit time was extracted from the pig position in branch (ZPIG) outputs. Then using Liquid Standard Flowrate (QLST) plots, the displacement volumes were obtained for each case by integrating the QLST between the pig launch and exit time. Then the rest of the data must be formatted appropriately to generate the pivot table.
With flotools, the liquid volume rate can be plotted against the desired parameters using the parametric plots tool. The pig displacement volume, maximum liquid rate and maximum gas rate can all be calculated with flotools using its calculations tool.
A comparison of the two post processing methods can be summarized in the following figure:
Creating all the cases to run for a study is very fast and streamlined with flotools. Even for a case matrix with over 50 cases, the entire process was done in a few minutes (or less for expert users).
However, using the OLGA GUI and Excel took about approximately 10 times as long to create the desired plots due to the limitations of the OLGA GUI. These limitations include how many cases that could be loaded into the GUI simultaneously, and how much info could be exported at one time. Exporting the data in segments was the rate limiting part of this workflow method.
An example of a desired plot for this project can be seen below:
To summarize, a time breakdown of each method is given below:
- Open cases in GUI and export QLST and ZPIG to .csv (11 minutes)
- Find time pig exits from ZPIG data (2 minutes)
- Integrate QLST between pig launch and exit times (7 minutes)
- Generate pivot tables (3 minutes)
- Format plots (create titles, axis labels, etc.) (10 minutes)
- Total (34 minutes)
- Open flotools and load cases (5 minutes)
- Open parametric study tool and select variables and filters/slices. (2 minutes)
- Format plots (2 minutes)
- Duplicate plots and change filters (2 minutes)
- Total (11 minutes)
The difference in the processing times can be especially crucial if the case matrix needs to be modified and thus the simulations re-run. Using the parametric study tool in flotools, the existing parametric study can be copied over and then modified instead of making a new one from scratch therefore reducing the amount of time that would have potential been spent on project. Likewise, parametric plots generated to analyze the results of a parametric study, can also be duplicated then slightly varied to cover a variety of different comparisons.
Using flotools for a common flow assurance task like studying pig displacement volumes can result in a much more streamlined process compared to using traditional methods like the OLGA GUI. The efficiency boost with flotools is due to several factors; namely flotools ability to process all case files in a single instance, calculations leveraged within flotools, and the ease of data handling and visualization in flotools. To expand on these arguments, it should be noted that flotools can handle all the cases in the potential case matrix, even cases that have large data files, whereas the OLGA GUI has a limit for the number of cases it can handle at once. Using flotools also would eliminate the need for further post-processing tools like Excel and ensures repeatability of results when using calculations within flotools. Finally, the workflows in flotools have been designed specifically for flow assurance engineering applications, thus deriving meaningful results can be quickly achieved based on a complete understanding of both input and output data inherent to the design of flotools.