How Did Odin Ai Begin?

The question I am most often asked is how I moved from frac expert to founding an artificial intelligence company. Like most things it was a natural progression. For 10 years I had built a consultancy around ground breaking discoveries that each came from deep data dives. Some of the fruits from these data dives were:

1. Hybrid Gas Assist Frac (2009)

   1. A frac technique that solved for impaired permeability caused by relative saturation changes induced by fracking

2. Slow Back Technique for enhanced EUR (2009)

   1. This technique is now commonly used, but in 2009, during the age of pulling hard to get high IP, this was sacrilege

3. Two Step Pad (2012)

   1. CBM frac technique that allowed for placement of larger proppant sizes and higher tonnes without screen out; In one case we increased from 10 tonnes of 30/50 to 80 tonnes of 16/30

4. CBM Basin Drainage (2012 to 2014)

   1. Production strategy for de-watering CBM

5. Hydraulics for the Delta P (2012 to 2016)

   1. The first downhole frac tool I developed for Canadian Fracturing that ran on jointed tubing. In one case study we increased a customers frac rate by 6x.

These projects all had one thing in common, 4 to 8 month analysis periods and hundreds of hours spent data processing in excel in specialized sheets I had made.

The problem was, even though I was getting industry changing results every time I did one of these studies, by 2016 I was getting burned out by the intense process work.

I needed a software solution.

Thus like most masochists, in 2017 I started a software company. The initial purpose was to solve two problems:

1. Streamline and systematize data handling and feature engineering (though I didn't call it that back then)

   1. I had this crazy excel sheet where I was capturing rates during the pad, slopes of break downs and pressure rises and dozens of other features. I would run this analysis, stage by stage, meticulously categorizing features that I would then statistically investigate for discoveries about wellbore and formation behavior. For example, it revealed that when you pump the pad during a CBM frac, if you keep rate at a minimum until a characteristic pressure change is observed and then you go to max rate; by doing so you bypass certain resistances in the rock matrix which then allows you to pump a much bigger frac without risk of screen out.

2. Make the wellbore hydraulics for the Delta P easy so that I could scale the overseas frac tool business

Here is a screen shot of that excel sheet. It triggers my PTSD every time I look at it.

The Delta P is a complex tool to run, in 2015 one of the major service companies tried to copy my design and train wrecked 4 wells for a previous customer. It requires understanding of pressures from the formation, the pumps, the rheology and nozzle effects.

From that spread sheet I also discovered a jet perforating technique that greatly reduced friction pressure in the formation and allowed a client to move from 20,000 PSI equipment to 15,000 PSI wellhead and iron.

In 2017 I initially hired a software development company to build this software for me. But after 20,000$ of billing, they hadn't written a single line of code, so I fired them and took over the project management.

I was researching like mad. Node JS, Python, PHP, databases, server architecture, the list goes on and on. In the beginning I had no idea what any of it meant, except that I did know first principles of data management from my computer science courses in engineering.

Note: Those courses became extremely valuable when communicating software structure to developers that I would go on to hire. So for young engineers reading this, pay attention in class! Or, if for you, class is not to your liking, then learn the text book backwards and forwards ;)

After this learning period and with the help of a few key hires, I had zeroed in on the tech stack for Odin Ai. The biggest learning was to use NoSQL for our database. It cut development time and maintenance by 90% vs SQL.

By mid 2018 we had the first modules built and I was able to streamline my old work flow, but that is when I learned about neural nets and artificial intelligence. I couldn't look away and had to wonder if they could be used to predict complex wellbore and reservoir behavior?

I began trying to find a data scientist, the turn over rate was extreme. It soon dawned on me that that hiring the right data scientist is even harder than finding the right programmer.

You have to understand that back then, even now, most data scientists were pointed at making cat and dog models, very few data scientists knew time series analysis and what I was doing had never been done before, at least in the public domain. The tools existed: TensorFlow, Pytorch, Numpy, but how to use them to train a model to predict something from time series data just didn't really exist in a comprehensive way like it did for image classification or natural language processing.

But this struggle taught me something I had not expected, that it is extremely difficult to bring a data scientist up the domain expert learning curve, and much easier to bring the domain expert up the data science learning curve. That informed how I would build the software going forward, I would build it to systematize the data science work load and allow for the domain expert to develop their own neural nets.

After several months I knew enough to be dangerous and had built a neural net that could tell me what was happening at each stage during the frac: master valve opens, tool is set, pad is pumping, proppant stages, flush. It was impressive, zero lines of code, just a raw intelligence picking this information out of a time series data stream.

But that wasn't enough to move the needle. I needed to set my sights on something bigger. That is when I looked at screen outs. Luckily I had access to enough data to attempt a first model. I made progress, but I needed more help. I started hiring and firing data scientists again, but this time I knew better the questions to ask them and directions to give them.

By early 2019 I had a rudimentary neural net that could predict a screen out.

Later that year I found my first test case where I could trial this technology. I demonstrated what I had done and they were willing to try it. They were fracking an area of the Montney that was notoriously difficult and fraught with screen outs.

Using my previous learnings and methods, I built a model for them using their data, they didn't have very much, only a handful of wells with sufficient quality of data, and it worked. We saved them 400k USD on a 2.5M USD well.

It was a great technological win, but that still wasn't big enough. Covid shut the industry down shortly thereafter and it gave me a chance to look deeper at what was possible. The next two years were deeply impactful and if I am right, the learnings will fundamentally change how we frac. But that is for a future post.