Skip to content

Jonathan Frame

  • 4 min read

What does your model do?

In Earth Sciences we build all sorts of models for one reason or another. I've recently gotten into several conversations where we discuss an aspect of modeling that breaks down what we want, what we ask for, and what the model was actually built to do. In an ideal scenario, all three of these would be the same. But, in reality, this is never the case. We need to build models sometimes only as a stepping stone to our desired goal. Sometimes that stepping stone has to be shakey in order to get to where we want to go. But one important thing about modeling, is the model is NEVER the end goal, or at least it shouldn't be. I worry sometimes that models are being build for their own sake. If you are having a hard time connecting the dots of how your model will be used, this blog is for you.

We can visualize this problem as a 3D coordinate system. On the X-axis, we have how well-defined our task is. On the Y-axis, we have how achievable it is. We might have a Z-axis: Alignment. If the circles of our intention don't overlap, we end up successfully completing a task that fails to solve the actual problem. Let's break every modeling project into three distinct items:

  • Goal: What do you actually want?
  • Task: What did you ask the model to do?
  • Design: What was the model designed to do?

When these three are in direct overlap, you have a useful tool. When they drift apart, you have a "Success-Failure": a model that does exactly what you told it to, while not bringing you any closer to your end goal.

Example 1: Should I bring my umbrella?

This is an example of an ideal alignment of goal, task and design in modeling. You want to stay dry on your walk to work. You use a short-range weather model to see if it will rain in the next hour.

  • Goal: Bring umbrella on walk.
  • Task: Forecast weather 1 hour out.
  • Design: Short-range forecasting.

In this scenario, the definitions are precise and the task is highly achievable. The circles overlap almost perfectly. If the model says "rain," and you grab the umbrella, your goal is met. The end goal of bringing an umbrella is relatively small compared to the massive modeling frameworks that go into modern weather forecasting.

Should I bring an umbrella to work

Example 2: Do I need a jacket on my trip next week?

Now, let’s stretch the temporal scale. You’re packing for a trip next week. You ask a mid-range model for a forecast.

  • Goal: Pack for upcoming trip.
  • Task: Forecast weather 1 week out.
  • Design: Mid-range weather forecasting.

Here, the Definition is still high, but Achievability starts to drop. Chaotic atmospheric dynamics mean that a 7-day forecast is less reliable than a 1-hour one. The overlap between your Task and your Goal shrinks. You might pack shorts based on a "Sunny" forecast, only to arrive in a cold snap. The model did its "Task," but the "Goal" (being prepared) was undermined by the inherent limits of the "Design."

What should I bring on my trip

Example 3: Solving Flooding (The Alignment Trap)

This is where things get dangerous. We often set out with a massive, virtuous goal, such as eliminate flood hazards. But how do we translate that into a computational task? Sometimes, we produce a model, validate the results, then call it a day, even though this won't neccessarily get us closer to our goal.

  • Goal: Eliminate flood hazards.
  • Task: Produce 100-yr flood map.
  • Design: Inundation from streamflow.

The Task is extremely well-defined (X-axis) and generally achievable (Y-axis). But the Alignment with the Goal is poor. A 100-year flood map tells you where the water goes in a massive, rare event. It doesn't tell you about the 20-year flood that washes out a low-water crossing, or the flash flood that overwhelms a storm drain. The end goal of solving flood hazards entirely is much larger than even the most complex models that go into flood prediction.

If we use the map as our sole development strategy, we might "pass" our task by keeping houses out of the 100-year zone, but "fail" our goal because people are still dying in their cars on "safe" roads.

Let's solve flooding

We should strive for as much overlap as possible between our end goal, model design, and model task. This is extremely hard, however. We should at least be transparent about our task alignment. We can continue improving our models to give us better "Tasks" (better hydrograph matching), but if our "Goal" is ecosystem health or water equity, we can't assume that a better-fitted line on a graph automatically translates to a better outcome in the real world.

I recommend that next time you are working on a model, you think through this alignment excercize.

  • 4 min read

Doing AI Hydrology to assess water resources for AI expansion... to continue doing AI Hydrology

In January (2025), the Stargate project was announced by the president of the United States, which will be a $500 billion investment over the next four years building new AI infrastructure.

In 1956, we introduced the National Interstate and Defense Highways Act (NIDHA) with an authorization of $25 billion (equivalent to $215 billion in 2024). The typical take on the NIDHA is that it facilitated an economic growth, national security and personal mobility. Another take, however, is that the highways destroyed American cities, segregated economic classes, and created a mobility barrier requiring a personal automobile. There is no doubt, what-so-ever, that the NIDHA changed American life and culture (for better or for worse...). Shortly after the NIDHA the air quality in Los Angeles reached an all time low, before the Clean Air Act in 1963 set a course for air quality improvement. Along with the Clean Water Act and the Endangered Species Act, these regulations are largely responsible for any protections we have against corporate pillaging of the environment.

Part of the Stargate project is a commitment from the federal government to eliminate any barriers to the expansion of AI Infrastructure. Presumably, this means no need for environmental regulation, nor consideration of the impact to American lives or culture.

Expanding AI Infrastructure will require increasing H2O demand, consumptive use, and pollution discharge, even with environmental regulation in place. The hydrological sciences now are thoroughly imbedded with AI Research. Common "low hanging fruit" papers are simply just slight modification of Deep Learning architectures, to keep up with the latest advancements from computer science, and adding a line on a standard benchmarking dataset. This is not by accident, but was actually called for by early adopters of the third book of AI in hydrology (including me).

Use of AI tools, like LLMs, is rapidly on the rise. From a H20 standpoint, this fact is itself troublesome. Even though I find these tools incredibly useful for my daily tasks, particularly programming, I am now beginning to reflect on the importance of my task in general. I've been writing computer programs for hydrology and hydraulics modeling since 2008. Sometimes these models are considered "AI", sometimes they aren't, but recently almost all my models incorporate some aspect of AI. My whole academic career has been defined by my development and analysis of AI for hydrologic and hydraulics modeling. You see, I've been riding this growing wave of research funding specifically for AI for H&H modeling. We are now at a point where hydro research without AI has little chance of funding. And I suspect this to be the case in most other academic fields as well. The feeling I am getting is "Do AI, or we aren't going to fund your research".

Recently though, I've heard several anecdotes of businesses now taking the same stance. Startup companies that don't have much AI tech involved probably aren't going to get funded. Just yesterday I heard that one company that had a long standing client in MS, but didn't have an AI portfolio, was told by MS to "start doing AI, or stop working with us." This goes well beyond a growth of a technology due to an organic increasing demand, and is starting to seem like growth for its own sake, perhaps as a means to keep the "bubble" growing.

I've spend my entire life advocating for means of transportation other than personal automobiles. I didn't know why, I just liked walking, biking and skateboarding over sitting in a car. In my late teenage years, I figured out that I really enjoyed small streets, vs large streets, but didn't know why. I stumbled upon a blog/group call Strongtowns some point in my early 20s, and I figured out the why. Small streets feel more comfortable because they are designed at the "human scale", while large streets with high speed limits are uncomfortable because they are designed for automobiles which need more space, particularly when traveling at high speeds. From Strongtowns, I also learned about the Automobile Infrastructure Growth Ponzi Scheme. In short, we continue to develop new roads, and we neglect to maintain the roads we have. It is growth for its own sake, not for the benefit of travelers. In most cases, I would actually argue (feel free to ask me about this later), that expanding road networks actually inhibits travel. Automobile infrastructure growth happens to take a whole lot of H&H modeling.

I've now found myself in a scenario where I'll be using and developing AI-based hydrologic modeling in order to evaluate and plan for increasing H20 resources for AI expanding infrastructure. What a time to be alive!

AI Hydro for AI Infrastructure

Note: This blog was written without the use of LLMs. Google was used sparingly.

  • 10 min read

Hydrology is flat, and its buckets all the way down!

For some reason, much of my recent work keeps coming back to buckets, and re-thinking the conceptualization of natural hydrologic systems as buckets. I am generally sick of talking about buckets. I'm hoping that this post is my farewell to thinking about buckets, at least for a while.

Sir Edmond Leakybucket

When I was first learning differential equations the professor told us a silly story about Sir Edmond LeakingBucket, some ol' timey English royal who had to drink his ale quickly because his ale bucket leaked. I went on to study hydrology, so I've had to think about Sir Edmond for the past fiteen years. I can't escape him. Sometimes he mixes two kinds of ales together, sometimes his ale bucket is more complicated or simpler, but he is always losing his ale. Poor guy. Sir Edmond and his bucket do two important things: 1) gives nice differential equation examples, but more importantly for hydrology 2) Leaking buckets are a primary conceptualization for hydrologic processes.

A simple differential equation for the ale level in Sir Edmond's bucket is:

\[ \frac{dh}{dt} = -k \sqrt{h} \]

Where \(h(t)\) is the ale at time \(t\), k is a proportionality constant that governs the rate of outflow. Its solution through seperation of variables is:

\[ h(t) = \left(\sqrt{h_0} - \frac{k}{2}t\right)^2 \]

Where \(h_0\) is the initial ale level in the bucket at time \(t = 0\). This gives us the opportunity to track volumes of ale through this bucket, and match the fluxes from buckets with data collected on real-world hydrological systesm. This is, in a nutshell, the field of computational hydrology, we just need to dress up and add complications to this bucket, and off we go.