In this episode of the Pipeliners Podcast, Tom Quinn and Greg Merkel from Marquette Energy Analytics join to discuss their approach to building a forecast model for gas demand.

They discuss the origins of their business, which evolved from a university research lab to a standalone company and explore the complexities of building accurate forecast models. Tom and Greg also explain the factors that influence gas demand, such as weather patterns and calendar events, and share insights on managing unusual situations like the COVID-19 pandemic in their forecasting models.

Building a Forecast Model for Gas Demand Show Notes, Links, and Insider Terms

• Tom Quinn is President and CEO of Marquette Energy Analytics (MEA), which provides the MCast® family of data analysis and energy demand forecasting tools. He is also Adjunct Associate Professor of Electrical and Computer Engineering at Marquette University in Milwaukee, WI. Connect with Tom on LinkedIn.
• Greg Merkel is the Lead Data Scientist at Marquette Energy Analytics, LLC. Connect with Greg on LinkedIn.
  • Marquette Energy Analytics, LLC. helps utilities leverage their data into decision support tools for efficient energy procurement and readiness for peak load periods. MEA provides natural gas and electric power load forecasts through its MCast GasDay, MCast GasHour, MCast Planner, and MCast Power SaaS services. MEA’s GasDay Load Growth and Design Day Study service provides custom peak load studies backed up by published research and widespread industry practice.
• Stakeholder Engagement: Involves actively involving relevant stakeholders (individuals or groups affected by or involved in a project) in planning, decision-making, and implementation processes, particularly significant in areas like pipeline safety and integrity.
• API (American Petroleum Institute): Since its formation in 1919 as a standards-setting organization, API has developed more than 800 standards to enhance industry operations. Today, it is the global leader in convening subject matter experts to establish, maintain, and distribute consensus standards for the oil and natural gas industry.
  • API RP 1185 aims to use the Pipeline SMS framework to build on stakeholder engagement to support more community involvement and dialogue.
• PHMSA (Pipeline and Hazardous Materials Safety Administration) ensures the safe transportation of energy and hazardous materials.
• Integrity Management is a comprehensive approach to ensuring the safe and reliable operation of pipelines, involving risk assessment, inspection, maintenance, and regulatory compliance.
• Natural Compliance: A strategy in pipeline operations aimed at achieving regulatory compliance as an inherent part of business processes and operations, rather than as a separate or additional effort.
• Pipeline SMS (Pipeline Safety Management Systems) or PSMS is an industry-wide focus to improve pipeline safety, driving toward zero incidents.
• API 1173 established the framework for operators to implement Pipeline Safety Management Systems. The PSMS standard includes 10 core elements. The API Energy Excellence Program followed this model to establish its 13 core elements.
  • The PDCA (Plan-Do-Check-Act Cycle) is embedded in Pipeline SMS (API RP 1173) as a continuous quality improvement model consisting of a logical sequence of four repetitive steps for continuous improvement and learning.
• The CRM Rule (Control Room Management Rule as defined by 49 CFR Parts 192 and 195) introduced by PHMSA provides regulations and guidelines for control room managers to safely operate a pipeline. PHMSA’s pipeline safety regulations prescribe safety requirements for controllers, control rooms, and SCADA systems used to remotely monitor and control pipeline operations.
  • Control Room Management is regulated by PHMSA under 49 CFR Parts 192 and 195 for the transport of gas and hazardous liquid pipelines, respectively. PHMSA’s pipeline safety regulations prescribe safety requirements for controllers, control rooms, and SCADA systems used to remotely monitor and control pipeline operations.
• Pipeline Right-of-Way is a strip of land encompassing buried pipelines and other natural gas equipment allowing them to be permanently located on public and/or private land to provide natural gas service.
• Fatigue Management: The policies and practices in place to address and reduce operator fatigue, particularly in 24/7 environments like pipeline control rooms, to ensure safety and performance..
• Key Performance Indicators (KPIs): Metrics used to evaluate the effectiveness and efficiency of operations within pipeline management, such as response times, safety incidents, and adherence to regulatory standards.
• Leak Detection System (LDS): Technology used to monitor pipelines for any signs of leaks, helping to identify and address issues promptly to prevent environmental and safety hazards.
• Integrity Assessment: Inspections and evaluations conducted to assess the physical condition of a pipeline, including factors like corrosion, dents, and any mechanical damage, often done with specialized tools and technologies.
• Pigging: The use of devices called “pigs” that travel through pipelines to clean or inspect them. Pigs can detect cracks, corrosion, and other anomalies that might compromise the pipeline’s integrity.
• SCADA (Supervisory Control and Data Acquisition) is a system of software and technology that allows pipeliners to control processes locally or at remote locations. SCADA breaks down into two key functions: supervisory control and data acquisition. Included is managing the field, communication, and control room technology components that send and receive valuable data, allowing users to respond to the data.

Building a Forecast Model for Gas Demand Full Episode Transcript

Russel Treat: Welcome to the “Pipeliners Podcast, Episode 361,” sponsored by EnerSys Corporation, providers of POEMS, the Pipeline Operations Excellence Management System, operations and compliance software for the pipeline control operator to address safety program management, control room management, and field operations. Find out more about POEMS at enersyscorp.com.

[background music]

Announcer: The Pipeliners Podcast, where professionals, Bubba geeks, and industry insiders share their knowledge and experience about technology, projects, and pipeline operations. Now, your host, Russel Treat.

Russel: Thanks for listening to this podcast. I appreciate you taking the time. To show the appreciation, we give away a customized YETI tumbler to one listener every episode. This week, our winner is Michael McNeil with Endura Products. Congratulations, Michael. Your YETI is on its way. To learn how you can win this prize, stick around till the end of the episode.

This week, we speak to Tom Quinn and Greg Merkel about building a forecast model for gas demand. Hey Tom, Greg, welcome to the Pipeliners Podcast.

Greg Merkel: Hi, Russel

Tom Quinn: Hello, Russel. It’s a treat to be here.

Russel: [laughs] I wish I could tell you that was the first time someone said that, Tom, but I can’t. Look, before we dive in, let me ask each of you to introduce yourselves. If you would, tell us a little bit about who you are, what you do, and background on how you got into your current position. Maybe if you don’t mind, Tom, would you go first?

Tom: Sure. My name is Tom Quinn. I’m currently the CEO of Marquette Energy Analytics. My background is as a software engineer. I studied computer science a long time ago. For the first half of my career, worked as a software engineer. Eventually transitioned into other roles, leadership, sales, things like that.

Then I went into working at Marquette University in Milwaukee, Wisconsin, where I met Dr. Ron Brown and became part of his GasDay laboratory. That lab was working on research initially funded by the old Gas Research Institute and a consortium of natural gas local distribution companies.

One thing led to another. That research was very successful. Ron and his graduate students developed and, through the university, began licensing some very successful forecasting models. I helped run that as a business even while it was still within the university.

Russel: I want to actually talk to you about that a little bit because I find that commercialization and level of effort necessary to do that interesting. Greg, do you mind? Same thing, give us a little bit about your background.

Greg: Sure. I’m Greg Merkel. I’m the lead data scientist at Marquette Energy Analytics. I started working with the company back when it was a lab part of Marquette University. I like to say I got dragged in as an excuse to not go home for the summer while I was an undergrad.

I’ve been forecasting energy demand, electric, natural gas as a data scientist for 11 years since then. Both, as part of the university, I did my master’s thesis on using neural networks for forecasting energy demand and other machine learning techniques. When we spun the company out of the university, I came along with it.

Russel: Awesome. Tell me a little bit about the history of Marquette because your trajectory as a business is unusual because you started out in a laboratory in a university and then moved into being a business outside of the university. Can you talk a little bit about that journey?

Let me build a little context around the question. I’ve done some stuff on commercialization on the podcast, and I’ve talked about what that process is. A lot of people confuse development and commercialization, and they don’t really get the distinction.

I know that, given where you guys are in the life of your company, you’re very clear about that distinction. Maybe you could talk about that a little bit.

Tom: It’s a distinction that we learn more about every day. The success of the early forecasting models surprised everyone. The original consortium of natural gas utilities were very excited to license them. This was back in 1999, the first time there was actual technology to license.

There was an outside consulting firm that was engaged for a while to do a little bit of marketing, but, basically, the university was writing licenses to these utility companies to use this software.

All of the funds that that generated went into fund graduate students, to pay undergraduate students their hourly salaries during summer breaks and during the few hours they could squeeze in between classes during the semester. We turned it into quite the operation because, typically, an employee would be with us between three and five years.

If they joined us as a sophomore, we’d have them for two to three years, and then if they stayed for a graduate student work, we’d have them for a few more. We very quickly developed an education component.

We used to run something called GasDay camp at the beginning of every summer, where we would take all of the rising sophomores who, like Greg, were hoping to avoid going home for the summer because they had just signed leases on their apartments in downtown Milwaukee, and put them through a boot camp.

Then, by the fall, prior to heating season, they were ready to help us clean data, and deliver models, and support this technology that was being licensed. I joined the project in about 2004. By then, my previous job had been vice president of sales in another technology company.

I was immediately drawn to the potential to grow the footprint of this enterprise and started visiting natural gas utilities and a couple of electric utilities around the country. It continued to grow, and we were able to support more students. We could bring more faculty on. We could do more innovations that ended up making it into the product.

Marquette University finally was developing its technology transfer capability. By 2018, we all recognized that this had grown to the point where it was time to stand on its own as a business.

Ron Brown and I took a proposal to the tech transfer office. We modified it a little bit, but basically, they allowed us to take all of the customer relationships, and contracts, and software, and data, and models, and set up a company just a few blocks from the University in downtown Milwaukee.

Ever since then, we’ve been continuing to grow the business, grow our capabilities, and we’ve made it over the five-year hump. They say, if you start a small business and it lasts five years, you’re probably doing fine and you’re on a great trajectory.

Russel: [laughs] Having been running small businesses for 30 years, I think you restart that trajectory every five years. Sorry for the bad news.

[laughter]

Russel: It’s a fascinating story because it’s very unusual. Certainly, there’s lots and lots of R&D that goes on at universities, but it’s very unusual to actually build a business capability inside of a university because the skills necessary to run businesses, at least in my experience, don’t generally exist inside of universities.

What y’all done is very interesting, not just in terms of the tech, but in terms of the business, the process you went to get there. I’m going to shift a little bit and ask you about, what is a forecast model for gas supply? What does that consist of? What is that all about?

Tom: We have a talk where we introduce these concepts often to people who are learning about this for the very first time. If you think about the word model and what it means, a model is simply a representation of something in the real world and you’re using some tools to create that representation. Sometimes you might build a model out of matchsticks or plastic or something.

In our case, we model the use of energy using mathematics, and you can start by some pretty simple, straightforward equations. When we talk about modeling and  introducing the fundamentals, we use a scatter plot.

Imagine a plot that has a dot for every single day of energy usage going back some number of years. Along our X-axis, that represents how cold it is if we’re talking about natural gas. That might be heating-degree days. Along your Y-axis is what your natural gas sendout is.

As you move further out along that X-axis to colder days, you would expect and often observe that your load or your sendout for that day increases along the Y-axis. You basically get something that, at first glance, resembles a line, at least if we’re talking about days where there’s actual heating degree days.

Russel: Interesting. This is one of those things that, on the surface of it, seems pretty straightforward, but one of the questions I would ask is why…Let me reframe this differently.

I know that a lot of natural gas utilities do their forecasting using spreadsheets, and smart guys have been around for a while. What is the difference or the value between doing all of that as a math model versus spreadsheets and people with experience?

Tom: All credit to the folks who do this in-house using their own intuition, expertise, and mathematical skills. That’s essentially how Ron conducted his initial research.

He was lucky enough to be granted access to the control room of our local natural gas distribution company. He would sit with the folks that had been running the system for 20 years and learn the ins and outs of why the system might perform one way on one day with a given temperature, and then differently on a different day with the same temperature.

Ron’s skills are grounded in controls systems. He has a very strong ability to translate intuition and anecdotes into equations.

Russel: [laughs]

Tom: A lot of what we do — and we present our techniques to the folks running the spreadsheets quite often — a lot of what we do, at its most fundamental, is very familiar. If you’re using a spreadsheet, you’re doing mathematical modeling.

You may be using tools that you might not be that familiar with, like the linear fit tool that’s built into Excel, but that’s doing an error minimization of all your data points and trying to fit a line through all your data. Those folks are doing a version of what we do.

Now, we’ve figured out a few of the important nuances of the drivers behind energy demand that sometimes aren’t quite as apparent or might vary significantly from one part of the country to another.

For example, a day of the week effect. There’s a number of different ways to model day-of-the-week effect and how that might influence energy demand. You could use simple integers to represent each day of the week, and that’s not a bad way to do it.

We happen to use Fourier series and second and fourth-order harmonics — Greg, correct me if I’m misstating that — but we use some pretty advanced engineering math to more accurately represent effects like that. That’s one example of the tricks that we have up our sleeve.

The other thing I’ll say is, often, the very smart person putting together those spreadsheets wants to either get promoted or wants to retire, depending on where they are in their career, and those can often be very difficult things for a new person to take over.

We find that we’re often a bridge from one generation of people interested in the data science side of running a utility from one generation to the next. As people progress in their career, our models are still there. We support them. We come in, and we do training. Our models are not black boxes. We like our customers to understand the mathematics of what we’re doing for them.

Russel: Interesting. In addition to the heating degree days and day of the week, what are some of the other things that you’re factoring into the model?

Greg: I would say the next most important thing after today’s heating degree days and maybe that day of week is, what was the temperature yesterday? How many heating degree days did we have yesterday?

The reason for that is there’s a thermodynamic effect when it comes to heating, where it takes a little bit of time for that cold air outside to get through the insulation in our walls and start affecting thermostats or human behavior, people turning up their thermostats, etc.

Other things that matter some places more than others are things like humidity. That’s going to have a big effect in places that have large swings in humidity. Places that are dry all the time, maybe not as much. There’s some things that come up in more niche situations like how cloudy is it, or the direction of the sun. When it comes to electric demand, that matters a lot more.

Russel: It’s interesting. I notionally understand this because of a lot of experience in control rooms around utilities and around SCADA systems around utilities.

On the surface of it, it would seem fairly simple. I know what my base commercial load is Monday through Friday, and I know what my heating load is based on temperature, but it’s just that if I’m dialing it in and I’m trying to get to a level of accuracy and repeatability, then it becomes a lot more subtle than that, is what I’m trying to say.

Greg: When it comes to doing what you described, that’s pretty easy. You can pretty easily forecast the normal situation using a basic understanding of what your base load does Monday through Friday and looking at the number of heating degree days.

Where we try to focus a lot of our efforts is, what we call, unusual days, so days with big temperature swings from one day to the next, or days that are much colder or warmer than normal.

Those days, especially shoulder months when we’re transitioning between heating and cooling or on extreme cold events. Those days are rare, and also have some interesting additional variables that are going to affect things a lot more than your typical day.

Russel: Right. Things like, is the wind blowing? Is the sun out? Snow on the ground is different and cold, and no snow on the ground. All those things impact where people set their thermostats and how hard the system has to work in order to achieve that number. It’s a lot of things. It gets complicated.

What about things like holidays or other kind of unusual events? I suspect, for a lot of people, the whole COVID thing caused a whole bunch of hiccups in their forecasting models.

Greg: Oh, yeah. I’ll talk about holidays first, and then we can circle back around and talk about COVID. When it comes to holidays, some holidays are pretty easy.

Martin Luther King Day, Labor Day, those holidays that always fall on the same day of the week, we get that every year, and we understand, “Well, it’s going to be on a Monday. It’s probably going to act a little bit more like a Sunday than a Monday does normally.” We can make some adjustments to our forecast based on that.

Where things get tricky is when it comes to holidays that move around. Christmas is going to occur on a different day a year, every year. If we only are looking at 10 years of data, how many Christmases on a Tuesday are we going to have in that dataset?

Probably one or two, which makes an event like Winter Storm Elliot, where we had an extreme cold event, come in right before the holidays. That was  a Christmas Eve that was extremely cold. The particular day of the week that occurred, I can’t recell off the top of my head.

What does that look like? Well, we haven’t seen. We’d have to look back in our dataset for a while. We do some adjustments. We focus on what day of the week it’s occurring on and try to adjust, “Well, this is going to act more like a different day of the week.”

Then we do a load adjustment saying, “All right, we know our models are usually going to be a little bit long, or we’re going to forecast too high on days like Christmas and Thanksgiving for a particular area. We know about how much that happens, and we can make a little adjustment using some assumptions there.”

Russel: What about something like a completely unusual event like COVID? How do you go about approaching something like that where, all of a sudden, the load is shifting from the commercial office space and the factories to the homes?

Tom: That was a tricky problem to deal with. Everybody is suddenly working from home overnight. For some territories, some LDCs, they saw a pretty big increase in their load because people were not turning their thermostats down at their homes during the day because they were in their homes.

Others that maybe have a different mix of commercial, industrial, residential saw a loss in load because suddenly offices weren’t filled, and they were keeping their thermostats low. We have a lot of methods that we use to track our model coefficients over time and try to make adjustments based on growth profiles.

We use this mostly for growth, typically, whereas as you bring on more customers and you gain efficiency over time, those can affect the profile at the full system level. We used similar techniques to try and model, “How has your load changed?”

We did this for several of our customers back in 2020/2021, looking at, “How did your system change during COVID by looking at what happened to your baseload during that time period?” Or, what happened to that use per degree day or that day of week effect that maybe was stronger or weaker than what we’d seen previously?

Russel: One of the things I’m taking away from all of this is that by using a more advanced model, it gives you the ability to dial it in better for your particular situation, but it’s not like you don’t still need the expertise.

You still need the knowledge of your system and the knowledge of your history, and to be able to understand what part of this particular model in this particular implementation matter.

I think about things like, if I’m in the mountains, I’m in a valley, very different than I’m in the plains. Even if the degree days and the temperatures are the same, things like sunshine, cloud cover, wind are very different and have very different impacts on heating requirements.

Look, I want to shift again a little bit, I’ll talk a little bit about the data. Where do you get your source data for the model, and what do you have to do to make that data work in the model? In other words, I’m saying not all data is created equal. What do you do to equalize your data?

Tom: Fortunately, it’s a pretty straightforward process to identify and collect the data needed to build a good model. As you can tell, we extract a lot of information from the calendar, so a company doesn’t need to provide us that. Though we do support holidays that are, say, proprietary to certain regions like Patriots Day in the Boston area.

Essentially, if we’re building a daily model for an LDC, we would like as many days of measured sendout as we can get, going back as far as possible. We can start with as shallow a data set as two or three years.

We’d prefer something like what Greg said earlier, like at least 10 years, because if you think of the winter storms, the peak events, Christmas Eve on a Monday, and Christmas Day on a Tuesday, which is going to have a weird shape to the load curve going through those days, you’re only going to have a very few set of those types of events.

The more we can get, the more information we can leverage from those datasets. Then, we need historical weather data. We accept that. If the customer has their own record that they prefer we use, we’ll get it from them.

More often than not, we’re pulling it down from NOAA or from one of our weather data partners, where they have archives of this, and they’ve cleaned the data and preserved it for us.

Then, that gets turned over to Greg’s team, and they apply several different treatments to that, the first being just looking for outliers. We’ll get datasets where there’s just days missing, and we’ll find out that either there was an equipment failure or somebody forgot to type in some values during those days.

We’ll find days where the load is unexpectedly high or low based on all the other observations in the dataset. Sometimes, those are perfectly legitimate measurements, but we like to know why they’re in there so that we understand some of the characteristics of the system we’re trying to forecast.

Russel: Simply stated, it’s, how much gas am I sending into my system and what was the weather?

Tom: That’s the starting point, yes.

Russel: What about things like nonweather-related load? Things like power generation, although power generation can certainly be weather related. In a lot of cities, particularly that have significant industrial complexes, there’s a lot of consumption that’s related to manufacturing and maybe cyclical.

Like somebody that’s making bricks, they’ve got a kiln, and they turn that kiln on, and they run it wide open for three days, and then they let it sit and cool for three days. Those kind of things, particularly if you’re looking at segmented load, can have pretty significant impacts.

Greg: That’s always a tricky thing when we’re trying to put together the dataset we’re going to build our models on.

For some folks, we want to pull out their transportation or large industrial or electric generation and say, “OK, we’re going to separate that out, and we’re going to forecast that separately, and we’re going to have this nice residential and commercial load that we can forecast extremely well.”

Especially if the distinction there is between sales and transport, usually, when we’re talking to local distribution companies, they care most about their sales, then what their transporters should be nominating.

For the case like the folks running the kiln, the best way to know what they’re going to use isn’t going to come from a mathematical model. It’s going to be calling them and asking them how much gas they’re going to use. It has its own problems and isn’t a perfect solution.

Russel: No, far from it. Do you take nomination data into your model?

Greg: We do not. We usually let the local distribution company handle that. They’ll take our forecasts and then add back in those large customers.

Russel: You’re primarily doing weather-based forecasting.

Greg: Depends. For some territories, their industrial is such a small piece of it that we forecast that baked into the baseload, usually. It depends on, can folks separate out that information or not?

Russel: Right, and to what degree is that type of consumption part of their overall load? If it’s one percent or two percent of the load, it doesn’t matter. If it’s 30 percent or 40 percent of the load and it’s variable, it probably matters a lot.

I would speculate that that’s been one of the challenges in some of the weather events in Houston, is so much of the load in Texas on the electrical side is not predictable. When it gets cold and the wind lays down and, all of a sudden, you got to fire up all the swing plants to generate electricity, that’s a different kind of complexity in your forecasting, is what I’m trying to say.

One of the things I know about any model is that you’ve got to get the data to the model in a way that it’s well-structured and clean.

I could see how you could do that with the weather data coming from NOAA or something like that because that data is well-structured out of the gate and it is what it is, but how big a deal is that to get the data structured and clean in order to feed it to the model?

Greg: I completely agree. We’ve had a running joke at the lab and now at the company that the three most important things for forecasting energy demand are good data, good data, and good data.

Russel: I’m taking that, calling it my own. That’s perfect.

[laughter]

Greg: Fair enough. It depends on what is available from the folks on the other end who are feeding that data into our systems. For some folks, they have a process where they go through and figure out from their SCADA systems, “This is what our sales ended up being from yesterday.” We can feed that in and say, “All right, that’s that data point.”

For other folks, it takes a little bit longer. They’ve got a longer amount of time it takes to collect. Here’s all those large industrial customers that we’re pulling out of or we want to basically subtract out of that data set before we feed it into the stuff we’re looking at.

Russel: It’s a matter of understanding, in all of the flow data that you have in an operating company, what is the data that you want to see and make sure that that’s what you’re getting and you’re consistently getting that data?

Greg: Yeah. We’ve got a couple of ways that we can monitor what folks are putting in so that we know that data point is much higher than we would have expected. Maybe that’s something we got to reach out and say, “OK, did we get something that we weren’t supposed to?”

Russel: Then once you identify your sources and you structure that data, what’s the process to actually drive the model? How automated is that, how much care and feeding is required? Trying to understand, and for pipeliners’ benefits that are interested in this is what’s the level of effort, what’s the process, and how often is it occurring? What does that look like?

Tom: We understand, we’ve learned over the 25 years we’ve been sending this technology out, that this has to be as reliable as possible. People come in early in the morning. It’s prior to the start of the GasDay. They have a nominating window. They need forecasts to schedule gas and be ready for the GasDay when it starts.

Our models will fire a forecast on a schedule. They also have the ability to fire a forecast any time new data is present, but basically, when it’s forecast time, our system will connect to the weather vendor that is providing forecast data, scrape the most recent observed weather data, and forecast weather data off of that site.

We take hourly weather data, we align it to the GasDay, and then we begin computing factors, like what’s the average temperature for those 24 hours? What’s the high? What’s the low? Sometimes we break that down into four quartiles of weather measurements for the day depending on the model structure that we’re using.

Then, we look for those prior-day measurements, or, usually, if it’s very early in the morning, you’re in the last three hours of a GasDay, you don’t know what that GasDay’s measurement is going to be.

We’ll hope to find the two-day ago measurement because that helps us, if we can get at those measurements, we can build an auto-regressive model that can use recent prior data to help improve the forecast.

All that’s automated, usually through secure file transfer. We have a secure API, and some of our customers have developed the ability to connect to that that’s actually more reliable and more secure. We retrieve all the weather data as much as possible through our secure application interfaces, and APIs from the weather vendors.

Then, once that’s all read into our database, the weather data is sorted out, then we fire the model. It gets passed through the model, a new forecast is generated, populated into the database, published via email, via on-screen reports. We have a whole number of ways that a customer can receive a forecast from us. We try to accommodate all their business cases.

Russel: How often are you typically updating a forecast?

Tom: For some customers, we run one forecast a day, for some customers we have six or seven separate forecast periods during a given GasDay. That tends to depend on what our customer’s opportunities are to improve their nominations and scheduling. If they have a mid-afternoon opportunity to adjust what they’ve scheduled for the day, we’ll run a forecast for them.

Usually, that early afternoon forecast can take advantage of the data generated by the GasDay that just concluded and by a more current weather forecast and produce a more accurate daily or hourly forecast.

Russel: I’m going to make a statement. I don’t mean to frame this as a question, but I would speculate that if I’m primarily a utility and I’m primarily delivering to households, then a daily update of the model is probably adequate, maybe twice a day.

If I’m a large utility with more complex load issues, I might want to update many times a day so that I can be more proactive about how I’m setting my nominations off of my suppliers. Is that fair way to think about it? Do I have that right?

Tom: You do. It’s very fundamental. That is exactly right. We’ve also learned that every single one of our customers has their own unique configuration of what their supply portfolio looks like, what storage they have available, what their options are if they’re long or short.

We have developed ways of meeting all the requirements that those different scenarios can present, but we’re always finding new ones because we’re always signing up new companies to work with. For somebody who balancing off of storage, their need for a super-accurate forecast late in the day often isn’t as prominent unless it’s late in the month or late in the storage season.

Somebody who’s living off the end of a one or two very long pipes is going to be a lot more interested in getting a very accurate forecast.

I should also mention that we’re used typically in two different functions within a natural gas utility, where we’re used within gas control, and sometimes those folks are living and dying by the hourly forecast. They’re flying the live gas distribution system.

If it’s an unusual event, there’s a cold front coming in, those folks are typically very concerned on what we call day zero. They’re focused on today’s GasDay perhaps hour by hour.

Then, we’re also very widely used in gas supply organizations, where they’re always looking a day ahead. People ran our forecast today so that they could have their supply lined up for Saturday, Sunday, and Monday.

Russel: I know that for some operators where they do not have storage but they’re on a large pipeline system for delivery, they’re often looking out three to five days, particularly when they see a cold event coming because they need that supply pipeline to pack up in order to be able to deliver. There’s a lot of coordination.

Sometimes the issue is more about accurate long term. Sometimes the issue is more about accurate short term.

Tom: Yes, that’s exactly right.

Russel: Look, this has been a great conversation for the listeners. I’ll let you know that this is first of a two-episode series. We’re going to wind this conversation up and pick back up next week, and we’re going to be talking a little bit more deeply about looking at forecasting and gas demand for peak demand days, which is another interesting topic around all this.

Tom, Greg, thank you very much for joining us. I look forward to picking it back up.

Tom: Great to talk with you, Russel. Thank you.

Greg: Thanks, Russel.

Russel: I hope you enjoyed this week’s episode of the Pipeliners Podcast and our conversation with Tom and Greg. Just a reminder before you go, you should register to win our customized Pipeliners Podcast YETI tumbler. Simply visit pipelinepodcastnetwork.com/win and enter yourself in the drawing.

If you’d like to support the podcast, please leave us a review. You can do that on Apple Podcasts, Google Play, wherever you happen to listen. You can find instructions at pipelinepodcastnetwork.com.

[background music]

Russel: If you have ideas, questions, or topics you’d be interested in, please let me know on the Contact Us page at pipelinepodcastnetwork.com or reach out to me on LinkedIn. Thanks for listening. I’ll talk to you next week.

[music]