The first week of the REU program consisted of IDL tutorials, which were given by Adam Kobelski and Roger Scott. The purpose of these was to help us get accustomed to the most important aspects of the new programming language, and become comfortable with it in preparation for the work ahead.
Having completed the week of IDL tutorials our focus shifted towards our individual research projects. My particular project involves active region transient brightenings (ARTBs). These are similar to solar flares - insomuch as they are magnetic reconnection events - however, they have several advantageous features, which make them an attractive phenomenon to study.
Firstly, ARTBs occur at lower energies than solar flares. As a result, they also occur much more frequently, meaning that ARTBs are far more suitable for statistical analysis. Secondly, ARTBs are much smaller events, meaning that a number of complicating factors necessary when developing numerical models of solar flares can be discounted, making ARTBs easier to describe using current numerical models. Thus, ARTBs are an effective and practical way to probe magnetic reconnection kinematics without requiring overly complex models and vast amounts of computing time.
The data set chosen to search for ARTBs was an XRT data set from October 2011, which covered one weeks worth of observations. Since ARTBs typically evolve over far shorter time scales - a few, to tens of minutes - it was necessary to split this large data set up into smaller, more managable, chunks before searching for ARTBs.
To do this, I wrote some code to split the data into chunks between 30 mins and a few hours. In order to use the maximum amount of data, an additional criterion was imposed on the data, whereby the data would only be split when there was a suitable natural pause. Typically there are gaps in the data when the Hinode satellite cannot observe the Sun as a result of its orbital position, or when the orientation of the satellite is changed. The code keeps a running total of the elapsed time in the current image stack, then once it is greater than 30 minutes and a suitable gap appears, that image stack is saved as a new data set. The running total then resets and the process is repeated. The result is that the original week-long data set is split into 61 smaller data sets; some notes on each of these appear below.
Having reviewed each of the above sets of data, the best canditates for ARTB searches were picked out - these were typically the ones with the most activity and of suitable length/cadence.
The program 'find_artb' was used to search the data for ARTBs. The program works by calculating the running mean of the background, then searches for pixels with a standard deviation greater than five sigma. When it finds such a pixel, it then searches all points connected to that pixel in order to determine whether they are part of the same brightening event. This effectively traces out the shape of the potential ARTB region and creates a new array containing the information about all ARTBs within the chosen image stack, and their location.
Upon running the ARTB search code, however, a problem was encountered: whilst processing certain data sets the code would become stuck and process individual pixels, one after another, as if they were part of an ARTB. I discussed this with Adam and he was able to modify the 'find_artb' code to fix the problem. The trouble was caused by the running mean count; it wasn't resetting properly in the longer data sets with the result that the calculated running mean was lower than should have been the case. This meant that the program was then flagging virtually all pixels as being ARTBs. A binary counting method was introduced to remedy the problem.
Run on ss_14: #1,2,9,11,13,14; ss_35: #1(?),8,12(?)The 'find_artb' code that is used to search for ARTBs uses a binary counting system in order to record which ARTB lies where. As a default, each element in the image stack is set to -1; then, when a particular pixel is detected as being part of an ARTB, a value is added to that pixel. The value depends upon the ARTB number.
For example, an arbitrary pixel x would have value: x = -1+2^n, where n is the ARTB number, and the first few ARTBs would have pixels numbered as follows.
ARTB 1, i.e. n=1: x = -1+2^1=1This counting method led to a problem however: the maximum size of an integer in IDL is 32767, which means that when the code attempts to calculate 2^16, it loops round and starts counting from upwards from -32768. As a result, it is not possible to record any more than 15 ARTBs in any one data set using this method.
There were two options at this point: either use another data type which can store larger integers, or chop the data sets up further so that no more than 15 were within an individual data set. We attempted to alter the code to use another data type, however this didn't work; therefore the only option was to chop up the data further before running the artb search code.
After running the code to find the ARTBs in each data set, the next step was to make a light curve for each one. The first step in doing this was to find the cross-section of the chosen ARTB. This was done by totalling 'artb_data' (the output of the ARTB search code) in the z-direction.