Forecasting earthquakes via ML should be possible but is very strongly limited by data. We have ~50 years of reasonably good seismological catalogs for most of the world. The seismic cycle (the sequence of major earthquake, reloading, major earthquake on a single section of fault) is generally thousands of years except at the fastest-slipping faults. There are very few sections of faults where we have seismological observations of multiple events, and for >90% of faults, we don't even know when the last earthquake was. There are geologic methods to help with this, but they are labor intensive and often yield error bars of hundreds to thousands of years, because the earthquakes don't produce radiocarbon signatures directly; the geologists use e.g. charcoal older and younger layers as available to bracket the timing, and many faults do not have suitable geologic sites to preserve the earthquake deformation and bracket the timing.
I do think it's possible that thorough exploration of the data that do exist can yield broader patterns that apply to many regions, but earthquake behavior has a lot of complexities and different fault systems may behave differently.
A lot of the hope is for coupling physical simulators to ML and the existing datasets to better understand the physics and then work from there, but this is typically cutting-edge HPC work, which limits the pace of research and the number of researchers.
You seem to know much more about this topic than I do, and your assessment agrees with mine. Predicting rare and sudden events is a very difficult modeling problem generally, and the data limitations is real. I agree that it will probably need to come from coupling of ML with physical simulators plus more extensive 3D map data on force vectors, material properties, etc.
>The system is what geologists call a fault-controlled non-volcanic geothermal feature.
These are quite common. Hot Springs National Park in Arkansas is a notable example. Most of the hot springs in Idaho are on fault lines, as are the hot springs along Highway 395 on the east side of the Sierras (though there is Quaternary volcanism in the region, it's not the source of heat), and through much of the rest of the Intermountain West.
This site seems to be unique for both the volume and the temperature of water, though. I'd be curious to know how far away the water originated, and how deep it goes before being heated. The crust in the area is not known to be particularly hot, as far as I know, unlike the Basin and Range of the western US where tectonic stretching and thinning of the crust has brought the hot mantle much closer to the surface and increased the geothermal gradient.
We're a century into it at least, even in nominal dollar terms, starting with Rockefeller as the first billionaire.
I don't know whether John Arnold is spread too thin or not, but he's certainly top caliber and does a lot to measure progress before/during investment in various causes (including education). He also seems to be more agnostic on what the most appropriate solution may be at the beginning of the process.
Maybe, just maybe, this is of obvious utility to the many people who have needs that are not yours?
I very regularly need to interact with my work through a python interpreter. My work is scientific programming. So the variables might be arrays with millions of elements. In order to debug, optimize, verify, or improve in any way my work, I cannot rely on any other methods than interacting with the code as it's being run, or while everything is still in memory. So if I want to really leverage LLMs, especially to allow them to work semi-autonomously, they must be able to do the same.
I'm not going to dump tens of GB of stuff to a log file or send it around via pipes or whatever. Why is there a nan in an array that is the product of many earlier steps in a code that took an hour to run? Why are certain data in a 200k-variable system of equations much harder to fit than others, and which equations are in tension with each other to prevent better convergence?
Are interpreters and pdb not great, previously-existing tools for this kind of work? Does a new tool that lets LLMs/agents use them actually represent some sort of hack job because better solutions have existed for years?
I agree that at first glance, it seems like tmux, or even long-running PTY shell calls in harnesses like Claude, solve this. They do keep processes alive across discrete interactions. But in practice, it’s kind of terrible, because the interaction model presented to the LLM is basically polling. Polling is slow and bloats context.
To avoid polling, you need to run the process with some knowledge of the internal interpreter state. Then a surprising number of edge cases start showing up once you start using it for real data science workflows. How do you support built-in debuggers? How do you handle in-band help? How do you handle long-running commands, interrupts, restarts, or segfaults in the interpreter? How do you deal with echo in multi-line inputs? How do you handle large outputs without filling the context window? Do you spill them to the filesystem somewhere instead of just truncating them, so the model can navigate them? What if the harness doesn’t have file tools? And so on.
Then there is sandboxing, which becomes another layer of complexity wrapped into the same tool.
Are you aware that you can use tmux (or zellij, etc.), spin up the interpreter in a tmux session, and then the LLM can interact with it perfectly normally by using send-keys? And that this works quite well, because LLMs are trained on it? You just need to tell the LLM "I have ipython open in a tmux session named pythonrepl"
This is exactly how I do most of my data analysis work in Julia.
In the data science scenario you should just have proper tooling, for you it sounds like a REPL the agent can interface with. I do this with nREPL/CIDER; in Python-land a Jupyter kernel over MCP maybe. For stateful introspection where you don't control the tooling, tmux plus trivial glue gets you most of the way.
edit: There are much better solutions for Python-land below it seems :)
What I do is have a quick command that spins up a worktree on a repo with my ghostty splits as I like them and the tmux named the worktree. I then tell the Claude code about the tmux when it needs to look. It’s pretty good at natively handling the tmux interactions.
Ideally Ghostty would offer primitives to launch splits but c’est la vie. Apple automation it is.
I use both gvim on linux and macvim on mac for a lot of things--not 'real' coding, typically, but opening and editing scripts and config files, writing in markdown, etc; I'm usually opening these from dolphin or finder. In the terminal, working on real code bases and not scripts, I use neovim. My configs for these have diverged a bit over the years but since the use cases are different, it doesn't bother me.
Thanks. I've got an OpenAI subscription and tried this in the past, and got a handful of results, but nothing comprehensive. Perhaps it is better now, or I could change the way I ask.
No prob, see if there's anything useful in any of the links I added to the post. I'm always interested in good benchmarks and test cases, as I usually don't have enough of my own to justify my expensive pro subscriptions. (I did not review them myself as I don't know what I'm looking at.)
A few years later, the gravitational deflection of the Himalayas on a plumb line by Airy proved less than expected, which suggested that mountains have 'roots' that extend below them, displacing more dense rock--like icebergs more or less.
I used the gravitational force of the Longmenshan range to calculate the perturbations in the elastic stress field of the Earth's crust in Sichuan province, China, to estimate the tectonic forces in the region, which caused the 2008 Wenchuan earthquake: https://agupubs.onlinelibrary.wiley.com/doi/full/10.1002/201...
Think of those numbers as one kind of in extreme case argument.
Another reality is that most of the global grid scale energy usage is not transport via mobile batteries that benefits most from high energy density lithium batteries that pack maximal energy from least weight.
Battery farms don't move, they can use other battery chemistries that are cheaper in resources and weigh a lot more per energy unit than lithium while still powering cities, smelters, processing plants, etc.
As for desalination in general, yes, there will be a lot more of that in coming years, fresh potable water supplies are stretched from a global PoV.
I do think it's possible that thorough exploration of the data that do exist can yield broader patterns that apply to many regions, but earthquake behavior has a lot of complexities and different fault systems may behave differently.
A lot of the hope is for coupling physical simulators to ML and the existing datasets to better understand the physics and then work from there, but this is typically cutting-edge HPC work, which limits the pace of research and the number of researchers.