Blog - Posted in 2019

Sunkit-Image: Final GSOC Report

2019-08-24T00:00:00+00:00

This project developed several image processing algorithms and manipulation routines for sunkit-image, an affiliated Python package of the Sunpy Project. The rigorous analysis of solar images is of paramount importance to the Heliophysics community as this can reveal more information on solar features and events, which in turn can affect the Earth. This project brought selected solar image processing algorithms under the umbrella of a new library.

GSOC 2019: Project Goals

There were four major goals as listed on the OpenAstronomy website.

These included: * Implement the Normalizing Radial Gradient Filter * Port the Multi-scale Gaussian Normalization * Implement the OCCULT-2 algorithm for coronal loop tracing * Implement Soft Morphological filtering of the solar images

Project Goals Completed

Implement the Normalizing Radial Gradient Filter Normalizing Radial Gradient Filter is an algorithm designed to enhance features off the solar limb in a solar image. It normalizes the radial gradient i.e., the sharp decrease in intensity values in images as the pixels increase in radial distance from the Sun’s centre which helps in visualizing the coronal structures. This has been completed and merged along with its sister algorithm the Fourier Normalizing Radial Gradient Filter. The code for this can be found on this PR.
Port the Multi-scale Gaussian Normalization Any solar image contains information distributed over a very wide range of spatial scales which can be mostly hidden due to the variation of intensity values in an image. Processing such an image to unveil that hidden information is therefore very important. Multi-scale Gaussian Normalisation effectively normalizes the pixel values locally at different scales by convolving with different widths of Gaussian kernels and can reduce noise locally revealing any hidden features. The algorithm was successfully implemented and the code has already been merged.
Implement the OCCULT-2 algorithm Oriented Coronal CUrved Loop Tracing (OCCULT) is an algorithm designed to automatically trace out coronal loops in an image. It traces out loops starting at the maximum flux position and then moving in a bidirectional fashion from that point. The code, documentation and examples are complete and can be found here, it is waiting for further reviews and will be merged shortly (< 2 weeks).
Implement the Soft Morphological filtering The soft morphological filter approach to removing cosmic ray hits in a solar image uses image morphology operators and genetic algorithms. However, a similar package called Astroscrappy that also removes cosmic ray hits was found. We found that the algorithm used by Astroscrappy had more citations as compared to the Soft Morphological filtering and in our tests, it produced good results on solar data. So it was decided that the Soft Morphological filtering will not be implemented and rather a detailed example on how to use Astroscrappy on solar data was written here.

Further Project Work

These tasks were not part of the main GSoC project goals but were worked upon during the GSoC project.

Fourier Linear Correlation Tracking An existing C library was wrapped using Cython to enable Python calls to a Fourier Linear Correlation Tracking (FLCT) C library along with the tests and documentation for the wrapper. This algorithm aims at finding out the 2D flow field between two images. This work is complete and under review. However, as the C code is licenced under GPL v2 and sunkit-image is under BSD, we are waiting on permissions from the original authors before this can be merged or if it needs to be spun into a separate library.
Fourier Normalizing Radial Gradient Filter This was implemented as a run-up to GSoC and the tests and example were written during the coding period. This was merged along with the Normalizing Radial Gradient Filter.
Noise Level Estimation There was a preexisting noise estimation class in sunkit-image and it was decided that this was to be converted into a series of functions. Most of this task had already taken care of in PR 22, however, the original author was unable to finish this work and so this was completed in a new pull request and was merged.

Google Summer of Code 2019 | Final Report | OpenAstronomy | NDCube

2019-08-24T00:00:00+00:00

Google Summer of Code 2019 | Final Report | OpenAstronomy | NDCube

GSoC FTW!

For those who are geeky and want to see the PRs submitted…

Here is the link where all my PRs for completing the project are present. > # Google Summer of Code (GSoC) is an online, international > #program designed to encourage university student participation in open source software development.

Details of my Organisation and Project

Before I start writing my report, I would like to thank my mentors Daniel Ryan and Stuart Mumford. They have been quite helpful in guiding me through the project, and have been quite responsive. Special thanks to Nabil Freij, for guiding through the project here in SunPy/NDCube.

NDCube is the fundamental class of the ndcube package and is designed to handle data contained in a single N-D array described by a single set of WCS transformations. NDCube is subclassed from astropy.nddata.NDData and so inherits the same attributes for data, wcs, uncertainty, mask, meta, and unit. The WCS object contained in the .wcs attribute is subclassed from astropy.wcs.WCS and contains a few additional attributes to enable to keep track of its relationship to the data.

SunPy: The Sub-Organisation that I worked in.

My GSoC project was under OpenAstronomy, and NDCube is a SunPy affiliated subpackage for handling ND Data arrays and perform data-analysis on them.

NDCube is a SunPy affiliated package for easily dealing with ND-Data cubes along with convenience method that allows the data cubes to be sliced, attach meta-data to it, and easy to use plotting methods, to visualize an ND-Data. It uses SunPy’s visualization to plot more than >2D cubes and provides sliders to shift the different dimensions, so even if users are using only 2D dimensions at a time, we can still leverage the other dimensions.

My project with NDCube was to port the internal API to match all the proposals laid out in APE14 and make sure that NDCube works in the same manner as it was working. The project was particularly interesting because I had a first-hand chance of interacting with API designing and how the different patterns were used to implement that. NDCube uses FITS-WCS to interact with, but APE14 leveraged the NDCube to use any WCS object implementing all the base methods laid out in the proposal. This was really exciting and I had a chance to use gWCS along with FITS-WCS in NDCube.

Blogging and details of my work

My weekly notes about my progress have been documented in my blog. Feel free to check out and suggest changes if needed.

Breakdown of my project

As described in my proposal, I had broken down my project into three parts —

Porting NDCubeBase to use APE14
Porting NDCubeSequence to APE14
Support plotting in NDCube

All the associated PRs have been blogged in the PR post that I made earlier. Feel free to check them and gauge the progress that I made.

Some Visuals associated with my project

Example of a WCS plotting with NDCube

Example of WCS Line Plotting with NDCube

My Experience with working with NDCube/SunPy

Right from the start, I was really interested in working in SunPy, because of its amazing community and responsive mentors which I had planned to learn from them. The mentors were really helpful, right from designing the proposal to implementing them, always filling out on potential hurdles and rescuing me out every now and then.

I decided to list out the tasks which could not be completed, as the rest of the checkpoints were achieved successfully.

Here are some tasks which I had planned but could not be done

Writing gWCS test-suite for NDCube — This was an optional part but having spent time with the code-base a lot, I realized that this could be done in a short time. However, this being an optional part, got pushed right at the end, and eventually had to be dropped off from the weekly tasks. I have planned to complete it after GSoC, so it remains on top of my priority list.
Completing plotting of NDCubeSequence — I had completed almost all of the tasks as I had planned in my proposal but remaining one — Completing the plotting for NDCube Sequence objects. I had made the PR, but on close digging with the codebase, I realized that the master codebase was buggy, and a bug fix was needed to be made before resuming my porting. I made the PR, and after consultation with my mentor, we decided to drop the priority for the bug fix and just concentrate on my porting. I made a PR but it remains open till the bug is fixed in the master branch.

My Experience with Google Summer of Code

GSoC had been an integral part of my sophomore life, as it was something that I wanted to try out, with the associated perks and the hyped-up( but true!) steep learning curve. I had started my contributions right from January when people are unsure with the organizations and the type of projects that they want to commit to for the rest of the summers. I chose SunPy because of its fantastic community of developers from whom I learned a lot.

There was blogpost by NumFocus which highlighted my learnings during GSoC, so I would be sharing some unique points (not share the old ones :P) that highlighted my learnings —

Make sure you have a good understanding of the subparts of the project

I have had some moments where I just went about my tasks without having a solid understanding of them. I had to revert back to understand it again, so I recognized my shortcomings after my first evaluations and made sure that I had a solid understanding of the problem, rather than diving into it, without understanding the what and why of the problem.

Make sure you have some backup tasks to fall back upon

I have had moments when my work progress dried out, but talking with my mentor(s) and having some backup tasks did help me with my case of sitting idle. This turned out to be crucial in the last few weeks, as I had little to no time of starting out on a new feature. Thanks to my backup tasks, I had to carry forward them rather than starting them from scratch.

Make sure you have fun

Well, this depends on org-to-org, so I would not consider it as a universal fact. I had fun in interacting with the weekly community meetings arranged in every Wednesday. Other developers were quite helpful and curious about the progress of my project, and I was really happy to share the progress of my work.

GSoC is surely an experience of a lifetime, and I would suggest everyone who is enthusiastic with Open-Source and want to develop industry graded software, then GSoC is the right place.

Ciaos Adios!

Part 7: The End Arrives

2019-08-19T00:00:00+00:00

It has now been twelve weeks since I began this journey and finally, the curtains on this arduous and breathtaking adventure have been begun to fall. This week it will be last week as an official Google Summer of Code and this will be my final post as a student. I can feel the nostalgia gripping me.

Well, this has been one of the most productive summers which helped me gain a lot of new skills and make new connections and I would really like to thank Google and Sunpy for giving me this opportunity. I would also like to thank my mentors Nabil and Jack for being the constant support which I needed throughout the length of the program.

This post mainly serves as a summary of all the progress which has been made in the Sunkit-Image project since the commencement of the summer of code. Speaking statistically, I had opened five pull requests adding four independent algorithms and image processing techniques along with a pull request solely dedicated to documentation. This included their documentation, testing, and examples how to use them which overall amounted to be about 3,000 lines of code written by me.

Coming to the algorithms which got introduced in Sunkit:

Normalizing Radial Gradient Filter

This particular algorithm is designed to enhance offlimb features in a solar image. Though this was already present in Sunkit, it had some flaws and without any proper documentation and examples to it. I rectified the code wherever it was needed along with adding proper documentation and example to it.

Fourier Normalizing Radial Gradient Filter

This is an advanced version of the Normalizing Radial Gradient Filter aimed at the same task. This was implemented from scratch as a precursor to my application for GSOC to sunpy. I completed it when the coding period began and both the NRGF and the FNRGF were pushed in a single PR here. This has already been merged.

Multiscale Gaussian Normalization

Next, I moved on to the Multiscale Gaussian Normalization which is an algorithm designed to enhance features on the solar surface. It was fully implemented along with documentation and examples which can be found here. This too has been merged.

Soft Morphological Transform

The implementation of this particular algorithm did not take place because we found an Astroscrappy module which actually does the exact same thing using a different approach. So instead of doing a repeated work we decided to move on to something more useful. But, nevertheless an example describing how to use Astroscrappy was written.

Oriented Coronal Loop Tracing (OCCULT)

This is the part of the programme which took the longest time to code and debug. It is an algorithm to automatically trace out coronal loops in an image. This PRis complete with tests and documentation and is under review presently.

Fourier Local Correlation Tracking

A python wrapper was created for the FLCT C code such that it becomes usable in Python. This particular algorithm finds the 2D velocity flow field between an image. This too took almost a month to be completed and is under review now. You can have a look at the code here.

This mostly sums up what has been done during the coding period and I feel the four major goals which had to be achieved for the successful completion of the programme have been achieved. I do hope that I will successfully clear the final evaluation.

Hope you all enjoyed reading the glimpses of my journey through GSOC. It was a very nice and fascinating experience. I will still try to contribute to sunkit after the program ends. I do hope I get a second chance to be a part of this adventure again.

GSoC 2019: Project IRISpy 3.2

2019-08-18T00:00:00+00:00

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 here , 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!

Part 6: Reaching the Summit

2019-08-05T00:00:00+00:00

If I describe my journey through Google Summer of Code as an arduous mountain climbing adventure then finally I have reached a point from where the summitis within reach.

But as they say — > # “The last stretch is the most difficult!!”

The past few weeks have been such a delight — they involved everything from episodes of frustration to moments of great joy!! I really have to thank my mentors — Nabil and Jack, for the level of confidence they have shown in me.

If you have been following my previous posts then you are very well aware of the one thing about which I have been talking, i.e. the Fourier Local Correlation Tracking.This has been the longest part of my project and it took me almost a month to conclude it (though it is still not merged). So, the last time when I left you we were searching for a bug in the wrapper code. But to our amazement, we could not find anyone in the wrapper code rather it was lurking in the most unexpected of places.

The C code had some IDL I/O routines involved with it to read and write binary “dat” files. We were aware that the IDL and C codes will read the arrays differently owing to the order in which they store arrays. IDL is column-major and C and Python are row-major. We thought that it can be taken care of by transposing the arrays but it was found that this was not the solution because both the codes were reading different values from the binary files and this was really baffling!!

Later, we realized that this was actually due to the order of operations. IDL was reading the binary file in column-major, unlike C which produced different results. So to fix this I wrote a few more Python functions wrapping the C read codes and also providing an option by which arrays read by IDL can also be used. This finally completed our code for FLCT and only the documentation and examples were left, which were later added.

On a separate note, I passed the second evaluation but after reading the above, I presume you already got to know about it ;-)

The most exciting part of this journey still awaits and I hope with the team with which I have been working with we will surely reach the summit. I hope you enjoyed this and would surely join us next time to see the conclusion of this saga. Until then, ciao!!!

GSoC 2019: Project IRISpy 3.1

2019-08-04T00:00:00+00:00

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 here.

Currently I am continuing on my efforts to complete the project by updating the intensity methods between instrument and physical units, in another PR. 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.

Part 5: The Second Evaluation Awaits

2019-07-21T00:00:00+00:00

The fifth part of the ongoing series of my blog posts on my experience in the Google Summer of Code. I am working with Sunpy on their solar image processing toolkit, Sunkit-image. As of now two months have already and it has been an enriching experience. The second evaluation is also just around the corner and I am very hopeful that I will be able to clear it.

In this post, I describe the last two weeks of my work which was essentially only one week of work as I was on a vacation for a week. I had already discussed with my mentors regarding taking a vacation and they were fine with it if I could compensate for the lost time.

Now coming to the details of the work in the past week. I had been working on writing a python wrapper for FLCT C code. Fourier Linear Correlation Tracking is an algorithm which finds the 2D flow field between two images taken within a close interval to each other. I had earlier written the wrapper for the subroutines of the FLCT main code. During this week, I fixed the original wrapper for the subroutines and also implemented the main FLCT file, which makes FLCT available in python.

There are few errors hidden in my code as of yet which are being diligently hunted. Hopefully, the code would soon be bug-free. I am also working on the testing and documentation of the sub-package simultaneously. The entire wrapping has been done using Cython where the numpy arrays have been converted to C-compatible types like pointers or pointer to pointers.

Overall this particular section of work was very interesting. It was the first time I had used Cython and power which it provides to use of C codes in plain Python is amazing. The knowledge of this opens up various avenues of optimization in other python functions.

Hope you enjoyed reading this. Stay tuned for further updates!!!

GSoC 2019: Project IRISpy 2.2

2019-07-21T00:00:00+00:00

To follow up, the problem encountered as reported in edition 2.1 in this series has been resolved with the help of my very helpful and responsive mentors. But some lingering issues remain, which we suspect to be mostly indexing-related, as is apparent from the way the given IDL code is translated into Python. So now all four versions of IRIS response can be used to produce some get_iris_response function output. However, say for example version=4, I have been only able to successfully reproduce 3/4’s of the expected output as generated by the IDL version of the code. This is encouraging, as previously only half was the same as the target output. So the part of the IDL code that I am having some problems with is the following:

; 4. SJI effective areas
if fix(r.version) le 3 then begin
 sz = size(r.coeffs_sji)
 for j=0,sz[3]-1 do begin
  ; calculate pre-launch area from the individual elements
  pl_a = r.geom_area
  for k=0,n_elements(r.index_el_sji[*,j])-1 do $
      pl_a=pl_a*r.elements[r.index_el_sji[k,j]].trans
  ; time dependent response
  rr = fit_iris_xput(tt,r.c_s_time[*,*,j],r.coeffs_sji[*,*,j])
  ; time dependent profiles
  for k=0L,ntt-1 do o[k].area_sji[*,j]=pl_a*rr[k]
 endfor
endif else begin

 for nuv=0,1 do begin
   ; calculate baseline SJI area curves
   asji = r.geom_area
   for k=0,n_elements(r.index_el_sji[*,nuv*2])-1 do $
     asji=asji*r.elements[reform(r.index_el_sji[k,nuv*2:nuv*2+1])].trans

   ; apply time dependent profile shape adjustment to FUV SJI
   if ~nuv then begin
     ; FUV: apply FUV SG "slant", then normalize so that a weighted (2.4:1)
     ;      sum at C II and Si IV gives constant response
     wei = [2.4,1.0]   ; typical solar ratio CII : SiIV
     wav = r.c_f_lambda
     nwv = n_elements(wav)
     wav = [wav[0],(wav[nwv-2]*2.0+wav[nwv-1])/3.0]       ; 2 wvlngts in nm
     ; calculate baseline SG area for scaling purposes
     asg = r.geom_area
     for k=0,n_elements(r.index_el_sg[*,nuv])-1 do $
       asg=asg*r.elements[r.index_el_sg[k,nuv]].trans
     ; SG and SJI areas at wav
     asg2 = interpol(asg,r.lambda,wav)
     asj2 = fltarr(2,2)
     for j=0,1 do asj2[*,j]=interpol(asji[*,j],r.lambda,wav)
     ; calculate the normalized slant function scal, apply to asji
     for k=0L,ntt-1 do begin
       ; best-estimate slant, i.e., eff.area @ wav / baseline SG @ wav
       sca2 = interpol(o[k].area_sg[*,0],o[k].lambda,wav) / asg2
       ; normalize slant so that total(wei*asj2*sca2)/total(wei*asj2)=1
       for j=0,1 do begin
         sca2n = sca2 * total(wei*asj2[*,j])/total(wei*asj2[*,j]*sca2)
         scaln = interpol(sca2n,wav,r.lambda) > 0.0
         o[k].area_sji[*,j] = asji[*,j]*scaln
       endfor
     endfor
   endif else begin
     ; NUV: essentially same calculation as r.version=3
     for k=0L,ntt-1 do o[k].area_sji[*,2:3]=asji
   endelse
 endfor
 for j=0,3 do begin
 ; SJI specific time dependency
   rr = fit_iris_xput(tt,r.c_s_time[*,*,j],r.coeffs_sji[*,*,j])
   for k=0L,ntt-1 do o[k].area_sji[*,j]=o[k].area_sji[*,j]*rr[k]
 endfor
endelse

if keyword_set(angstrom) then o.lambda=o.lambda*10.
return, o

This is the last but most complicated part of the get_iris_response code to compute the SJI effective areas for both the FUV’s and NUV’s. Something of interest to note is that the indexing in Python is the exact reverse of that in IDL. But it will be a lot fun trying to make the current code I have been working on to agree with the above 100%. I have been thinking maybe there is something regarding the IDL interpol function (for interpolation) that I have been translating wrong, as there is no exact equivalents in Python, and the closest thing to it is some two-part scipy.interpolate methods which I can use for the same task. Hopefully I will be able to overcome this almost last hurdle soon, say within a week or two. That would leave me with enough time to complete the project comfortably before the conclusion of GSoC 2019.

[Week 06] — First Evaluations and Completing the first half

2019-07-08T00:00:00+00:00

First Evaluations are Completed!

This blog post deals with the entry of tasks that I did for the 6th week for the project under Google Summer of Code 2019.

First Evaluations results are out

So the first evaluations results are out, and fortunately, I have passed the first evaluations. This was a mini-victory moment for me, and to top it up, my PR regarding the first evals was merged which was sweet for me!

I got a mail from Google, stating that I have passed my evaluations, and my mentor had given positive feedback. I was overjoyed and jumping out of happiness! I am not comfortable in sharing my mail here, but I am happy to state a few of the comments by my mentor.

My mentor commended the amount of hard work done and suggested me to improve my check-ins with the progress and keep pushing the code to GitHub so that how much progress I am making could be gauged.

This was imperative as it would help me in assessing my strengths and not over-working them, and work on my shortcomings as soon as possible. I had decided with my mentors that for the second part of the project, I would rather break my PRs into several small parts, each of them dealing with a small sub-task, that could be individually integrated back into NDCube.

Gearing up for the next sub-part

If any of my readers had been gauging my progress, here is a tab which contains most of the task that should be completed to check-off the task. I had covered most of the tasks of NDCubeBase. I was concerned with the working of axis_world_coords, which I had re-written earlier, and not sure about the working of it.

I decided to add it to my later tasks, as I started with planning for the next half of the project, the plotting. This required me to read through the docs for understanding the plotting. I had earlier worked with the plotting earlier, so I had been familiar with the code of plotting.

The trick was to break the codebase into small portions, as the plotting code was delegated into small methods which worked out the plotting of 1D, 2D and >2D NDCube objects. @DanRyanIrish had earlier advised me to break out the code into small parts, each of the refactoring dealing with different types of NDCube objects.

Tasks for the next week

The tasks for the next week remains a bit confusing. I plan to take on plotting, before trying out the changes that I made for the first part of the coding. My mentor @Cadair would be out on his vacations for around 2-3 weeks, so @DanRyanIrish would be expected to take in the charge. I don’t expect him to be available every now and then 😛, but I plan to make progress without pinging them every now and then.

Link to my previous post

[Week 05] — Testing out the codebase! — Link

[Week 05] — Testing out the codebase!

2019-07-08T00:00:00+00:00

Testing FTW!

This blog post deals with the entry of tasks that I did for the 5th week for the project under Google Summer of Code 2019.

First evaluations are nearing!

My task for this week was cut-out; complete the testing and pass my first evaluations. Well, it wasn’t as strict as it sounds, as my mentor has been quite supportive, and he was more than happy to pass me for the first evaluations for the amount of work that I had put. However, I personally felt that delivering complete content before the first evaluations were important, for it would unfair for anyone to pass me for the sake of hard work. Final results matter, so I was determined to complete off the tasks, before riding on to the next set of challenges.

Testing out the Slicing

So I started out with commenting out all tests, and un-commenting each of them one by one, and seeing if they are failing. Well, it was manual work, but I was more than happy to do, considering the mentally draining work that I did the week before.

Each test cases were written with a specific use case, and my code was performing well with each one. After completing the refactoring of the test-suite, I was mostly finished with them, with two of the tests failing. I was not sure what was happening, so I discussed my issue with @Cadair and @DanRyanIrish. They were quite happy with the progress, and I had a telecon with them, through which I explained how I rewrote the codebase and explained the assumptions that I took while writing them.

Code reviews are important!

Well before I had my telecon, I was assisted with my mentors for a code review, and boy it sounded quite intimidating. Imagine working out a workable solution, and then get suggested by the mentors, a much simpler and elegant solution. It was helpful and scary at the same time — Helpful in the sense that it changed my way of approaching a paradigm of coding, and scary because I was unsure if I met with the standards of coding.

Telecon with my mentors

After finishing up with the suggestions from my mentor, I discussed out the two failing test cases, which was bothering me for a long time. @DanRyanIrish was away for a long time, so he asked me for a telecon to get updated with what I have been up to this time. @Cadair also joined me, filling out on the holes that I made throughout the discussion, as he was quite active while I was writing and pushing my code.

During the telecon, after closely looking through the code, @Cadair suggested that the ordering of slicing for WCS object required input parameters in the cartesian format, opposite to what I had assumed in my code. This sounded really scary I had written my code with that assumption. This was really heartbreaking for me, as I didn’t expect such a conceptual error from my side. This meant that I hadn’t read the assumption well, and certainly threatened my progress.

Diving into the docs again

In order to fix this, I was determined to dive into the docs again, as I wasn’t sure how the stuff was working. I mostly considered the slicing of WCS as a black box, which was a big conceptual error from my part. I learned how not believe certain assumptions, and the code is written provides the concise proof of the assumptions taken — Nothing more, nothing less.

On further brainstorming, I found that the slicing used NumPy convention(opposite of cartesian convention), and that was the result why most of the tests were not breaking. This was a big green flag, but I was worried about those two failing test. On close inspection, I found that both of them used Cartesian ordering instead of NumPy ordering, which was why it was breaking. It was sloppy from my side, as dealing with a huge number of test-cases certainly invites a mistake or two.

I was able to get my PR merged, as Cadair was mostly impressed and convinced about the tests passing, and asked me to focus on the next part of the project which was plotting.

Content for the next week’s blog post

The next week comes after my first evaluations have been done, so I plan to document out my evals result and discuss my next target of the coding.

Link to my previous post

[Week 04] — Climbing the Everest — 02— Link