Sneak peek into the world of SIG ML
SIG ML recently welcomed Jackson Searle into their team at a time when some really exciting engineering A.I. projects started turning into managed products. Jackson is a petroleum engineer (turned analytics engineer) with experience working in production and reservoir engineering disciplines. Prior to working as an engineer, Jackson worked in the construction industry for a little over ten years as a rigger.
With three industrial AI projects in full flight, Jackson has been thrown into the deep end (sorry Jackson, you're doing great!). We asked him some questions about his first month of working at SIG ML.
Why choose a company like SIG ML to work at?
Since I joined the energy industry as a petroleum engineer, I have always been fascinated with data and how it can tell a story about an engineering problem or solution. Whether that story be good or bad, it provides us with an opportunity to enact change to do exactly what engineers are supposed to do i.e. optimise and improve the systems we are working with. I loved the problem solving aspects of being a petroleum engineer and also having responsibility for managing large groups of assets, but I also realised that a lot of the tasks we do as engineers, should be automated. I don’t see this from the perspective of a machine taking my job, but rather I think of the significant amount of possibilities I could be exploring, if only I wasn’t caught up in the day to day struggles of never getting on top of all of my work priorities. This problem that I noticed in industry, was a one that SIG ML was trying to solve i.e. applied AI solutions to mirror the decisions of an engineer. When I got to know SIG ML’s managing director Sam, I was taken aback by his “beginner's mindset” to problem solving. That mindset in engineers is something that drives innovation and change.
What sort of projects are you working on?
I am currently working on the deployment of software solutions in the Industrial A.I. stream at SIG ML, focussed on production engineering-led products. In particular, learning and contributing to the SmartPCP software. The SmartPCP has been built to support production engineers with Progressive Cavity Pump (PCP) optimisation. The SmartPCP is designed to ‘codify’ (I have heard this word quite a few times already!) a combination of physics- and engineering-based rules into a machine learning system that learns from past operating behaviors, to provide engineers with actionable insights. The SmartPCP is also capable of running as a supervisory control system, to reduce repetitive tasks for engineers and operators and maximising production and well uptime.
In addition to diving into the detail of the SmartPCP, I’ll soon be supporting the SmartLever product, an automated turndown scheduling and supervisory control system for CSG well fleet assets, and the SmartWorkovers tool, for intelligent well intervention design.
I’ve also been introduced to the Exploration A.I. stream, where machine learning algorithms have been built using geoscience concepts and targets generated are being actively pursued by a mineral exploration company in South Australia.
How do you see your experience with a prior hands-on occupation in the construction industry, as an attribute when working with data?
Working with my hands in a previous life taught me that solving a problem is sometimes achieved by brute force or trial and error, but that shouldn’t be the preference. When it was the first time me or the construction team I was working with were encountered with a problem that requires significant physical exertion to solve, you tend to sit back and think creatively before you charge like a bull at a gate. While working with data does not involve me breaking my back, the same philosophy to problem solving in this domain applies. Sit back and think about the problem before you jump right in. In the instance of data, it will save you time and anguish. Though, brute force also works when that doesn’t.
What new digital tools are you using compared to before?
The two main tools I have been only recently using, have been Python and Tableau. I have always been big on Excel as a tool, as I found comfort in easily loading up and handling data in a timely fashion, until you exceed 1 million rows of course (1,048,576 for those that like detail). I would occasionally hear some folk bash Excel as a tool of choice but to most professionals, I think it is a practical and efficient way to gather insights and let your data do the talking. Whether a tool be physical or digital, the question that applies to both cases is if this is the right tool for the job? This aside, my new boss has advised me that Microsoft Office is "not the current tool for the job". Note the difference? I am not entirely sure this is company policy, but I have no other choice but to embrace Python now. This is truly a blessing in disguise for those who want to “force-learn” a skill at a much faster rate and also, it removes the temptation to open those beautiful sheets of cells and formulas. "It's for your own good!" I hear someone say in the background.
What was transitioning to SIG ML like?
Engineering can feel like organised chaos. Projects and processes can feel like they are moving with an inertia that makes it hard to accelerate in any direction. Contrary to that, I feel like I have moved into the game of pivoting quickly, testing ideas and running on high octane fuel (and caffeine). I also now have a large appreciation now for the amount of work that goes into creating and sustaining good quality data pipelines and models. We also tend to think that pipelines and models are like a whitegood purchase i.e. it will function until something better comes along in the future, or it breaks! This couldn’t be further from the truth. On an entirely separate note but still relevant, we should love the data engineers we work with a little more each day - especially when our data storage and processing systems continue to grow at an exponential rate.
SIG ML uses applied AI to deliver value-centric insights and automation systems. Do you think it is possible to codify manual engineering tasks that a human would normally execute?
I think there is a really exciting point in that question because anything could be possible provided we engineer it in the right way. This process of codifying our knowledge should empower engineers to put their energy into more complicated tasks that involve creativity, reasoning and ingenuity. As an example, as one human it is virtually impossible to handle 250 assets that each behave in their own unique way. People also come and go in an organisation, meaning that knowledge retention is a big problem. We also take time to be brought up to speed with operations, take time to develop job efficiency, and we can also fall sick or have life get in the way of being productive. Algorithms don’t suffer from these aforementioned points.
What has learning programming as a petroleum engineer been like?
It honestly has been a frustrating process. Unnatural at first, but with time, practice and reward, the concepts and techniques become clearer. The reward part is important and keeps you coming back. For me that reward has come when I can use the output of a language, in the form of a visualisation, to explain my business problem clearly. It is also nice to know a piece of information that no one has ever encountered before. I have not stepped out beyond the realm of Python and VBA languages thus far, but there is always time.
In three words, what do you have to say about month 2 at SIG ML?
Bring it on!
To keep up to date with Jackson, you can find him on LinkedIn here: https://www.linkedin.com/in/jackson-searle-b2130a46/