Frequently Asked Questions about the NUKEMAP
- Who created the NUKEMAP?
The original NUKEMAP was created in February 2012 by me, Alex Wellerstein, a historian of nuclear weapons. I have a B.A. in History from UC Berkeley, a Ph.D. in History of Science from Harvard University, and I am finishing a book on the history of nuclear secrecy in the United States from the Manhattan Project through the War on Terror. At the time I created the NUKEMAP, I was an Associate Historian at the American Institute of Physics in College Park, Maryland. In 2014, I began working as an Assistant Professor of Science and Technology Studies at the Stevens Institute of Technology, in Hoboken, New Jersey.
Note: I am a historian of physics, not a physicist — people seem to sometimes get confused on this because of the subject matter I study and where I have worked. You can read more about my research on my blog, Restricted Data: The Nuclear Secrecy Blog.
In July 2013, I unveiled NUKEMAP2 and NUKEMAP3D. NUKEMAP2 allows for many more effects visualization options, and the display of casualties and fallout information. NUKEMAP3D allows for the visualization of mushroom cloud sizes in a 3D environment. In December 2013, I upgraded the blast model of NUKEMAP2 to account for arbitrary-height detonations. In April 2015, I performed a major algorithm upgrade to the casualty model to give it much finer-grade calculation of people over small areas and to generally increase its speed of calculation.
Various other tweaks and additions have been made over the course of the intervening years. In 2018 the underlying map engine was converted to Mapbox and Leaflet, because Google changed their pricing scheme in a way that meant my costs went up by a factor of ten, which was unaffordable.
NUKEMAP3D's development has been put on hold after Google announced its deprecation of the Google Earth Plugin API, on which NUKEMAP3D relies.
- The NUKEMAP is intended as an educational resource. It should not be used for emergency planning or emergency response purposes where lives and health might be on the line. It is not a perfect simulation.
Please do not use the NUKEMAP for the purposes of planning an actual detonation. Thank you.
- Can I use screenshots from NUKEMAP in my news story, book, presentation, museum exhibit, etc.?
Generally, yes. The NUKEMAP was created for educational use and I am happy whenever people want to spread it. Please credit me by name. E.g., "NUKEMAP by Alex Wellerstein (https://nuclearsecrecy.com/nukemap/)," is generally sufficient. You should also credit the map imagery: "Map data © OpenStreetMap contributors, CC-BY-SA, Imagery © Mapbox." Note that this line is included on the NUKEMAP itself, so if your screenshot includes it, that should be sufficient.
Note: I am an academic, and do not make any money from the NUKEMAP directly (there are no advertisements, none of the data is "monetized"). My economic ecosystem (academia) is one based fundamentally on credit and attribution, which is what allows me to get grants, funding, promotions, etc. This is why I appreciate being properly credited.
If you are in a position to license the NUKEMAP imagery (e.g., contribute money towards its upkeep and further development), please feel free to get in touch with me.
If you are interested in using a "live" version of the NUKEMAP on your website, get in touch with me and we can talk about the various ways to do that.
If you are a museum and are interested in the possibility of making an interactive NUKEMAP-kiosk, or even a non-interactive but dynamic NUKEMAP display, get in touch with me. I have already developed code bases that allow for such things (a kiosk version of the NUKEMAP can be seen at the Intrepid Museum's A View From the Deep: The Submarine Growler and the Cold War exhibit, for example), so development of such a thing can be done fairly easily and quickly. In general I do charge in most cases for any additional labor I need to do.
If you have any further questions about use of the NUKEMAP or its resources, please get in touch.
- How was the NUKEMAP created?
NUKEMAP is a what used to be called a "mash-up." It takes code written by others — in this case Mapbox+Leaflet (originally Google Maps) — and use it for somewhat different purposes than it was intended, notably to show nuclear weapons effects. In simpler terms, this means that the NUKEMAP is code that can work with web browser technology to show you what happens when a bomb goes off. Information about the models is below.
- Why was the NUKEMAP created?
We live in a world where nuclear weapons issues are on the front pages of our newspapers on a regular basis, yet most people still have a very bad sense of what an exploding nuclear weapon can actually do. Some people think they destroy everything in the
world all that once, some people think they are not very different from conventional bombs. The reality is somewhere in between: nuclear weapons can cause immense destruction and huge losses of life, but the effects are still comprehendible on a human scale.
The NUKEMAP is aimed at helping people visualize nuclear weapons on terms they can make sense of — helping them to get a sense of the scale of the bombs. By allowing people to use arbitrarily picked geographical locations, I hope that people will come to understand what a nuclear weapon would do to places they are familiar with, and how the different sizes of nuclear weapons change the results.
There are many different political interpretations one can legitimately take away from such results. There is not intended to be a simple political "message" of the NUKEMAP.
- Who pays for the NUKEMAP?
The NUKEMAP's server bills are paid for by the College of Arts and Letters at the Stevens Institute of Technology, in Hoboken, New Jersey, my employer. Stevens is very supportive of my modeling and educational work.
See the support section below for further credits and support information.
- Could a terrorist, rogue state, or other nuclear power use this for nefarious purposes?
Nuclear states have people whose jobs it is to do the kinds of calculations that the NUKEMAP does, but they probably use better models that are more specific to their particular targets and weaponry. The NUKEMAP would not tell such people anything that they didn't know.
As for terrorists: If we get to the point where a terrorist group is asking, "where should I set off my nuclear weapon that I have?" then we've already gone past the point of no return. There's no way to avert a catastrophe at that point. No terrorist is going to be surprised that nuclear weapons do a lot of damage. Similarly, it isn't exactly too hard to figure out what the most attractive targets would be even without such a map (the most populous or politically important areas of a target country). So I don't really consider the NUKEMAP to be giving such people anything new. The reason terrorists don't currently have nuclear weapons (so far as we know) has nothing to do with them not being aware that nuclear weapons are impressive and devastating.
All of the effects models used by the NUKEMAP are unclassified. There is no secret information here. What the NUKEMAP does is make the models easier to visualize. I've had a hard time seeing any harm in that. A nuclear effects calculator is not a nuclear weapon. It seems like an obvious statement, but people seem prone to mixing these up.
- Technically, how does the NUKEMAP work?
NUKEMAP is a what used to be called a "mash-up." It takes code written by others — in this case Mapbox and Leaflet (originally Google Maps) — and use it for somewhat different purposes than it was intended.
The casualty estimator uses an ambient population density database to query the number of people who are within various distances of ground zero, and applies a model of casualties to those raw numbers. See more information on this below. The casualty code runs off of PHP and MySQL.
- What determines the default city? Why does it often start as New York City?
When it loads, the NUKEMAP attempts to very quickly determine where the user is based on their IP address. This is a very rough determination of your location; IP addresses correspond with your Internet Service Provider, who may be in a totally different city than you are in (especially if you are accessing NUKEMAP through a cellular network).
Once it has determined this, it then looks through a database of "large global cities" for a city which is close to where it thinks you are located. The idea here is that while your random city might not be a plausible nuclear target, a nearby large city might be, and you've probably been to "the big city" nearby. (The exact determination of which "large global cities" is on the list is tricky; most large cities should be on it, unless they are within the orbit range of a much larger city.)
If it can't find a large city nearby, it just defaults to your nation's capital city (where "your nation" is guessed from your IP address).
If all of this fails (if it has no idea where you're at), it just chooses New York City. The reason for New York City is that it has traditionally been the "most frequently nuked city" in at least the American nuclear imagination, so I figure as far as selecting a default city one can argue there is a historical precedent. It is also one of the most visited cities in the world.
I might also note that I live right next to NYC (Hoboken, NJ), and am in Manhattan at least once a week, so I don't think I can be accused of trivializing its destruction, which would affect me greatly and personally.
None of this approach is perfect, but it seemed like a good tradeoff in terms of difficulty and privacy issues (having NUKEMAP request your exist location felt creepy, and would be much slower in any event).
This feature was updated in June 2019.
- I've found a bug or have a suggestion!
If you are seeing buggy behavior, first, please check the "known issues" below, and if it's not listed there, please send me a detailed description of how you triggered it (and a screenshot if possible!) would be great. Also let me know what kind of computer (e.g. your operating system) and web browser (e.g. Chrome, Explorer, Firefox) you are using.
Suggestions for new additions are always appreciated, even if they can't usually be implemented! But feel free to send them along. I'll do what I can to reply in a timely fashion.
- Known bugs/issues
- NUKEMAP3D doesn't work at all. NUKEMAP3D has been discontinued because Google stopped supporting the Google Earth Plug-in. Sorry! You can use the "Export to KMZ" option in the "Advanced Options" menu to see what it looks like offline, using the Google Earth stand-alone application.
- Sometimes the map doesn't load on some systems. This appears to be an issue with Mapbox. I am working on it.
- NUKEMAP's casualty equations don't take into account fallout, fire, etc. Modeling these things are tricky. Maybe some of these things will be taken into account in the future. Maybe not. We'll see. It depends on funding support, the availability of usable models, etc.
- NUKEMAP doesn't take into account Electromagnetic Pulse (EMP) effects. The range of EMP effects as they relate to both height of burst and detonation yield are very hard to model (there is very little by means of unclassified models for them; there are a lot of simple diagrams out there, none of which are very dynamic). Even harder to model is what those range of effects would mean for people on the ground (it is not as simple as saying "anything electronic in this range of effects would be disabled"). For the moment I am not going to try to model EMP effects both because it is difficult (and my time and resources are limited), and also because I'm afraid of either under- or over-stating the impact of a very controversial and contentious effect, one that various groups have politicized in recent decades.
- The humanitarian impact option doesn't show up. This is currently (hopefully temporarily) disabled, because I moved from the Google ecosystem and haven't worked out a replacement yet.
- What kinds of statistics are kept about usage of the NUKEMAP?
The following statistics are kept about every detonation, unless the "do not log anonymous statistics" checkbox is checked:
NUKEMAP: Effects models
All latitudes and longitudes are rounded to three decimal digits, because I don't really care what block you detonated it on, just the general area. Individual IP addresses are not logged.
- The version of NUKEMAP being used.
- The detonation settings used (kilotons, fallout, casualties, height of burst, etc.).
- The latitude and longitude of the "target," along with a geo-located country name of the target (because geo-location is easier to do as you detonate as opposed to doing it later).
If available, the approximate latitude, longitude, and geo-located country of the user. This information is provided via the Google Maps API ClientLocation service. This is based on your IP address, and often just gives the location of your Internet Service Provider, which is often a few towns over from you anyway. (This information is not provided by Google Maps anymore, and in any case I use Mapbox now.)
- How many active detonations there are, and whether the detonation was set off by "you" or whether you clicked a link to get to it.
If it is NUKEMAP3D, the detonation type (static cloud, animated cloud, effects rings). (NUKEMAP3D is deprecated.)
Why do I record this information? It's because I'm interested in broad usage patterns. You can see a write-up I did of past usage patterns here to get an idea of what I'm doing with them. I want to know whether people nuke themselves or other countries, and what types of bombs they use, and what kinds of scenarios they imagine. As far as I know, no government is going to knock on your door late at night just because you used the NUKEMAP; over 20 million people have used it.
Separately, I use Google Analytics to keep track of web and browser statistics in general. This information is not correlated with the actual "detonations."
- How does the prompt effects model work?
A few of the equations are taken from my own curve fits of data in Samuel Glasstone and Philip J. Dolan, The Effects of Nuclear Weapons, 1977 edition. In particular, the original curves for the calories per square centimeter needed for various burns were significantly modified in the 1977 edition, so my equations reflect that. The blast effects were also taken from the graphs in the 1977 edition (see below).
- What is the difference between an airburst and a surface burst in this context?
There are several differences between surface and airbursts that this model attempts to demonstrate (you can see them if you set an airburst with an altitude of "0", which is not exactly the same in this model as a surface burst). Essentially, the model seems to assume that a surface burst will result in a decreased amount of thermal output, but with a wider fireball (probably on par with the semi-circular fireball photos of the familiar shots of the "Trinity" test). Blast and radiation ignore this setting and treat every shot as an airburst of some altitude.
There are several airburst options. One is "Maximize airburst radii for all effects," which will show what the maximize size of each effect ring would be if the idealized airburst height for that effect ring was chosen. This can be a bit misleading, because it is really showing you a spread of different altitudes (each of the blast effects will indicate what the optimized height of burst is).
Another is "Optimize for overpressure." This means that for a given radius of maximum overpressure (e.g., 5 pounds per square inch), the code will figure out the altitude of detonation of the weapon that would maximize it. The reason that such optimized altitudes exist is because at certain detonation heights, the blast wave will reflect off of the ground and interact constructively with itself. This is graphed in a so-called "knee curve" that shows how at certain heights there is a big "bulge" in the radius of a given overpressure:
NUKEMAP's code uses data from Glasstone and Dolan's charts (like the one above) which has been translated into raw numbers. Unknown points are interpolated. More details on this are available in this blog post. In the case of the optimized choice, NUKEMAP will figure out the optimal burst altitude and then render the effects as if you have selected an arbitrary burst height (see below).
The "burst height" option allows you to set an arbitrary height of burst. It will scale all effects except the fireball for what the effects on the ground would be. (Generally speaking, the fireball radius matters only for ground effects if the bomb is detonated at surface or near-surface heights.) In the case of the blast effects, it takes into account whether there is Mach reflection or not (using charts like those shown above). For thermal and radiation effects, it calculates an idealized sphere of maximum effect and then uses slant range to find where it would intersect with the ground.
None of these models do not take into account terrain, building shielding, atmospheric reflection (e.g. off of inversion layers), or atmospheric opacity (e.g. there are different thermal propagation rates depending on humidity). This is because modeling these effects is much more difficult, and requires accurate information about the terrain, buildings, and atmosphere, which I do not have access to (as of yet), and even if I did, might require computational resources exceeding those of a web browser. Including these sorts of effects in a future version of the NUKEMAP is a potential goal, but there are technical limitations involved. One should consider the NUKEMAP's visualized effects to be "back-of-the-envelope," "order of magnitude" estimations that might be either increased or decreased under different local environmental situations or different assumptions about the targets.
- How does the fallout model work? How should the contours be interpreted?
When a nuclear weapon explodes, it produces prompt (immediate) radiation, but it also produces radiation that is released in the shorter and longer terms. The "short-term" radiation, defined here as the radioactive residues of the explosion that remain active for the next few weeks or months (as opposed to years) that "fall out" of the mushroom clouds is known as the "fallout."
It is very difficult to accurately model radioactive fallout. There are many relevant variables: the height of the blast detonation, the ratio of fission to fusion reactions in the bomb (most thermonuclear weapons derived at least 50% of their yield from fission reactions), the type of terrain the explosion is detonated on or over (e.g. desert, coral reefs, inhabited cities), and, importantly. the weather conditions, including wind shear at the many different altitudes at which the cloud exists. (Mushroom clouds go up to the 10,000-100,000s of feet and are exposed to different wind conditions along that distance.)
There are two basic approaches to modeling fallout. One is to try and develop a model based on weather conditions. These are complex and computationally intensive, but yield results that match up very well to past testing results. The other are what are known as "scaling models," which present graphs that attempt to give a general idea of the approximate distances of various levels of radioactive exposure, but make no attempt to model realistically specific wind conditions.
The NUKEMAP fallout model is a scaling model. This is not because scaling models are the best, necessarily, but there are things in their favor. For one, they are computationally very easy: one does not need to know detailed meteorological data about the location of the detonation, and thus can be generalized to many times and places very easily. Their falseness is also quite apparent: people are not as likely to confuse their contours as being entirely realistic estimates of what would actually happen, but will understand them to be rough indications. Lastly, there are good pre-existing scaling models available for use, whereas detailed weather models are generally harder to get ahold of, and the prospects of them working quickly even in modern web browsers is not as clear. (If someone has a more complicated model that they'd like to share with me, I'd love to hear from you.)
The Miller fallout model works by assuming that the fallout plume is a result of both the cloud and the stem. Basically the elongated shape of it is sort of like a mushroom cloud put on its slide and smeared out. Here is a Miller's drawing of the final shape of a 1 Mt yield surface burst at a wind speed of 15 mph and with 100% fission yield:
At first glance it doesn't look much like the fallout contours one might be used to, like this one of the Castle BRAVO detonation from 1954:
But part of that is because the ones people are used to have often been "cleaned up" and modified a bit to look better. This is another version of the BRAVO contours, created by the RAND Corp. from the same data, and you can see the resemblance to the Miller model in terms of the separation of stem and cloud fallout, leading to a large downwind "hot spot":
Separately, it is worth noting that real fallout evolves over time. The scaling models are known as H+1 models, which is to say that the fallout has been "normalized" to what it would look like after 1 hour, assuming that its maximum time to its final size was 1 hour. This is quite standard in the fallout literature, despite the fact that for large detonations, the arrival time is much longer than 1 hour. Here, for example, is the evolution of the BRAVO fallout plume over 18 hours:
So of what value is the H+1 hour model? It lines up not too poorly with the final total-dose contours for the fallout plume, and as such could be taken as an idealized understanding of what your average rad dose per hour would be downwind of the blast. It is meant, by Miller and by me, to give an indication of the rough size of the contaminated area after a nuclear explosion, which has both pedagogical and planning value, even if it is a little confusing in terms of the movement of the actual cloud.
If you want to translate the H+1 dose to a "dose on the ground," use the "Probe location" feature. It will let you select a point on the ground downwind of the cloud, and will give far more information, based on wind speed, time exposed, and potential shelter, on what the effects on the ground would be.
Note that this model is exclusively for modeling a surface burst, not an airburst. Airbursts do contribute to long-term fallout (e.g. the overall radioactivity in the atmosphere, or the amount of cesium-127 that eventually makes it into human diets at very, very long distances), but, by and large, contribute only negligibly to short-term local fallout. This appears to be the case even with very large yield airbursts that contain significant fission products. The line between an "airburst" and a "surface burst" in such a consideration is whether the fireball touches the ground, as this pulls up significant numbers of heavy particles (e.g. dirt, coral, buildings, people) into the rising fireball, and these heavy particles affect the "falling out" considerably. When the fireball does not touch the ground, the fireball appears to rise high enough and fast enough that the bulk of its fission products do not fallout until much later, when they have lost much of their radioactivity. (Radiation energy is inversely related to time— this is the import of "half-life" measurements. The more radioactively active a given isotope is, the quicker it reduces in quantity. This does not mean that all radioactive hazard dissipates quickly, but the nature of the hazard between short-lived, highly-energetic particles is different than long-lived, moderately-energetic particles. The former are an immediate, acute radiation hazard— e.g., they can give you radiation sickness and hurt you in a few hours or weeks —and the latter are a long-term, chronic radiation hazard — e.g., they can give you cancer and hurt you in several years or decades.)
- How does the casualties model work?
The casualties model queries a very large and very fine-grained ambient population database known as the LandScan Global Population 2011. The database was developed by Oak Ridge National Laboratory and is licensed through a company called EastView. Special thanks to the Center for the History of Physics at the American Institute of Physics for purchasing this database for my use. "Ambient population" here means a 24-hour average of people in an area. In many respects this is better than census information, because that usually just measures where people live, as opposed to where they go when they are not at home.
In short, a spatial query is run on database whenever casualties are requested. The database spits back information about how many people live within several radii of ground zero. This information is then used to generate a list of casualties and injuries, according to data contained in a 1973 report by the Defense Civil Preparedness Agency titled DCPA Attack Environment Manual, later reprinted in the 1979 Office of Technology Assessment report, The Effects of Nuclear War:
As you can see, it primarily relies on blast effects (pounds per square inch) as a proxy for calculating injuries and fatalities.
There are limitations to this model. For some yields, especially those which are very low or very high, blast effects are less important than thermal or radiation effects. The model itself also does not take into effect the fact that highly dense urban areas have a "shielding" effect from blast effects — those buildings nearest the ground zero bear most of the brunt of the blast. It's also not entirely clear what the OTA based these estimates on.
So the numbers might be too high. They also might be too low. Without taking into account many more variables than the model can deal with, like terrain type, building type, expected reaction of the bombed populace, and radioactive fallout, it's hard to do anything more than gesture at the numbers that would be affected by a nuclear explosion. I'm not trying to say "it's too complicated, so any model is as good as any other." But in choosing a model I went with one that could be relatively straightforwardly be implemented given the data I have available, and was backed by at least one serious source. So I thoroughly encourage you to take these numbers with a grain of salt — they give some indication of how many people live in reasonably close proximity to the selected ground zero.
I have seen some other official estimates of fatalities and injuries that put the numbers (especially of the injured) much higher than the estimates that are given by the casualty model here, and I have seen some other official estimates of blast effects that would put it lower depending on the building types. It's not my intention to over- or under-exaggerate the effects.
- How does the 'humanitarian impact' model work?
The "humanitarian impact" model works by using the Google Places API to search out tagged places near the ground zero location. (This is the same algorithm Google Maps uses whenever you ask how many restaurants are near where you happen to be.) Its accuracy is 100% tied to how good Google's information is. Which is to say... it's not perfect.
The point of the "humanitarian impact" model is to emphasize some of the collateral impacts of a nuclear explosion, and to indicate the ways in which support services (e.g. hospitals and fire stations) would be themselves impacted by a nuclear attack.
NOTE: The humanitarian impact model is temporarily disabled because of my switch from the Google platform. I may bring it back in the future.
- How does the mushroom cloud model work?
The mushroom cloud model dynamics come primarily from Carl F. Miller, "Fallout and Radiological Countermeasures, Volume 1," Stanford Research Institute Project No. IM-4021, January 1963. Miller was, in his day, considered one of the premier experts on modeling mushroom cloud behavior. Some of the information also comes from curve fitting various figures (in particular the rate of cloud rise) in Samuel Glasstone and Philip J. Dolan, The Effects of Nuclear Weapons, 1977 edn.
For the 3D-modeled (KMZ) cloud, given the limitations of Google Earth's API (you can move, rotate, and scale models but not otherwise manipulate them), I had to do a little bit of fudging to make things look right aesthetically. But many of the parameters, such as the rate of rise, the changing size of the cloud head, and the final size of the cloud, are taken directly from models derived from nuclear test data.
- Who has supported the work on the NUKEMAP?
The majority of all NUKEMAP programming and work was done by me (Alex Wellerstein). I sometimes get asked if I have a large staff for such things... don't I wish I did!
The Center for the History of Physics at the American Institute of Physics generously supported my initial creation of the NUKEMAP as part of my work as Associate Historian, from 2011-2014. They also paid for my license to the LandScan population density database.
The College of Arts and Letters at the Stevens Institute of Technology has generously supported my (ever-increasing) server and API fees associated with hosting the NUKEMAP. Some of these fees are supported by the research fund associated with my being the David & G.G. Farber Faculty Fellow in Science and Technology Studies.
Aspects of expanding the NUKEMAP's codebase have been supported by N Square and the Future of Life Institute. Bluecadet and Outrider collaborated with me for creating their NUKEMAP-derived Bomb Blast website.
If you are interested in supporting the NUKEMAP through a donation to the Stevens Institute of Technology, feel free to get in touch with me!
Over the years, several Stevens undergraduates have helped in working on aspects of expanding the NUKEMAP's model, notably Jeffrey A. Meli and Benjamin Blease.
- How can I contact you?
- Have more questions? Looking for a place to make a charitable, tax-deductable donation to support more work like this? Send any such queries to firstname.lastname@example.org and I'll try to get back to you ASAP. You can also tag me on Twitter.
This page was last updated in June 2019.