Category: Fracturing

  • Frac Design in Python

    Need to design a frac quickly, with performance and pumping schedules for screening and budgeting? Got you covered!

    The proppant number follows unified fracture design theory that for a given fracture volume, there is an ideal fracture width and half-length that maximizes stimulation. This is around Fcd=1.6 for many fracs, especially frac packs. 

    However it’s not always realistic – some fractures would be thousands of feet long but only 0.1” wide – good luck with proppant entry, and embedment or slumping is going to kill the APC – or 10’ long but 5” wide – reality for such a soft rock is there’s of embedment and mixing of disaggregated formation and proppant at the rock face, with maybe a clean 1” frac.

    The next step is then to look at predicted fracture geometry with one of the common 1D models, Penny, PKN, or KGD, and see if that volume of proppant and geometry is sensible. If the Fcd is backmodeled based on the geometry, what is realistically possible in terms of rate and proppant placed? This can be iterated a few times until the fracture geometry starts to agree on itself. It may be that more or less proppant and rate is needed to achieve targets, or we stick with the original volume and acknowledge that Fcd may not be optimal. In the video example the 32bpm is overkill and should be reduced considerably as the Fcd is lower than 1.7, suggesting that length should be longer and with more net pressure gain.

    Finally the schedule is based entirely on volume and efficiency that builds a fracture – geometry is formed, fluid leaks off, proppant is placed successively in an ideal model. I frequently use this as a first estimate in Stimplan, make some standard modifications that I prefer, and I usually end up with a pretty decent first pass at a frac. Obviously multi-layered rocks make this approach not as effective, but for first pass this method has saved me quite a bit of time and energy in frac design, and lets me respond to production teams on estimated costs and performance within an hour of getting barebones data, sometimes during the same meeting!

    Currently this app is unavailable publicly due to tight integration with the rest of the software, but I wanted to share an example of a custom app can be built and deployed to work within your workflow. I hope to have a framework of the package available soon once I have the background data model developed, but in the meantime I’m happy to have a chat on how this and other applications work and can help!

  • Thoughts on Continuous Wavelet Transforms for fracture diagnostics

    I had the pleasure of sitting through Dr. Mohamed Gabry’s presentation on CWT to analyze complex fracture networks using the water hammer response at shut-in, as part of NSI’s Wed(NSI)day technical presentations series. The concept of CWT is new to me, I’m more traditional in Fourier transforms, but I believe I understand the basics by using a wavelet that passes along the time-based water hammer dataset, matching the wavelet to the waveform to determine parameters. These damping parameters that would then generate a unique exponential decline curve which then defines the fracture network complexity.  I am amazed at it was able to deconvolute the incredible complexity of multiple reflections and flowpaths, and seems like a good diagnostic tool which matches fracture density logging results (avoids a logging run in a debris-laden well!). However I missed how it could be used as a design tool currently, which I am equally interested in as an engineer. I would like to correlate the fracture complexity to parameters necessary for proppant transport and production, like fracture width and tortuosity, to understand how to improve subsequent treatments in our forward-looking design models.

    From field experience in testing and measuring water hammer in Permian I learned:

    • Rate, fluid volume, and modulus of elasticity of the flow path are important
    • Speed of sound of the fluid must be calibrated correctly, such as adjusting for changing density, solids fraction, viscosity, and phase/flow regime
    • Shut-in ideally is instantaneous without fluid loss (practical inside a cement wellbore, but in the formation…?)
    • High data rate recording is necessary, I used perforating gauges to gather data points
    • Pressure signals recorded at surface are a superposition of:
      • Waves in pipe, with reflections from the sump and surface
      • Waves reflected by restrictions (perfs, pinched fractures)
      • Waves in the fractures propagating to the tip
    • And heavily influenced by differential elements
      • Tortuosity in the perforation tunnels creating time lag and discontinuity
      • Friction in the fractures and choke points
      • Leakoff (changes in reflected fluid volume) – high perm will have larger volumes lost

    We were able to develop the water hammer and tweak it to match the response downhole, however I was fortunate to only need to measure the transient wave with incompressible fluids inside the pipe, with fixed values. Reflection throughout the wellbore was negligible as we were measuring the immediate hammer and decline at the perfs, with sump and surface far away. Decline was not critical for the experiments, whereas it is important in the CWT fracture network analysis. Even after thinking and writing this, I am still amazed at how it could analyze the superposition of pressure transients.

    For any that are experienced in using fracture network diagnostics for production analysis and planning propped fractures, what value does this kind of analysis give you? Can simply knowing a fracture network complexity give you enough additional data, along with recorded field and pumped treatment data, to give accurate predictions? If you are experienced in CWT as an analysis tool, does the parametric curve fit help you to ultimately match physical parameters for the water hammer model?