Week 2: Plotting and Stacking – Time for Data Visualization

Mason t -

This week I want to show the actual light curves of the meteors and a bit more about how the stacking part of the project actually works.

I wrote a function in my code that allows me to graph the light curve data of a meteor detection. This allows me to better visualize the code I’m looking at, and means I can show some of them in this blog post to all of you. There are still some errors here, such as the x-axis time (which is in seconds.milliseconds) having a bunch of tailing zeroes, but this plot shows the basic information that I need for simple analysis. The magnitude is on the y-axis, and is inverted because smaller magnitude = brighter. The x-axis shows time, and that comes out to a plot showing the magnitude of a meteor over a certain period of time. There is also a label system showing which camera contributed to which curve, which is shown on the upper right – in this case it’s camera USL008.

Light curve example

But we need to be able to look at more than just a single curve at a time. I wrote another function that allows me to call a dictionary (remember from the last post that each dictionary contains many names of detections each linked with a block of meteor light curve data) and ask it to make a light curve for each detection in the dictionary. For now I am manually placing each detection into a dictionary of other detections of the same object. For example, in the graph below, cameras USL008, USL00G, and USL00M all captured a meteor on 05/31/2022 at 8:49 and 40 seconds. I can graph all of these detections on the same curve instead of separately, and since it’s all the same meteor being detected, the graphs should look pretty similar, as seen below.

Stacked curves example

Now I can actually do analysis on this group of curves, figuring out what features are noise and which ones are actually spikes in the light curve will be one of the first things I’ll do.

Sometimes, small bugs in the code get blown out of proportion as the project grows more and more, and big issues later on can be tracked back to tiny errors earlier in the code. For example, when I was working on the stacking curves section of the code, I ran into an issue where the curves would not line up on the x-axis. This should be impossible because the cameras are constantly being recalibrated since time is one of the most important factors in analyzing light curves. It ended up being a small bug earlier in the code where I forgot to factor in milliseconds into the code that calculated where the light curve goes on the x-axis. This tiny miscalculation led to a big issue later on, which is why its important to always iron out each part of the code before moving on.

On a side note – here is where I’ve been working up at Lowell. So even if I encounter bugs I have a nice place to work on fixing them.

workplace

More Posts

Comments:

All viewpoints are welcome but profane, threatening, disrespectful, or harassing comments will not be tolerated and are subject to moderation up to, and including, full deletion.

    Corey Hartman
    Hi Mason! Great post. What is the best way to iron out each part of the code before moving on? Is it with visualization? And how often do you typically check your work?
    March 5, 2025 at 2:59 pm - Reply
      mason_t
      Hi Ms. Hartman! Ironing out code is sometimes a bit difficult because it's hard to always predict what kind of issues might come up later on. However, doing things like commenting my code (writing in notes so that I can look back on it later and quickly understand what each section is doing), writing easy-to understand variable names, and making sure the code is doing exactly what it should by manually feeding in simple data that I know what the output will look like (which is also how I check my work) are some methods of good practice I can use to stay organized.
      March 17, 2025 at 11:04 am - Reply
    samantha_g
    I did not remember that about dictionaries, thanks for the reminder! For the three cameras that captured a meteor on 05/31/2022 at 8:49 and 40 seconds (the specificity is nice, I like it Picasso) do you know the differences between them in how they capture these meteors? You have your own office space at Lowell, fancy! Thanks!
    March 9, 2025 at 2:00 am - Reply
      mason_t
      I actually haven't worked too much with the physical cameras themselves, just with the data that they capture. I talked to my mentor today about it, and he told me that the Lowell network uses the same type of camera. They're small - not too different from the ones in our phones!
      March 17, 2025 at 2:09 pm - Reply
    mae_b
    This is cool stuff! Your meteor-stacked graphs look very impressive. Around how long has it taken you so far to code this program? I expect a long, long time...it looks pretty sophisticated (to my totally untrained eye).
    March 10, 2025 at 7:09 am - Reply
      mason_t
      Good question... I wish the coding app I am using could tell me how long I have been working on this particular file, I do have around 650 lines of code now though. Sometimes I can code a bunch of lines quickly, and sometimes it takes me five minutes to get through one, it mostly depends on what I'm trying to write.
      March 17, 2025 at 2:18 pm - Reply
    maleea_m
    Your office looks so sophisticated, the chalkboard, the wooden educational feel, and the laptop. It gives me Good Will Hunting Vibes for some reason, a super genius pupil. With 650 lines of code (congrats by the way) how do you go about finding and correcting bugs? Sounds maddening!
    March 19, 2025 at 10:17 am - Reply
    eugene_j
    Hey Mason! It's amazing how visualizing the data makes it already much clearer, even with only a few meteors. That place at Lowell looks like a great place to work. How often are you at Lowell, and how are you accessing the meteor data?
    April 18, 2025 at 11:06 pm - Reply

Leave a Reply to mason_t Cancel reply

Your email address will not be published. Required fields are marked *