Ceci est une ancienne révision du document !
Python and Space Weather
Greetings again fellow Sentient Lifeforms. Things here at landing pad 2997 on Terra STILL mostly crazy. Trying to handle everything on my plate is somewhat like trying to juggle four chainsaws, and an orange, all at the same time. (A VERY nasty mental picture, I must admit.) I mean, I’m supposed to be at least SEMI retired, but I seem to be busier than I was when I had a full time (read 70+ hours a week) job, a young family, and other professional responsibilities. Oh well, as the Barenaked Ladies once said “I wax poetic as you're waxing your legs”. We’ll move on now to this month’s offering.
Here in Texas, we have a saying: “If you don’t like the weather, wait 10 minutes.” That’s because on any given day, the weather is so very volatile. Especially in the summertime. In order to make any plans for outside activities, things like walks, shopping, family trips, heck even walking the dog, can be impacted by the weather. Cold, hot, windy, rainy, foggy, muddy, clear… it all affects how we will spend our day or night.
So, yes, weather here on Terra is an important thing that we need to take into consideration before we make any decisions about what we will do today, tomorrow or even next week. There is another event that is very weather sensitive. That’s the launching of spacecraft to explore areas not on Terra, and even the return of said spacecraft. Yes, I’m talking about space, the great unknown, the ‘final frontier’.
Space doesn’t have rain or thunder or cold fronts or even seasonal changes, but it does have some interesting things like plasma temperatures and densities, solar wind speeds, and when you look at our star, the sun, there are Coronal Mass Ejections and solar flares and other things that can make our lives here on Terra interesting to say the least.
Many countries have created space programs that only monitor the space weather. NASA is one of them and that’s where we will concentrate our attention for this article.
To get started, take a look at https://api.nasa.gov/. This link will give you a list of 17 (as of September 5, 2024) different APIs that are available. Many of the APIs have “sub APIs” associated with them. For example, the DONKI API (Space Weather Database of Notifications, Knowledge, Information) has 11 different sub groups. These include things like Coronal Mass Ejection (CME), Geomagnetic Storms (GST), Solar Flares (FLR), and many more.
If you are interested in digging in, you should sign up for an API key at https://api.nasa.gov/#signUp. The API key is FREE, so really there’s no reason to not sign up for one, and the key is delivered in your email within a minute or two. However, if you want to just play before you commit, most of the API calls support an API key of “DEMO_KEY”. You are limited to 50 requests per IP addresses per day, and 30 requests per IP address per hour. So your free testing will be fairly limited.
Let’s look at some of the things that DONKI can provide.
In your favorite IDE, start a quick python project. Of course, we’ll need to import requests and json. Due to the amount of data that will come down, you’ll want to include pprint in your project as well. Set a variable named mykey to “DEMO_KEY”, then create a formatted string to the API url that you want to use. In this case “https://api.nasa.gov/DONKI/CME?api_key=DEMO_KEY”.
You can narrow the amount of data that comes down by including a startDate and endDate in the format YYYY-MM-DD, but if you want to just get a gross overview of what the call will return, leaving out the startDate will default to 30 days prior to the current UTC date, and the endDate will default to the current UTC date.
Here’s (top right) what the api call would look like, including the startDate and endDate parameters… https://api.nasa.gov/DONKI/CME?startDate=2024-09-01&endDate=2024-09-30&api_key={mykey}
Please note, by leaving out the startDate and/or endDate could lead to way more data items than you might want to start with. So use that type of call for when you really need it.
From here, you can query the info variable to get the fields you want.
I did this very early in the morning on Saturday, September the 7th, and it returned 129 data records with each record containing 12 items, and some of those items were dictionaries themselves.
So anyway, in order to get a very gross overview of the data, I decided to query the json response for just the dictionary keys. Here’s what was returned…
dict_keys(['activityID', 'catalog', 'startTime', 'instruments', 'sourceLocation', 'activeRegionNum', 'note', 'submissionTime', 'versionId', 'link', 'cmeAnalyses', 'linkedEvents'])
I then wanted to see what just one record would look like. So I had it dump to the terminal via pprint. I broke the data dump into smaller pieces to make it easier to understand. Some of the data items don’t mean anything to me yet.
{'activeRegionNum': None,
'activityID': '2024-08-08T04:48:00-CME-001',
'catalog': 'M2M_CATALOG',
For me, the important data item in this small group is the activityID. This contains the date and time of the incident in the id number.
Now for the second dictionary item in our json data. The cmeAnalyses field (below): You can see that there are many items that don’t quite compute to me, but there are two items that stand out pretty well right at first glance. Mainly the note field and the link field. If I was really interested in this event, I’d pull that link up. Remember, this is the analysis of the event, so it will be fairly specific.
Now we are back at the “general” data, and here we see that there were two devices that were used to look at this event as well as another link, this time a more general web page that will show any related (top right).
The note field is usually one of the most important to me, so I can decide to dive deeper into this report or not.
'note': 'Faint CME first seen in the NW by SOHO LASCO C2 beginning at '
'2024-08-08T04:48Z as well as in later frames by STEREO A COR2. This '
'event is not clearly visible in SOHO LASCO C3 as it may be too faint '
'or obscured by the pylon. Possible source is wider field line '
'opening seen beyond the NW limb in SDO AIA 171 and GOES SUVI 284',
Finally the last batch of data fields. Here, the startTime and submissionTime fields are something I would normally look at.
'sourceLocation': '', 'startTime': '2024-08-08T04:48Z', 'submissionTime': '2024-08-08T13:06Z', 'versionId': 1}
All that having been said, the cmeAnalyses dictionary can contain multiple entries. A very good example of this occurred on May 11 of this year (2024, just in case you read this sometime in the future). I used the same methodology to get a data dump for that day again using DONKI.
url1 = f“https://api.nasa.gov/DONKI/CME?startDate={startDate}&endDate={endDate}&api_key={mykey}”
Then, once I got the data, I saved the data to a local pickle file, so I didn’t have to keep making the call. There were 5 events reported that day. I dug into the json data and near the end of the first report was a link to https://webtools.ccmc.gsfc.nasa.gov/DONKI/view/CME/30719/1, which is a very clear (well sort of) description of the actual event, including other links.
Higher up in the json data for the first report, I found another link which led me to https://webtools.ccmc.gsfc.nasa.gov/DONKI/view/WSA-ENLIL/30726/-1. This site, at the bottom, showed a number of animated .gif files. The first “Inner Planets Link” shows a rather large CME flying off the Sun https://iswa.gsfc.nasa.gov/downloads/20240511_032400_2.0_anim.tim-den.gif.
That big dark purple (to my eyes) is the CME headed for that tiny yellow dot which represents Earth. Since the image is a GIF, I didn’t try to capture it just as it hits, but you can visit the above link to watch it yourself.