James A. Rising

Dividing an elephant in half does not make two small elephants. It makes one mess.

The same is true of our oceans. Modern management of the natural environment is all about dividing up elephants, assigning the halves to different owners, and blinding ourselves to the activities beyond our halves. But just as with elephants, pieces of an ocean depend on each other: fish and currents do not respect national boundaries.

That is the starting point of a new paper Nandini Ramesh, Kimberly Oremus, and I recently published in Science, entitled “The small world of global marine fisheries: The cross-boundary consequences of larval dispersal“. We wanted to understand how national fisheries depended upon each other.

To study this, we used the same model used to study how debris from the Malaysia Airlines Flight 370 crash ended up halfway around the world:

Instead of looking at airplane debris, we looked at fish spawn. Most marine species spend a stage of their lives as plankton, either in the form of floating eggs or microscopic larvae. They can travel huge distances as they float with the currents, sometimes over the course of several months. We can use those journeys to identify the original spawning grounds of the adult fish that are eventually caught.

These connections are important, because they mean that your national fisheries depend upon neighboring countries. Spawning regions are highly sensitive, and if your national neighbors fail to protect them, the fish in your country can disappear. A country like the UK depends upon plenty of other countries for its many species.

Finally, this is not just an issue for the fishing sector. We also looked at food security and jobs. People around the world depend on the careful environmental management of their neighbors, and it is time we recognized this elephant as a whole.

Shortly after I joined LSE, Stéphane Hallegatte from the World Bank gave a presentation on their new report, “Unbreakable”. The report is about how to measure risk in the face of the potential to fall into poverty, and includes one of my favorite graphs of the last year:

I think it’s an amazing bit of modeling to be able to relate natural events to the excruciatingly chaotic process we call “falling into poverty”. But it’s the scale of the two sides of the graph that blows me away. On the left, earthquakes, storm surge, tsunamis, and windstorms all together account for about 1 million people falling into poverty every year. On the right, floods account for 10x as many, and droughts account for an additional 8x as many.

The reason is that floods and droughts are naturally huge events– covering large areas and affecting millions of people– every time they occur. The second is that they occur all the time.

This gets at the importance of water. Most of the researchers I know don’t spend much time thinking about water. They know it’s important, but in a way that’s so commonplace as to be invisible. We just said that 18 million people fall into poverty each year from floods and droughts; in 2015 there were 736 million people in poverty total. That means that if we magically got everyone out of poverty today, in 41 years, there would have already been 736 million new instances of poverty from floods and drought alone. Water is about enough to explain the stubbornness of extreme poverty all on its own.

At the Sustainable Development Research (SusDeveR) conference this weekend, I offered some simple tools for performing Bayesian Regressions: Jump to the Github Repository.

The point of these templates is to make it possible for anyone who is familiar with OLS to run a Bayesian regression. The templates have a chunk at the top to change for your application, and a chunk at the bottom that uses Gelman et al.’s Stan to estimate the posterior parameter distributions.

In general, the area at the top is just to create an output vector and a predictor matrix. Like this:

The template part has all of the Stan code, which (for a Bayesian regression) always has a simple form:

The last line does all of the work, and just says (in OLS speak) that the error distribution follows a normal distribution. Most of the templates also have a more efficient version, which does the same thing.

I say in the README what Bayesian regressions are and what they do. But why use them? The simple answer is that we shouldn’t expect the uncertainty on our parameters to be well-behaved. It’s nice if it is, and then OLS and Bayesian regressions will give the same answer. But if the true uncertainty on your parameter of interest is skewed or long-tailed or bimodal, the OLS assumption can do some real harm.

Plus, since Bayesian regressions are just a generalization of MLE, you can setup any functional form you like, laying out multiple, nonlinear expressions, estimating intermediate variables, and imposing additional probabilistic constraints, all in one model. Of course, the templates don’t show you how to do all that, but it’s a start.

The water-energy-food nexus has become a popular buzz-word in the sustainability field. It aims to capture the idea that water, energy, and food challenges are intertwined, and that shocks to any one can precipitate problems to all three.

I’ve often wondered how closely these three are intertwined though. Water is certainly needed for energy (for thermoelectric cooling and hydropower), but the reverse link (mostly pumping) seems a lot weaker. Water is also needed for food production, but is food needed for water availability? Energy and food have some links, with a fair amount of energy needed to produce fertilizer, and a some “food” production actually going to biofuelds, but the sizes aren’t clear.

Below is my attempt to show these flows, for the United States:

Water-Energy-Food Flows

It seems to me, based on this, that this is less a nexus than water-centered system. Every drop of water is fought over for energy, food, and urban production. It’s less a interconnected nexus than a hub-with-spokes. A way to recognize that water is at the center of it all.

Sources:
– Hydrological flows: Total water (GW+SW) extractions from USGS. Food system only has irrigation and livestock; energy only has thermoelectric. The rest make up the difference.
– Energy system flows: Food system energy from Canning, P. 2010. Energy Use in the U.S. Food System. USDA Economic Research Report Number 94; “In 2010, the U.S. water system consumed over 600 billion kWh, or approximately 12.6 percent of the nation’s energy according to a study by researchers at the University of Texas at Austin.” from http://www.ncsl.org/research/environment-and-natural-resources/overviewofthewaterenergynexusintheus.aspx “Energy consumption by public drinking water and wastewater utilities, which are primarily owned and operated by local governments, can represent 30%-40% of a municipality’s energy bill.” from https://fas.org/sgp/crs/misc/R43200.pdf; remainder to 100%.
– Biofuels: 18.38e6 m^3 ethanol + 1.7e6 m^3 biodiesel, at a density of 719.7 kg/m^3 is 14.45e6 MT.
– Remainder of food: https://www.ers.usda.gov/topics/international-markets-trade/us-agricultural-trade/import-share-of-consumption.aspx reports 635 billion pounds consumption, 81% of which was domestically produced.

I’ve built a new tool for working with county-level data across the United States. The tool provides a kind of clearing-house for data on climate, water, agriculture, energy, demographics, and more! See the details on the AWASH News page.

I love text consoles. The more I can do without moving a mouse or opening a new window, the better. So, when I saw XKCD’s command-line interface, I grabbed the code and started to build new features into it, as my kind of browser window to a cyber world of text.

I want to tell you about my console-based time-management system, the entertainment system, the LambdaMOO world, the integration with my fledgling single-stream analysis toolbox. But the first step was to clean out the password-protected stuff, and expose the console code for anyone who wants it.

So here it is! Feel free to play around on the public version, http://console.existencia.org/, or clone the repository for your own.

Here are the major changes from the original XKCD code by Chromacode:

• Multiple “shells”: I currently just have the Javascript and XKCD-Shell ones exposed. Javascript gives you a developer-style javascript console (but buggy). You can switch between the two by typing x: and j:.
• A bookmark system: ln URL NAME makes a new bookmark; ls lists the available bookmarks, and cd NAME opens a bookmark.
• A login/registration system: Different users can have different bookmarks (and other stuff). Leave ‘login:’ blank the first time to create a new account.
• Some new commands, but the only one I’m sure I left in is scholar [search terms] for a Google Scholar search.

Share, expand, and enjoy!

The research behind the Risky Business report will be released as a fully remastered book, tomorrow, August 11!  This was a huge collaborative effort, led by Trevor Houser, Solomon Hsiang, and Robert Kopp, and coauthored with nine others, including me:

From the publisher’s website:

Climate change threatens the economy of the United States in myriad ways, including increased flooding and storm damage, altered crop yields, lost labor productivity, higher crime, reshaped public-health patterns, and strained energy systems, among many other effects. Combining the latest climate models, state-of-the-art econometric research on human responses to climate, and cutting-edge private-sector risk-assessment tools, Economic Risks of Climate Change: An American Prospectus crafts a game-changing profile of the economic risks of climate change in the United States.

The book combines an exciting new approach to solidly ground results in data with an extensive overview of the world of climate change impacts. Take a look!

My girlfriend uses a “Moka Express”-style stovetop Bialetti espresso-maker most mornings for her cappuccino. These devices are wonderful, reliable, and simple, but they have a nearly fatal flaw. A basin collects the espresso as it condenses, and for the five minutes before the steam brewing happens, there will be no indication of anything happening. Then espresso will start to quietly gurgle up, and if you don’t stop the process in the 20 seconds after it starts, the drink will be ruined.

I built a simple device to solve this problem. It has two wires that sit in the basin, and a loud buzzer that sounds as soon as coffee touches them.

How it works

Here is the circuit diagram for the coffee buzzer, designed to be powered by a 9V battery:

The core of the coffee buzzer is a simple voltage divider. Normally, when the device is not in coffee, the resistance through the air between the two leads on the left (labeled “LOAD”) is very high. As a result, the entire voltage from 9V battery is applied to that gap, so that the voltage across the 500 KΩ resistor is 0.

The IRF1104 is a simple MOSFET, which acts like a voltage-controlled switch. With no voltage across the resistor, the MOSFET is off, so the buzzer doesn’t sound.

To turn the MOSFET on, the voltage across the 500 KΩ resistor needs to be about 2 V. As a result, anything between the two LOAD leads with a resistance of less than about 2000 KΩ will cause the buzzer to turn on.

Coffee resistance seems to vary quite a bit, and the 137 KΩ shown here is on the low end. For this, you need a resistor of at least 40 KΩ. I suggest using something higher, so the detector will be more sensitive.

What you need

Tools

You will need wire-strippers, a multimeter (to check your circuit), and a soldering iron (to put everything together).

Parts

These wires will be the main detector of the coffee buzzer.

Here I use a 1500 KΩ resistor, so the buzzer will sound for resistances less than 5000 KΩ will be detected. Make sure that you use a resistor of more than 300 KΩ.

The MOSFET is a voltage controlled switch, and it’s what allows the buzzer to get plenty of current even though there’s a lot of resistance for current moving through the coffee.

You can get a 9V battery connector (top) and a buzzer (middle, rated for between 4 and 8 V) at RadioShack or from DigiKey. And, of course, the battery itself (not included).

Optional (but highly recommended!)

A simple switch (which may look very different from this one) is a great way to build an integrity tester into the device itself.

A breadboard will let you put the whole circuit together and test it before you solder it.

Wires like these make plugging everything into a breadboard easier.

I suggest taping up the whole device after you solder it, both for protection and to keep everything in one tight package.

How to make an Espresso Buzzer

Start by preparing the detector wires (the black and white wires above). Take at least 30 cm of wire, so the device can sit on the counter away from the flame. Use the wire stripper to strip one end of the wires for use in the circuit. You may want to strip the “detection” end, or not: if you leave the detector end unstripped, the buzzer won’t go off prematurely when if both wires touch the bottom of the basin, but you’ll have to wipe off the end of the wires to get them to stop buzzing once they have started.

Now connect all of the pieces on the breadboard. Here’s one arrangement:

If you aren’t sure how to use a breadboard or how to read a circuit diagram, you can still make the buzzer by skipping this step and soldering the wires together as specified below.

Once everything is connected on the breadboard, you should be able to test the coffee buzzer. If you use a switch, pressing it should make the buzzer sound. Then make a little experimental coffee, and dip the leads into the coffee to check that it works.

Next, solder it all together. As you can see in the circuit diagram, you want to solder together the following groups of wires:

• Ground: The black wire from the battery connector; one wire from the resistor; and the source lead on the MOSFET (furthest right).
• Power: The red wire from the battery connector; one wire from the buzzer; the (stripped) circuit end of one of the detector wires; and optionally one end of the switch.
• Gate: The (stripped) circuit end of the other detector wire; the other end of the resistor; the gate lead on the MOSFET (furthest left); and optionally the other end of the switch.
• Buzzer: The gate lead on the MOSFET (middle); and the remaining wire to the buzzer.

After you have soldered everything together, test it and then wrap tape around it all.

The results

That’s it! Now, to use it, place the detector leads at the bottom of the coffee basin. I suggest putting a bend into the wires a couple inches from the end, so they can sit easily in the basin. If you’ve stripped the ends, the buzzer may buzz when the leads touch the base, but if you just let them go at this point, one wire will sit slightly above the other and just millimeters away from the bottom for perfect detection.

As soon as the coffee reaches a level where both leads are submerged, the detector will start buzzing!

Enjoy!