Weeks 9 & 10: Slicing, Profiles and a New Factory

-

 Slicing, Profiles and a New Factory 🚀

The last two weeks have been a pretty interesting mix of working on spectrogram slicing and starting to look at one of the bigger architectural changes in radiospectra.

A lot of the work this time was about understanding how the different pieces fit together and figuring out how to make things easier for users and contributors.

Exploring Slicing and Profiles 🔍

After the ndcube refactor, I started looking more closely at how users could work with individual parts of a spectrogram.

One thing I wanted to make easier was getting a time profile at a particular frequency or a frequency profile at a particular time.

Initially, I worked on adding time_profile() and line_profile() methods to GenericSpectrogram.

To make this work, I had to deal with something I hadn't worked with much before—converting physical coordinates into the actual array indices behind the spectrogram.

I added a couple of internal helpers to handle this conversion, so users could provide things like an astropy.time.Time or a frequency with units without having to figure out the corresponding array index themselves.

I also added tests to make sure these conversions work correctly across different cases.

This was a nice learning experience for me because it made me look much more closely at how the WCS and the actual data array are connected.

Starting the SpectrogramFactory Migration 🔧

The other major thing I've been working on is the SpectrogramFactory migration.

This is definitely one of the bigger changes I've worked on so far.

The existing factory would basically parse the entire file first and create the data and metadata before checking which instrument the file belonged to.

That means quite a lot of work could happen before we even knew which instrument was supposed to handle the file.

The idea behind the new approach is to keep this much lighter.

Instead of fully parsing the file first, the factory can get the basic information needed to identify the instrument. Once the correct instrument is found, that instrument can handle the actual parsing through a new from_raw() method.

So the basic idea becomes:

Old:

Read everything → Identify instrument → Create spectrogram

New:

Read basic information → Identify instrument → Let the instrument parse the data

I've started implementing this approach and have migrated the first two sources:

  • WAVES
  • e-CALLISTO

There's still a lot to migrate, but getting these two working has given me a much better idea of how the rest of the factory can be moved over.

What's Next? 👀

For the next couple of weeks, I'll be working through the feedback on the slicing and profiling work and continuing the SpectrogramFactory migration.

There are still several instruments to move to the new from_raw() pattern, so I'm looking forward to seeing how the factory looks once the migration is complete.

It's been really interesting moving from smaller API improvements to working on the bigger architecture of radiospectra, and I'm excited to keep going!

Until next time! 🚀

Comments

Post a Comment

Popular posts from this blog

GSoC 2026 – Weeks 3 & 4: Looking Beyond the Code

-
Image
Understanding the Infrastructure 🔧 The past two weeks have been quite different from the start of the coding period. Instead of spending most of my time implementing new functionality, I found myself exploring a part of open source development that I had very little experience with before: testing infrastructure, CI workflows and release tooling. One thing I've learned so far is that writing code is only part of maintaining a project. Making sure that code continues to work months or years later is an equally important challenge. Bringing Figure Tests to Radiospectra 📊 The main focus of the last two weeks was introducing the initial figure testing infrastructure to radiospectra. Before this, I had never worked with figure tests. My understanding of testing was mostly limited to checking outputs and functionality. Testing plots turned out to be a completely different world. To understand how it worked, I spent time exploring the figure testing workflow used across the SunPy e...
Read more

GSoC 2026 - My Journey to SunPy Under OpenAstronomy

-
My GSoC Journey I’m incredibly excited to share that I’ve been selected for Google Summer of Code 2026  under OpenAstronomy for the SunPy project:  Improving radiospectra’s Functionality and Interoperability. This has been one of the most emotional and memorable journeys of my life so far. Getting Started with Open Source A few months ago, I started exploring open source and eventually came across the SunPy ecosystem and the radiospectra repository. What initially began as curiosity slowly turned into genuine interest as I started understanding the codebase, participating in discussions, attending weekly meetings and contributing through pull requests and issues. As I spent more time with the project, I became increasingly interested in the architectural discussions around scientific software, interoperability, plotting systems and coordinate-aware APIs. Over time, the project became much more than just a GSoC application for me. The Rejection 😢 On 30th April, when the...
Read more

GSoC 2026 - Weeks 1 & 2: Understanding Before Implementing

-
The Journey Begins 💪 The first two weeks of the coding period have been a mixture of excitement, confusion, debugging, learning and the occasional moment of staring at a terminal wondering why something that worked five minutes ago suddenly doesn't. As someone once said: "The expert in anything was once a beginner who refused to give up." That quote has felt surprisingly relevant over the past couple of weeks. Building the Foundation with NDCube 💻 A major part of my work focused on integrating radiospectra with NDCube. This involved migrating the core GenericSpectrogram  class, understanding how coordinate-aware data is represented and diving deeper into World Coordinate Systems (WCS) than I ever expected. At first glance it sounded simple: "just integrate NDCube." It was not. Along the way, I had to understand how time and frequency coordinates interact, how plotting components work and spend a fair amount of time convincing Git that my branches and commits w...
Read more