JEC Engineering & Consulting

Delivering Expert Wells

Articles

  • 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!

  • Von Mises Derivation and Application

    Von Mises stress envelope is a valuable tool to performing tubular stress analysis. However that pretty ellipse that you put your load calculations in has some math behind it, and understanding how it is derived helps understand why it is used.

    The Von Mises envelope equation provides the interaction between the different stresses that will equal to the yield stress of the tubular. When other stresses are 0, then clearly the remaining stress will be the same as yield. However what happens if you start pulling tension on the pipe? Does that additional stress strengthen or weaken the pipe? It actually strengthens it, and can be valuable in eking out maximum performance in your tubing and casing through design. Trying to draw a single envelope can be difficult with up to 4 variables, however this workflow illustrates how some terms can be eliminated or made in terms of one other, and identify the extremes to plot with.

    Von Mises works well for extending the ability of the pipe under tension and burst conditions, however collapse is a different story; it is an inherently unstable condition that is fine, until it isn’t. While burst will often cause some cracking and leaks as the pressure increases until total failure happens, collapse can happen extremely quickly, causing catastrophic damage before it can be reacted to. The term pancaking isn’t an exaggeration, pipe can be nice and round in one moment and flattened in the next. I remember an incident with sand screens, the field had been producing great until water influx carried particles that plugged the screen, and wells started going down one after another. The API calculations in 5C3 are the standard for determining collapse, and have a well-proven track history.

    I did a separate write up in Word to accompany code on my Github, and have copied it below (email me if you’d like a PDF of it). Head over to https://github.com/jack-charles/PipeEnvelope to check out the code itself. It’s setup out of the box to create and plot multiple VME and API curves with safety factors and derating. It can be modified easily to integrate into your own workflows for quick stress checks, without breaking out the big software packages and needing to re-input all your data.

    Next in the series – how do we calculate the tubing and casing loads, especially with buckling or torsion? And how do we know which envelope the load should be plotted against?

  • Sand Sieve Analysis Python script

    I uploaded to GitHub a Python version of the sand sieve analysis spreadsheet that I used for years. The script will generate a number of plots that help graphically determine sand control options, in a method better than the traditional Excel spreadsheets do.

    https://github.com/jack-charles/SandSieveAnalysis

    It has a straightforward terminal prompt that allows for:

    • Opening a new sieve data file with multiple samples
    • Combining multiple sieve data results (plotting old core data with newer offset wells is easy!)
    • Selection of screens and proppants as options
    • Calculation of the cumulative weight percentages, uniformity coefficients, sorting coefficients, etc.
    • Plots of distributions, parameters against depth and other parameters, and screen/proppant data to determine suitability of sand control
    • Basic input error detection, but don’t stress the program if you can help it!
    • Displays to terminal or outputs to a JSON file

    On my to-do list is to incorporate logging data, such as gamma ray, sonic, and density logs to help establish other views of the formation. I would like to also add in sand retention test data from a flow cell (typically retained perm vs pressure and flow) to help make selections. I will make periodic updates to add in other calculations, including converting this to a Flask or other web framework application, and integrating to an SQL database for complete data collection.

    If you find this useful or have suggestions for improvements, please let me know. These graphs work for me, but may not be the best for users globally.

    This is a first baby step I have in mind for delivering bespoke production and well engineering calculations through an online (internet or intranet) platform. We’re all familiar with enterprise software like Landmark and trust their reliability for well integrity, but I believe there are many other critical calculations that we rely too heavily on Excel for. Even worse is when we must rely on Excel for calculations that are then put into EDM and other software. I will discuss more on my philosophy in later posts, but my own experiences and observations leads me to believe that operator and vendor data is not well managed. GIGO, unaudited calculation tools, and user laziness is a real thing that can make a database with hundreds of entries and gigs of data effectively useless.

    Interested in adding this and more to your company’s workflows? Contact me to see how we can make this happen.

  • 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.

    How damping coefficient defines network complexity – from Dr. Gabry’s presentation
    Water Hammer Signal During Cascade3 Injection Trials

    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?

  • Man does not plan to fail, but fails to plan

    I often find my professional tendencies are reflected in my hobbies. One of these is scuba diving. Ever since those training dives in Balikpapan, one of the core principles that was drilled into me was “plan your dive, dive your plan.” This saying has stuck with me to over 100 dives, and I credit it for helping me through situations on bottom and staying calm.


    Why is planning and holding to plan important? Diving is so fun and relaxing that it’s easy to have time slip by; suddenly you’re over 30m underwater with 25 bar on your pressure gauge, far from the boat and you don’t see your dive buddy in low visibility water. Big trouble and puts your life, and possibly others, at risk!

    The planning is relatively straightforward – know the starting air pressure and expected consumption rate, what are the depths and paths to take, what air pressures to start surfacing safely at, and communicating this before diving with my dive buddy and boat crew. I don’t deviate from the plan no matter how much I think I can get away with it “just this one time” staying down longer or skipping decompression stops. Emergencies can happen but common ones are identified with contingency actions and can be safely resolved by sticking to the plan. And this works great for de-escalating conflicts with other divers, by establishing criteria and agreeing to hold to it.

    There is Mike Tyson’s saying “everyone has a plan until they get punched in the face” that counters what I’ve said, but I find the root cause for plans to fail is not anticipating unknown factors correctly. It’s often less the “why” something happened but “what” the outcome is: it doesn’t matter if a shark bites my regulator hose or it starts leaking at a fitting, my planned actions will be the same towards safety. We should also learn from those incidents and incorporate them back into our planning process.


    I find I bring this same approach to my work. I enjoy being able to map out and piece together the activity streams that need to occur and when, who is responsible, and identifying open switches that need special actions. Engineering work develops the working envelope that that satisfies safety design limits and ensures a robust design, and once operations start I follow prepared actions to get to the end safely and meet the goals, with clear contingencies based on actual results. Having a well-developed plan on hand is a great feeling, and seeing it executed is amazing.

    This isn’t to say that I’m inflexible with my plans; if a last-minute change needs to happen (Let’s go inside this shipwreck! or We need to change rig sequence!) then the change and consequences need to be fully understood. In business we have the flexibility to communicate and resolve before committing and documenting the change. Too often someone has their own priority that conflicts with another’s plan and allowing that priority to proceed without a full accounting can cause significant issues, and verifying the impact of taking up that priority is critical.


    Do you find yourself often in scenarios where the tasks start deviating from plans? Do you hold so rigid to plans that opportunities are missed and not followed up the next time?

  • Sharing Knowledge

    Over the years I’ve picked up quite a bit. One of the great joys of learning is to turn it around and share it. Besides sitting around a frac shack or doghouse and swapping stories, I’ve also published a number of reports, white papers, and industry papers.

    I’m also a big proponent of engineering programming, with some fairly complex VBA-backed Excel programs. Lately I have been converting much of my old code to Python, all 5000-ish lines of it, and exploring how to make the leap from the old spreadsheets to a proper web-based software platform, with assured calculations displayed in a clear and open manner.

    I will publish articles here on well engineering going forward, with a mix of theory, advice from experience, and how to practically apply it in an engineer’s procedures and calculations.

    Hopefully visitors will find it useful, and be part of the 10,000 for the day!