1. glue PR #2167 for updating 1D Profile viewer to use wcsaxes for plotting and add sliders (open / commit: da82536)
2. glue PR #2161 for updating ‘wcs_autolinking’ code to handle N-D cases using a generalised approach conforming to APE 14: Shared Python interface for World Coordinate Systems (merged / commit: 222d31e)
3. glue PR #2164 for adding support to NDData for astropy package (open / commit: 0b089d7)
4. glue PR #2131 for adding a preferred_cmap attribute to introduce a color coding scheme for different glue-solar data types (for example to distinguish the IRIS raster data cubes from its companion IRIS SJI data cubes (merged / commit: 381fe75)
5. glue-solar PR #15 for adding to open with “SunPy Map” GUI option (merged / commit: 91c5b6a)
6. glue-solar PR #17 for adding “Loading and Overplotting AIA and HMI files as SunPy Maps” docs as a user guide (merged / commit: de7be62)
7. glue-solar PR #18 for adding “loading IRIS level 2 raster and sji data together docs” as a user guide (merged / commit: fa416f4)
8. glue-solar PR #23 for updating IRIS data labels with OBSIDs for filtering (merged / commit: 0d1a17f)
9. glue-solar PR #28, PR #29 as core glue-solar documentation (merged / commits: b9b6e21 & d706912)
10. glue-solar PR #32 for patching a TypeError bug in the glue-solar plugin that was not caught in CI tests before, added a unit test in the process. (merged / commit: f3f7aae)
11. glue-solar PR #33 for adding data loader customization guide as developer docs (merged / commit: 1973d24)

As a personal bonus, I have actually started using our work on the glue 1D profile tool for my current doctoral studies on some studies of planetary nebulae applying integral field spectroscopy (IFS), which involves the handling of a large number of data cubes from some Australian telescopes (data collected by my PhD supervisor Prof. Quentin Parker). Turned out this tool made the process of investigating the different spectra, which could run up to hundreds in number per data cube or observation, as it allows me to load in my data cube only once, and then to inspect the variation across spatial dimensions to see if the signal-to-noise of a particular observation is too high, or if the opposite is true so that the spectra will then be further processed into full-optical integrated spectra with flux calibration or de-reddening as necessary.

I am grateful for Google, my mentors, other org members as well as my GSoC peers to make this a particular fun-filled and memorable project! I have learned so much from the experience that even money cannot buy in terms of programming and soft skills. I wish Google will continue this program or initiate some similar program to continue cultivating new generations of open-source software developers / development enthusiasts to further our aim to make open-source approachable and usable for all.

It is my hope that I will be able to continue my contributions to both glue and glue-solar even after this year’s GSoC is over.

We have finally resumed code reviews for the remaining PRs in the glue repo, and I am happy to report that the PR dealing with adding a preferred_cmap attribute to the visual module of glue/core has been merged four days ago from today. This is a very memorable milestone as this is my first contribution to the glue codebase. The remaining PRs which are being worked on include the 1D Profile PR (PR #2156) as well as the wcs auto-linking PR (PR #2161).

Regarding our work at the glue-solar repo, all of the PRs reviewed except the two experimental ones has been merged. A User’s Guide and a Developer’s Guide have been added to the docs, while there is one open WIP PR which I am working on to add both a contributing document and the code references (or API) for the repo. Also some docs introducing users on how to start their own extensions in glue-solar for conducting solar physics has been planned.

All of the above will form the bulk of work to be submitted for the GSoC project.

More can be done for glue-solar, including but not limited to the following:

1. Add NDData support to glue via glue-solar
2. Add instrument loader code from sunkit-instruments to glue-solar
3. Enable image / Movie exports, both with axes and without axes via matplotlib
4. Add support for pre-computed statistics in datasets / viewers.

Hopefully with the support of the mentors much of what has been planned can be brought to fruition, so that this project will be a successful one.

The first and foremost concern we should have regarding any type of unit testing is what we should check for functionality-wise. Let me take some code I have just written over the past few days which adds NDData (a data structure native to Astropy) support to glue and enables the loading of various types of astronomical data more readily, such as the standard FITS files. As I have discussed with my mentors via the glue-solar IRC channel, we have observed that NDData is much like laser was back in the 1960’s (e.g. as reported by NYTimes then) was a solution in search of a problem before its wider adoption by the astronomy community for LSST, DKIST and CCDProc data. Now we are in the process of integrating it into glue. The original conception of this, at least in principle, is to use the simple and fluid structure of NDData to help process for example FITS data. This is because there are no generic NDData files in existence at all. This is to facilitate the manipulation of not only the data component, but also its units, mask, uncertainty, and meta attributes, which are quite common in the handling of astronomical data (pun intended). With such a motivation in mind, we have added a nddata.py module to the glue/core/data_factories directory in a PR at glue. To complete the PR, it is standard practice to add tests where applicable, so we have added a testing module called test_nddata.py in the glue/core/data_factories/tests directory to not only serve as a routine, but also to test whether the code has been properly debugged, which caught all of the major known bugs I have inadvertently introduced to the codebase before testing.

The GUI unit test I have written is as follows:

I have studied the other tests in the same glue/core/data_factories/tests carefully before I proceed to write the code, as I have observed that the most basic test to write is to test the data loader. Of course, official docs helped me greatly as well. As for the formatted NDData factory, that would be hard to test. I will need to consult with my mentors, before deciding on whether a separate unit test for that later.

One takeaway I have come away with in the process is that sufficient time is needed before I could brainstorm and come up with a tangible plan to write unit tests for any established codebase, and that I should not rush through the process. This is a lesson that I will definitely keep in mind. There is no use going through the motion and not enjoying the process as I go along, not to mention the omissions that I would make otherwise without a well thought-out plan.

Problem statement: Originally the wcs-autolinking only worked for some cases, for example for the spatial axes but not for the temporal and wavelength axes in the scenario where the dimensions of the two wcs objects of the data cubes being matched up do not match. This is highly undesirable and needs generalizing while conforming to APE 14, where the issue of a shared Python interface for World Coordinate Systems is discussed.

The solution: So we rewrote the code. Most of the celestial code has been retained, with some new additions to add linking for the other dimensions. The code rewritten is as follows:

# Case for when the axes don't exactly match up
if not forwards or not backwards:

    # A generalized APE 14-compatible way
    # Handle also the extra-spatial axes such as those of the time and wavelength dimensions

    if not wcs1.has_celestial or not wcs2.has_celestial:
        raise IncompatibleWCS("Can't create WCS link between {0} and {1}".format(data1.label, data2.label))

    try:
        wcs1_celestial = wcs1.celestial
        wcs2_celestial = wcs2.celestial
        wcs1_celestial_axis_physical_types = wcs1.celestial.world_axis_physical_types
        wcs2_celestial_axis_physical_types = wcs2.celestial.world_axis_physical_types
        print('wcs1.celestial.world_axis_physical_types', wcs1_celestial_axis_physical_types)
        print('wcs2.celestial.world_axis_physical_types', wcs2_celestial_axis_physical_types)
    except Exception:
        raise IncompatibleWCS("Can't create WCS link between {0} and {1}".format(data1.label, data2.label))

    cids1 = data1.pixel_component_ids
    cids1_celestial = [cids1[wcs1.wcs.naxis - wcs1.wcs.lng - 1],
                       cids1[wcs1.wcs.naxis - wcs1.wcs.lat - 1]]
    slicing_axes_celestial1 = [cids1_celestial[0].axis, cids1_celestial[1].axis]
    slicing_axes_celestial1 = sorted(slicing_axes_celestial1, key=str, reverse=False)
    print('slicing_axes_celestial1', slicing_axes_celestial1)

    if wcs1_celestial.wcs.lng > wcs1_celestial.wcs.lat:
        cids1_celestial = cids1_celestial[::-1]

    cids2 = data2.pixel_component_ids
    cids2_celestial = [cids2[wcs2.wcs.naxis - wcs2.wcs.lng - 1],
                       cids2[wcs2.wcs.naxis - wcs2.wcs.lat - 1]]
    slicing_axes_celestial2 = [cids2_celestial[0].axis, cids2_celestial[1].axis]
    slicing_axes_celestial2 = sorted(slicing_axes_celestial2, key=str, reverse=False)
    print('slicing_axes_celestial2', slicing_axes_celestial2)

    if wcs2_celestial.wcs.lng > wcs2_celestial.wcs.lat:
        cids2_celestial = cids2_celestial[::-1]

    # Collect all apparently matching axes in two lists for the two wcs objects being linked up
    wcs1_sliced_physical_types = wcs1_celestial_axis_physical_types
    slicing_axes1 = slicing_axes_celestial1
    wcs2_sliced_physical_types = wcs2_celestial_axis_physical_types
    slicing_axes2 = slicing_axes_celestial2
    for i, physical_type1 in enumerate(wcs1.world_axis_physical_types):
        for j, physical_type2 in enumerate(wcs2.world_axis_physical_types):
            if physical_type1 == physical_type2:
                if physical_type1 not in wcs1_sliced_physical_types:
                    slicing_axes1.append(wcs1.world_n_dim - i - 1)
                    wcs1_sliced_physical_types.append(physical_type1)
                if physical_type2 not in wcs2_sliced_physical_types:
                    slicing_axes2.append(wcs2.world_n_dim - j - 1)
                    wcs2_sliced_physical_types.append(physical_type2)

    slicing_axes1 = sorted(slicing_axes1, key=str, reverse=True)
    slicing_axes2 = sorted(slicing_axes2, key=str, reverse=True)

    print('slicing_axes1', slicing_axes1)
    print('slicing_axes2', slicing_axes2)

    print('wcs1_sliced_physical_types', wcs1_sliced_physical_types)
    print('wcs2_sliced_physical_types', wcs2_sliced_physical_types)

    # Generate slices for the wcs slicing
    slices1 = (slice(None),) * wcs1.world_n_dim
    slices2 = (slice(None),) * wcs2.world_n_dim

    slices1 = sorted(list(slices1))
    slices2 = sorted(list(slices2))

    for i in range(wcs1.world_n_dim):
        if i in slicing_axes1:
            pass
        else:
            slices1[i] = 0

    for i in range(wcs2.world_n_dim):
        if i in slicing_axes2:
            pass
        else:
            slices2[i] = 0

    wcs1_sliced = wcs1[tuple(slices1)]
    wcs2_sliced = wcs2[tuple(slices2)]

    cids1 = data1.pixel_component_ids
    cids1_sliced = [cids1[x] for x in slicing_axes1]
    cids1_sliced = sorted(cids1_sliced, key=str, reverse=True)

    cids2 = data2.pixel_component_ids
    cids2_sliced = [cids2[x] for x in slicing_axes2]
    cids2_sliced = sorted(cids2_sliced, key=str, reverse=True)

    pixel_cids1, pixel_cids2, forwards, backwards = get_cids_and_functions(
        wcs1_sliced, wcs2_sliced, cids1_sliced, cids2_sliced)

    self._physical_types_1 = wcs1_sliced_physical_types
    self._physical_types_2 = wcs2_sliced_physical_types

    if pixel_cids1 is None:
        raise IncompatibleWCS("Can't create WCS link between {0} and {1}".format(data1.label, data2.label))

After checking with the tests written previously the code was modified before it is confirmed with pytest that all CI tests are now passing.

Now we can link up wcs axes of the same physical types of two data cubes having different dimensions with no problems, illustrated as follows:

Part 1: Personal struggles

One personal “secret” I wish to reveal is that this is my last year as a PhD Candidate in Astrophysics at the University of Hong Kong (HKU). Not only that, since my Postgraduate Scholarship officially ran out in October 2019 and no other funding options are available, I have been holding down a job as a front-end developer for some parts of the weekdays to support my PhD studies. So far I have been trying to manage my time wisely and balancing my various duties and obligations as best as possible, but it has been a genuine struggle, especially in me trying to find enough time to sleep. To make matters worse I have a tendency to drift towards writing code than writing my thesis, though I am making progress in both. So I did hesitated to apply for GSoC for a 2nd time this year and was originally against the idea. But when I saw the project ideas available I changed my mind. Glue-solar is actually like a godsend for me; the project enabled me to not only further develop my self-discipline as a person, it also allowed me to learn from experts in the field working on open-source data visualization, and to grow from the experience. I thoroughly enjoyed interacted with my mentors, who have been very patient and helpful in offering me guidance (as well as friendship) throughout. If I have any advice I am allowed to offer anyone wanting to try out open-source software development through GSoC, and if GSoC does continue in the near future, I would recommend them to try out any of the OpenAstronomy projects. This is because OpenAstronomy is one (relatively) small but vibrant community of dedicated programmers, many of which scientists, that is welcoming to newcomers coming from a diverse background. And also, simply put, ASTRONOMY IS FUN! This is especially true for SunPy. I remember I started to contribute to open-source software as a relative novice with some bookish knowledge but not a lot of real-world experience back in around January 2019. My first contributions were to SunPy and Astropy. I remember I have read an article about how to get into GSoC in 2018 to learn about the program, though was not all that keen in getting into it at first. My first motivation to contribute was to give back to the community, because I had been using Python-based astronomy packages like Astropy for my PhD research. But at the urge of a mentor active in the Astropy community, I did apply. The GSoC project I worked on last year in 2019 was IRISpy, and my mentors were Dan Ryan and Laura Hayes. They were amazing as mentors, and were instrumental in my being able to complete the project successfully in the end of the program. I still miss my time spent with them on that project. IRISpy has officially changed its name to sunraster, which I was fortunate enough to help launch earlier this year in 2020. Basically when I was working on it as a GSoC project it was to provide additional functionalities for the analysis of observations from NASA’s Interface Region Imaging Spectrograph (IRIS) satellite which looks at UV emission from the solar chromosphere in particular. Now that scope has been extended to not just IRIS data, but data collected with similar instruments. This year I am using a lot of the code I have written for the IRISpy project for the current glue-solar project, which is kind of cool. As an icing to the cake, I get to work on data cubes for glue-solar, which is one of my favorite things in this world, a passion I have gained through my PhD research into integral field spectroscopy (IFS). For the present GSoC work I even get to work on 4D data cubes (ones with an extra time dimension), which has one more dimension than the IFS cubes I am so familiar with! So far it has been another incredible GSoC experience for me. All in all I have a feeling it will be a good one, and also a fruitful one.

Part 2: Technical aspect of progress made in glue-solar

So we (me and my mentors) have ventured away from focusing on glue-solar and have entered the glue “proper” territory as we put more time and effort towards modifying the 1D Profile viewer. By this I mean we have begun work on glue instead of glue-solar as was the case as described in my previous article where we have built a “SunPy Map” viewer. So I am well on my way to complete the task “modifying the existing glue 1D Profile viewer to provide sliders for extra dimensions (currently collapses)” soon, which is a significant part of the glue-solar project. Personally, I am really looking forward to working on the “adding support for pre-computed statistics in datasets / viewers” task, which I will surely make time to complete before end of August.

Let me demonstrate how far we have come with the modification of the 1D Profile viewer. So ordinarily it is hard to get 4D data cubes with a time dimension. This can be fixed by stacking sequential (IRIS) raster scans/cubes. After firing up glue from the terminal by the magic command “glue”, and importing some if not all raster scans from the same observation using the IRIS OBS directory importer, and choosing to “Stack the sequential raster scans” , we see some data points appearing in the Data field of the GUI. This is illustrated by the sequence of images to follow:

As we can see in Figure 6, all 4 dimensions are represented in the 1D Profile viewer either as the x-axis or as a slider quantity. In this example, the x-axis is indeed wavelength (which yields a 1D spectrum by definition), the other dimensions are time, longitude (HPLN), and latitude (HPLT). Even though for now the sliders are still not yet functional and will need some tender loving care to make them work in tandem with the reference data as inherited or passed from the 2D Image viewer, which may take a few more days to complete, I believe this is truly a milestone in this GSoC project. If we can control the sliders to change the coordinate values, that would be a very useful tool in data exploration. I will spare the perhaps rather dry details regarding the reasoning through the whole thinking process that leads to this check point. However, I would like to explain the logic used in the slicing. What I have done is to introduced a SlicedData class, much like the existing IndexedData class that is used for pixel extraction with a tool my mentor Stuart Mumford originally wrote for glue-solar (currently in a draft PR to be upstreamed to glue). First to pick a spatial coordinate, we choose in the 2D Image viewer the spatial axes for the image axes, selecting a point in the image shown on screen with the pixel selection tool, and then tweak the slider we would like its corresponding axis to be used as the x-axis in the 1D Profile viewer. Then we drag the same dataset to the viewing area and view using the 1D Profile viewer, in order to generate a profile for the slicing we have chosen. So this has been the work completed thus far. What is yet to be completed is to enable the manipulating of the 4D or higher dimensional data cube using the sliders for the same x-axis. So in the end regardless of the starting point, we could potentially use the 1D profile viewer to inspect the 4D or ND data cube in ways previously impossible before, at least to me.

Again, I would like to thank my mentors for their guidance and support which enabled the progress I have made to happen. Much work will need to be done in order for the PRs to be polished up and merged later on in the summer. I really enjoy my glue-solar work for GSoC this summer. I hope you enjoyed reading this article as much as I had fun writing it too!

1. Modify the existing glue 1D Profile viewer to provide sliders for extra dimensions (currently collapses)
2. Clean up UX / UI (icon) for the pixel extraction tool (perhaps also upstreaming from glue-solar to glue)
3. WCS info for derived datasets (i.e. raster + SJI time linking)
4. Loaders for specific instruments: NDData (in glue), NDCube (for NDCube 2.0 with extra coords), SST, IRIS, EIS, DKIST (e.g. with asdf to glue)
5. Add auto-linking to match wavelength and time dimensions in larger cubes (currently already works for Celestial dimensions)
6. Enable image / Movie exports, both with axes and without axes via the matplotlib package
7. Add support for pre-computed statistics in datasets / viewers

The above, along with the accompanying documentation, are expected to be part of the deliverables of the GSoC project. So far a couple of pull requests (PRs) have been submitted to both the glue and glue-solar repositories (repos), with the most recent one being the one for updating the 1D Profile viewer to plot with wcsaxes instead, which can be accessed at glue-viz/glue's PR #2156. However, the CI problem encountered in this PR seems to be able to be fixed by upstreaming the pixel extraction tool which currently only resides in glue-solar. This will need to be discussed with my mentors as careful considerations such as one pertaining to timing are warranted.

One of the first glue-solar PRs I have worked on are for adding an “open with SunPy Map” option to the “Import Data” tool. Part of this tool has been merged into glue-solar, while the other part is pending merge in glue. Basically if I load in an AIA map with its associated HMI map, like the sample one from SunPy, while choosing “SunPy Map” as opposed to the FITS format that gets detected by default, as shown in the Fig. 1:

So if one plots the SunPy maps individually, one would get the what is shown in Fig. 2. This is basically the same as what one would get with FITS files as well, except for the colormaps.

The magic of our work is that now with the glue-solar plugin, we can overplot AIA map and its associated HMI map, as simply as dragging the HMI data from the Data section onto the AIA map 2D image already opened with the 2D Image viewer, as these are spatially linked by the plugin using some pixel-to-pixel transformation via WCS.

So the subject of attention that has been the focus of my glue-solar work, or my favorite “toy”, over the last few weeks has been firstly a prototype for a “SunPy 1D Profile” tool which plots a 1D spectrum at a spatial position as picked out by the pixel extraction tool currently resides within glue-solar. To upstream the changes I have made to glue, and with the help of my mentors especially Stuart, we have started work on a PR to move such changes to the “1D Profile” in glue proper, using my “SunPy 1D Profile” work as a check and basis. If one loads in a raster cube using some IRIS level 2 data using the IRIS Spectrograph file type enabled by glue-solar, plots a slice of the data cube with the “2D Image” viewer, and then extracts a pixel position in the 2D image in the viewer (with the “HPLN” as the x-axis in lieu of the “wavelength” as the default option), one obtains a 1D profile upon hitting the spectrum icon in the 2D Image viewer panel. The result is as depicted in the collapsing “Fig. 4” image below:

After which if one changes the “function” in the “Plot Options — 1D Profile” from the “maximum” to the newly added “slice” option in my PR, one would obtain a 1D spectrum without any collapsing as shown in the “Fig. 5” image below:

This non-collapsing 1D spectrum plotting facility is new to glue with the glue-solar plugin, and is currently still under heavy development.

Overall it has been a great experience this second time around participating in GSoC at this early phase. The experience is especially positive given that I am engaged in some work that I could understand and really like. Previously I have been exposed to data cubes in my PhD studies in astrophysics, with the knowledge gained now comes in handy for my glue and glue-solar work. I look forward to contributing as much as possible to the project in the months to come during GSoC, and possibly beyond.

To introduce the glue-solar plugin, it is only natural to first introduce the glue package for which it operates on. As its official website would suggest, glue is a package for multi-dimensional linked-data exploration. With glue, users can generate scatter plots, histograms, and both 2D and 3D images of their own data. The package emphasizes on the brushing and linking paradigm, where selections in any graph can propagate to all others. Moreover, glue uses the existing logical links between different data sets to overlay visualizations of different datasets, and to propagate the same selections across all other data sets. To clarify, these can be spatial and temporal links. These links are specified by the user, and are designed to be arbitrarily flexible. Finally, glue is written in Python, and built on top of its standard scientific libraries (e.g., Numpy, Matplotlib, Scipy), such that users can easily integrate their own python code for data input, cleaning, and analysis, enabling full scripting capability.

Back to the glue-solar project, it is to provide a foundation for interactively exploring and quickly analyzing large datasets (100Gb or larger) in solar physics to be built in Python. This software will enable multi-instrument interactive visualisation as a plugin of glue. While a fully featured GUI toolkit for solar data is not expected to be built in one summer due to time constraint, the goal is to provide the technical building blocks, but more importantly to demonstrate, and document, how this framework can be used by various instrument teams to build custom solutions for their solar data. Glue-solar, like glue is completely free for anyone to use and is open-source. Furthermore, glue-solar is a collaboration between glue and SunPy, hence its focus on solar physics.

The official start date of this year’s GSoC is June 2nd, 2020, immediately after the current community bonding period. But work has already begun and we have already opened pull requests (or PRs) at both the glue and glue-solar repos to enable loading of basic SunPy maps such as AIA and HMI data so that they can be overplotted as different colormaps. As per usual, GSoC will last for about three months, until August 25th, 2020. This summer is surely going to be filled with many fun hours of coding for both glue and glue-solar for me. I am definitely looking forward to enjoying working on my last GSoC project this year, with my amazing mentors’ guidance.

Side Notes* — Gemini announcements verbatim as as released on October 11th, 2019 are as follows:

• As of this week’s v10.15 release, MacOS is no longer capable of running the 32-bit Astroconda IRAF distribution needed by Gemini IRAF. For the time being, Gemini IRAF users on Apple machines are advised to continue using MacOS 10.14 or earlier, or to install Astroconda in a virtual machine with a compatible OS. Gemini will look into providing a ready-made VM image to help with this while we are migrating our data reduction tools to Python.
• Furthermore, MacOS 10.14.6 suffers from a bug that can cause a desktop session logout when attempting to display plots or images with PyRAF, DS9, Matplotlib or other software that uses Tk. We suggest that PyRAF users on 10.14 avoid updating their OS until such time as this problem is resolved by Apple and/or we can determine a reliable workaround (check here for further announcements). IRAF CL is unaffected, but note that we are no longer testing it routinely and are aware of occasional failures with Gemini IRAF.

Steps

1. First is to install VirtualBox on your Mac, for me I downloaded VirtualBox version 6.1 (released on January 14th, 2020) first. In here I assume the setup is quite simple as the instructions given after the user has opened the installer by double clicking on its icon is quite straightforward, so I will not dwell too much on it in here.
2. Then next thing to do is to run VirtualBox on your Mac. If all goes well a GUI should pop up with the welcoming message “Welcome to VirtualBox!…”. If that’s the case we will leave things as is with VirtualBox for now.
3. Then download the current LTS version of Ubuntu (my go-to Linux distribution) on your local machine. At the time of writing of this article the LTS version is 18.04. Say for example the link for the download is https://ubuntu.com/download/desktop). The disk file downloaded is then one in the .iso format.
4. Next we go back to our VirtualBox GUI, we start a new VM by creating a “New” machine. You will then be prompted to give the VM a name at this stage. For me I have used “ubuntu-18.04” (not typing in the quotes in the name field) as the name for the new instance. But feel free to use anything you deem appropriate like “iraf-pyraf-vm” or “my-awesome-vm”. Then choose the default folder (i.e. leaving the folder field as is), the type “Linux”, and the version Ubuntu 64-bit. For the memory size just to be sure I have set it to be 4096 MB, also since I can afford to given my host machine setup. Next set the Hard Disk option to Create a virtual hard disk now. Finally press “Create” button on the lower right corner to finish the VM creation process.
5. We leave the File Location as the default. Next we have choose for the File Size to be at least 10.00 GB for the Ubuntu disk file to enough space to function properly. And in my case to make sure things would work I have in face set this to be 100.00 GB, since I have tried 10.00 GB but it didn’t work for a basic installation of IRAF/PyRAF the first time I tried. Then choose for Hard disk file type the option VDI, which is short for “VirtualBox Disk Image”. And, set Storage on physical hard disk to the option Dynamically allocated.
6. Next we will need to install the Ubuntu image. First we choose to start the VM instance in the “Normal Start” mode. Then, we choose from the dropdown menu the Ubuntu disk image in .iso format we have downloaded from Ubuntu in Step 3. If everything goes as expected, Ubuntu will then start. However, at this point at least, the display of the image might be too small and it is best to be adjusted by setting the Virtual Screen 1 to “Scale to 200% (autoscaled output)” which is located at the 5th icon in the bottom right buttons panel, at least for the time being.
7. Next we are ready to install Ubuntu onto the VM by clicking “Install Ubuntu” on the Install window where it says “Welcome” on the top left corner, instead of “Try Ubuntu”. Note you can also select a different language other than English here.
8. Next is keyboard layout settings. The defaults are set to “English (US)”. But you can certainly choose to have different settings if so desired. Then click “Continue”.
9. Now we are at “Updates and other software” window, for convenience we can go with the default settings of “Normal Installation” with “Download updates while installing Ubuntu”. Then click “Continue”.
10. After that, choose “Erase disk and install Ubuntu” for the installation type, and click the Install now button to confirm. When prompted to confirm whether you would like to “Write the changes to disks?”, simply choose “Continue”.
11. Then next is to choose the timezone in the “Where are You?” window. Your time zone will be detected automatically so it is recommended that the defaults be accepted by choosing “Continue”.
12. Lastly, it is time to enter our personal credentials to complete the setup. Enter on the “Who are you?” window you chosen name, computer name, username, as well as an adequately strong password. It is recommended to choose both names and computer names as all-one-words with no spaces in between. After this, you will be prompted to restart the VM. Accept this to reboot your machine.
13. Next is to both download and install Miniconda for your VM once it has been restarted. First go to your home directory, by doing something as simple as typing and entering cd at the command prompt. You can download Miniconda with the following command at the Terminal:

$ wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh

14. After the download has been successfully completed, install it with the command:

$ bash ./Miniconda3-latest-Linux-x86_64.sh

15. Then we are to install all the necessary dependencies with the following command:

$ sudo apt-get install libc6:i386 libz1:i386 libncurses5:i386 libbz2-1.0:i386 libuuid1:i386 libxcb1:i386 libxmu6:i386

16. Next do the following to first add the astroconda channel, and then to create a new virtual conda environment named “iraf27”:

$ conda config --add channels http://ssb.stsci.edu/astroconda
$ conda create -n iraf27 python=2.7 iraf-all pyraf-all stsci

17. If after solving the environment you are prompted to answer whether to proceed with the installations, simply type y and then press enter. If everything goes as planned a confirmation message will be produced in the text output and you will be given some brief instructions as to how to activate and deactivate this particular environment (“iraf27” in our case). Following the instructions and then at the command prompt please enter the following to source the correct environment:

$ conda activate iraf27

18. Then we first make a directory called “iraf”, change directory to it, then initialize pyraf with the following commands in sequence:

$ mkdir iraf
$ cd iraf
$ mkiraf

19. When prompted for the terminal type please enter xterm.

20. Finally, if no error or omission has been made, in the iraf directory, simply enter the following to start pyraf :

$ pyraf

Then you are all set to go with a functional copy of the PyRAF software! It should be noted that you can configure VM further such as the display resolution, and the shared (with one’s local machine) transient folder to be used.

Happy exploring astrophysics!

It is my pleasure to report that with my mentors’ assistance as well as my many hours of contributing to the sunpy/irispy GitHub repo, I have been able to reach all four goals original set out by the primary mentor Danny Ryan, which are as follows:

• The time-dependent instrument function response code must be rewritten to be more efficient and Python-friendly.
• Formal benchmarking between the results it produces and those found using the original IDL code must be performed.
• Tests for the Python version must be written.
• This software must be incorporated into methods and functions in IRISpy that depend on the instrument response function.

Accordingly, the three outcomes have been accomplished as below:

• A function for deriving the time-dependent IRIS response function.
• Benchmarking and unit tests so this new software can be reliably maintained.
• Updated intensity conversion methods between instrument and physical units that correct for the time observations were taken.

For a product of this effort, please go to https://github.com/sunpy/irispy/pull/119 , which is to merge the four PR’s already merged into the time_dependent_response branch into the master branch in order to incorporate our work into IRISpy officially.

I would particularly like to take the time to thank every one in the SunPy community for their support of me over the past few months, in particular my project mentors Danny Ryan and Laura Hayes. They have been very helpful in answering my questions and in helping me solve some very thorny IDL questions. The time I spent on GSoC this year is the moments I will not forget!

Grateful to report that I have eventually solved the issues encountered as stated in blog post 2.2 in the series for my GSoC project… and most important of all with my mentors’ blessings I have successfully passed the 2nd coding phase. Moreover, I am delighted to report that my most significant contribution on GitHub thus far, which is the PR to enable time-dependent effective areas determination of IRISpy, has been merged about 6 days ago. More can be found about this PR at the link https://github.com/sunpy/irispy/pull/108.

Currently I am continuing on my efforts to complete the project by updating the intensity methods between instrument and physical units, in another PR at https://github.com/sunpy/irispy/pull/117 . My goal is after finishing up this PR then move on to completing the testing by tidying up loose-ends left in PR #108 and add to it the required tests. The challenges remain is to determine the test cases used and the best way to keep the tests neat. I have already begun work on the testing front as well, though a former PR has not been opened for it yet.

All in all everything is looking good. I am looking forward to continue working under the supervision of my project mentors further before GSoC 2019 comes to a close in about 2 to 3 weeks’ time. Their expertise and patience have been amazing, and I am grateful for their mentorship.