A Great Start to GSoC with SunPy

Hello, everyone! My name is Manit Singh, and I’m thrilled to share my journey as a participant in Google Summer of Code (GSoC) with SunPy. Getting selected for this prestigious program has been a significant milestone in my career, and I am excited to contribute to the Enhancing SOAR Metadata project.

Community Bonding Period

Introduction to the Community Bonding Period

The community bonding period was an essential phase where I got to know my mentors, understand the project’s goals in-depth, and prepare for the coding period.

Meetings and Discussions

During this period, I had several meetings and discussions with my mentors and community members. These interactions were crucial for:

  • Understanding the Project Goals: The project aims to increase the scope of SOAR data in sunpy-soar.
  • Clarifying Initial Approaches: My initial approach was to implement wavelength and detector first, and then discuss the implementation of the next set of metadata.

From these initial discussions, we concluded that the Detector should be implemented first, after creating methods to support the joining of instrument and data tables (i.e., v_<instrument>_<ll/sc>_fits and v_<ll/sc>_data_item).

First Coding Week: Implementing the Detector in the SOAR Project

Objectives

The primary objective for the first week was to add methods to support querying data involving instrument and data tables both and implement the detector component in the SOAR project. Although the detector is part of the SOAR product, my mentors suggested that there are many people who might still want to query over the detector.

Implementation Details

As discussed in the meetings held during the community bonding period, I worked on constructing methods to enable joining two different tables. Initially, it all looked very messy, but with time and refactoring, a quite simple join constructing method was created.

  • Implementing Detector: Similar to how other metadata in the sunpy.net attribute system was implemented, I implemented the Detector. The only major difference was taking data from two tables and joining them.
  • Testing: I added tests to ensure that the construct method designed for joining tables could give the desired query outputs and that the detector was working fine for instruments with multiple dimensional data. (which depends on the dimensional index).

Challenges and Solutions

Different Dimension Index for instruments:

Instruments collect a wide variety of data types that can be multidimensional. For example, for SPICE, there are 4 dimensions, resulting in 4 similar rows of data, one for each dimension. This could be confusing for the user unless the dimension index is also shown in a column. For the STIX instrument, there are 0 dimensions, meaning it does not have any detector column in its instrument fits table. For other remote sensing instruments, there are 2 dimensions.

Solution:

# As there are no dimensions in STIX, the dimension index need not be included in the query for STIX.
if "stx" not in instrument_table:
# To avoid duplicate rows in the output table, the dimension index is set to 1.
final_query += "h2.dimension_index='1'+AND+"

In the construct methods of the ADQL query I added dimension_index to be taken 1 by default for all instruments other than STIX, this results in no repetition of data.
For STIX instrument, since there are no dimension it just works simply okay without taking any dimension in the join query constructed after construct methods

Outcomes

code:

instrument = a.Instrument("METIS")
time = a.Time("2022-06-02 0:00","2022-06-02 1:00")
level = a.Level(2)
detector=a.Detector("VLD")

By the end of the first week, the detector component was successfully implemented in sunpy-soar. The pull request is currently awaiting review from all the mentors to ensure any discrepancies in the implementation are addressed and to gather additional insights. :)

Conclusion

The journey so far has been incredibly enriching. The support from my mentors and the community has been invaluable. I am looking forward to the upcoming weeks and continuing to contribute to the SOAR project.