GSOC start here!

[fjebaker]

Welcome! Thanks for your interest in contributing to our GSOC 2026 project Spectra.jl across the electromagnetic spectrum.

Useful links:

• The OA GSOC project description.
• The GSOC 2026 timeline.

Getting started

Although the GSOC period has not yet started (the application period ends on the 31st of March, with the projects properly starting in the summer), you are welcome to start to get to know Spectra.jl

To do this, you'll need Julia installed on your machine. Start Julia in a terminal (by typing julia). This is the Read, Eval(uate), Print, Loop interface, or REPL. It is the interactive prompt for using the Julia programming language.

Hit the ] key to enter the package manager mode (use Ctrl-C to get out of it). Start by updating your environment

pkg> up

Then fetch Spectra.jl in development mode

pkg> dev Spectra

This will clone the repository to your $HOME/.julia/dev/ directory. If you edit the source code, Julia will now also fetch the changes, allowing you to play around as you will!

As a tip, consider using something like Revise.jl to automatically reload changes without having to restart the Julia REPL.

Follow the Quick start demonstration in the documentation to get a feel for how to use Spectra.jl.

The project

Please do not start opening PRs addressing this until you have been selected for the project in ~ April.

Our main aim is to flesh out the data loading routines in Spectra.jl to work with spectra from different wavelengths. We'll start with X-ray spectra, as these have a non-trivial format and require instrument response files to be correctly interpreted. Such a data loader has already been mostly implemented in SpectralFitting.jl, and the first task is to move that part of the codebase over to Spectra.jl. It then needs to be integrated with the various spectral types that Spectra.jl defines, so that the interface for using the data is homogenous, and tests writen to ensure the functionality is as expected.

After that, we'll focus on another wavelength or even theoretical spectra (that bits up to you -- whatever takes your fancy!) and the mentors will guide you in putting a brand new data loader implementation together. Utility functions for often-performed reductions should also be implemented, such as the different flux unit conversions, data rebinning, metadata interpretation, and so on.

In the meantime

There are some things you can do in the meantime if you are really keen to work with us on this project:

• Familiarly with Julia is key. A simple web-search will reveal many good tutorials for how you can learn the basics, the type system, and how to structure larger programs.

• You'll be working with the data files produced by various ground-based and space-based telescopes in this project. That often means pouring over some technical descriptions, such as the OGIP data format. Some practice at reading such documentations would be good to have.

---

If you have any problems, questions, or queries, feel free to reach out to the mentors of the Spectra.jl project! You can find their contact details on the OpenAstronomy website.

[Akshat1000Sharma]

Hello everyone,

My name is Akshat, and I am interested in contributing to Spectra.jl for GSoC 2026. I have a background in programming and data-focused projects, and I have been working with Julia in scientific computing contexts.
Over the part few days, I have set up the development environment, reviewed the codebase, and gone through the current open issues to understand the project structure and direction.
I submitted a PR #46 for issue #28. I would appreciate it if you could review it when convenient. Any feedback or suggestions for improvement would be helpful.

Thank you.

[fjebaker]

Hello @Akshat1000Sharma thanks for your interest and for the PR! Apologies, it may take me a few days to review this in appropriate detail, but glancing at your work so far looks good.

[Mahmoudmoh-cse]

Hi, I'm Mahmoud, a CS student from Egypt. I'm planning to apply for this GSoC project. I've been reading through the codebase and the related issues. I'll be working on issue #45 as my first contribution.

[jamesrafe]

Hi everyone and @fjebaker ,
I'm James R Lee, a software engineer from Indonesia. I'm excited to be applying for Spectra.jl in GSoC 2026. I have just uploaded a draft of my proposal to the OpenAstronomy gsoc-proposal repository. If the mentors are available and have the time, I would really appreciate any feedback.
Thank you in advance!

[aryawadhwa]

Hi everyone! My name is Arya Wadhwa and I am a first year GSoC applicant submitting a proposal for the Spectra.jl project.

I want to be upfront. This is my first time applying to GSoC and I was not aware of how important it is to reach out to mentors before the deadline. I only discovered this issue a day before submissions close and I genuinely wish I had found it sooner. I apologize for the late introduction.

That said, I did not want to submit a proposal without actually looking at the code. So I spent the last several hours reading through the codebase carefully. I documented everything I found in an exploration_notes.md in my fork: https://github.com/aryawadhwa/Spectra.jl

Based on that reading, I took a first pass at two things I noticed were missing:

spectrum_binned.jl — a concrete implementation of BinnedSpectrum, which is a TODO in the main module. Since OGIP X ray PHA files define spectra using energy bin edges rather than center points, this seemed like the correct foundational type before any OGIP loader can be written.

src/io/fits_loader.jl — a prototype Spectra.load() API with automatic format detection, a working 1D optical FITS loader, and a stub OGIP PHA reader that correctly identifies the SPECTRUM HDU extension and reads CHANNEL and COUNTS columns.

I also wrote a TDD test suite in test/test_binned_spectrum.jl covering construction validation, bin_centers, bin_widths, count_rate, and error handling.

I have one technical question I genuinely do not know the answer to: should BinnedSpectrum be the canonical target type for OGIP ingested data, or should the existing SingleSpectrum be extended to accommodate bin edge spectral axes?

I understand if being late to the conversation affects how my proposal is received. But I wanted to show genuine effort rather than submitting a generic application. Thank you for taking the time to read this.