HydraSense

Targets

With the goal in mind of building a solution that offered its primary user as much speed as possible, we also wanted to consider the intersection of man and machine. We asked: "as opposed to what tasks either are capable of, which tasks do we want man to avoid, and which tasks are too important for a machine? More importantly, how can they overlap?" The answer that we came to was that where one's weaknesses end, the other's strengths begin.

What it does

Realizing that meticulous monitoring was a job much better suited for machines, we developed a predictive model trained on natural gas well data to determine when blockages would occur before they happened—keeping human eyes from staring at a graph of raw incoming data. By concurrently observing multiple wells, our model periodically produces a report to a monitoring human summarizing the states of each well being tracked. Thus, the "lease operator" as described by the prompt would only need to direct their attention towards at-risk wells, making it simple, quick, and easy for them to get ahead of potential blockages.

How we built it

Our model itself is built using scikit-learn, due to its easy-to-use, abstracted design. As a result, we were able to create a scalable solution which accurately predicted blockages before they occurred. In order to simulate a lease operator's monitoring environment, we employed Streamlit for front-end development. Its efficiency in data visualization paired with its capability to read csv data enabled us to demonstrate real-time data analytics, showcasing the predictive power of our model. Finally, to create comprehensive status reports of all at-risk wells, we employed the SambaNova Cloud API, employing its heightened speed for Natural Language Processing to produce efficient explanations to its user.

Challenges we ran into

A big struggle was realizing that the free tier of SambaNova had many limitations, which kept us from training our model using Llamas through SambaNova. Furthermore, while Streamlit simplified real-time data visualization for front-end development, organizing the dashboard to display concurrent graphs of different wells while offering customization was very difficult to balance. Attempting to incorporate additional, more detailed graphs created more problems with each change, ultimately leading us to redirect our focus to the overall layout of the dashboard.

Accomplishments that we're proud of

Our model was able to produce accurate confidence scores when predicting hydrate blockages, typically able to predict blockages within two records. While that might not seem like much, based on the time intervals of the given datasets, those two records could amount to anything from 4 to 32 minutes ahead of the blockage itself. Thus, our model succeeded in being able to let a lease operator quickly, easily, and clearly see when blockages would form. Secondly, we were very proud of creating a display with real-time concurrent graphs updating; this version of the dashboard reflects a realistic monitoring system, where multiple wells could be tracked at the same time, especially with the AI alert aid.

What we learned

We learned that integrating two different AI models, even if they didn't necessarily directly interact, created huge merge conflicts. This was due to the fact that both models referenced the same dataset, which had to be formatted to suit each one's purposes.

What's next for HydraSense

An important next step for HydraSense would be to provide overall reports on the dashboard, which would describe the stability of all wells being tracked-- as opposed to the single alert system that is currently employed.