|
Monday, July 25th- Friday July 29th
Ok so first off I've been touching up my stack plot. The first issue was that the loops I traced from right to left weren't satisfying the inequalities I had in my intersection program. This weekend I identified those loops and reversed the coordinates so now almost every loop intersects the slit, except, at most, 20. I also switched from plotting distance from center to plotting just the x distance from the center. You can see the shape of that graph (the right one) fits the shape of the intensity a lot better. 
The only issue is that it seems to be shifted forward in TIME. I'll have to puzzle over that one for a bit before I decide what to do. Friday, July 15th- Friday July 22nd I'm finished with the stack plot program for now. I managed to make an array with all 169 loops in it, so I don't have to toggle back and forth between structures, and can plot everything at once. Here's the final result: 
The biggest problems for me are that the spacing between dots is spread out - I can't figure out why, and that for the lower section in particular, only 4 loops intersect the slit. There should definitely be more than that, but with the shifts they just don't intersect. I'll come back to this later, but for now I've moved on to extracting the data and displaying it. The program I wrote takes the data from the stack plot and makes an intensity v. time graph for a particular loop. If the loop didn't intersect the slit, the program doesn't like it, but I get a nice graph if it does. I've also wrote it so that it prints the intensities and the times. I'd like to have it label the highest intensity on the graph, but I haven't been able to get that working. I should mention, I'm pretty sure the units of intensity are DN/s/pix, but that's just a guess. Here's 4 rather different looking plots:  
 Well this morning's been frustrating. I've still been working on the intersection and stack plot programs. I made a really good discovery too. Apparently the FITS files that pfl_stack was reading came from a file search for *171*, but that search also picked up files like '08-01-2010-091714_AIA_304.fts', that is, files that had a 171 string anywhere in their name. So that FITS array was longer and it was throwing off the shifts. Once I fixed that expected everything to fall into place, but no luck. I set the slit to be just a vertical line, and I made a false array of 1 horizontal loop. From that I could tell that the slit and loops are being shifted correctly and the intersections are being foundAND those intersections are being plotted the way I want. I have to dig deeper into the coordinates of my plot. If there is a problem it'll probably be there. if there's not then my crappy graph will just have to do. I want to get this program over with, but even if that doesn't happen I'm moving on to work on other things. Dana had me create this plot:  Here's the same graph with the 335 data shifted up by 30 minutes: 
Obviously something is going on around 10/10:15 but I don't know what. Looking back at an older graph though you can see around the same time we lose all correlation between loop length and formation time.  I should note, however, the 335 data has no correlation between length and formation time at any point:  *****************Tuesday July 19th*********************** 5 e8 for an abundance factor of 4 These numbers are low compared to the loops Aschwanden calculated in his paper, so I wonder if that means anything in particular. From here I can calculate the intensity of a loop from Eq 1 in Longcope et al 2005. I'd just need to find the diameter of the loop (or guess at it). Or I could use the intensity from the stack plot to find the diameter. How useful is that though?   Currently I'm tinkering with EBTEL. I got a few things to work, but it's a massive program and I'm so lost in the code right now. Fortunately I have a pretty clear idea of what I want to do. I want to set several different heating functions, then note which ones give me a cooling delay of 30 minutes, roughly what we saw from the # loops v time plots. ******************Thursday July 21th********************* Ok the last thing I want to show is also an incomplete project, but I still think it's useful to see. Below are graphs of the northernmost footpoints of the loops I traced: 
 From here I want to get a hold of Jiong's footpoint data and see how well it matches/if it matches, with the motion of the ends of my loops. Friday, July 8th Ok so this has been a very slow two weeks. It took a long time for me to work out the coordinate conversions and the intersection programs. I'll start with where I left off in my last entry. The problem last time was converting the traced loops into a comparable format. The loops I traced store the coordinates in arcseconds from the center of the disk. However they only store it at the inital time I trace the loops. So they need to be shifted as time passes to account for the movement of the flare. The program I wrote to do this, named 'loops_to_arcsec', reads the FITS files and creates an array called shifted which stores the distance, dx, that the coordinates must be shifted. Another array called coordinates then takes the x coordinates of the loop and adds dx to them. This array is a little tricky since it's four dimensional. A typical output would look something like this: -486.362 ..... -484.900 83.5698.....83.5698  This is over the course of 34 minutes, and the loops are shifted roughly 5.5 arcsec per minute. Really I just wanted to show that the program is shifting the loops in the horizontal direction but not the vertical. And it shifts the traced coordinates the same number of times the slit itself is shifted. So I can compare the slit shifted 3 times to a loop shifted 3 times. From here I had both sets of coordinates, the coordinates of the slit, shifted with each time, and the coordinates of the traced loops, also shifted with time. I next wrote a program that found where the two lines intersected. I got incredibly lucky since I found a program written by someone at Johns Hopkins Applied Physics Laboratory. The program takes two points on one line, and two points on a second line, and then calculates where they intersect, if they intersect at all. I ammended this program to test to see if the intersection point was between the endpoints of the slit and the endpoints of the segments of the traced loops. I should explain more so that I'll remember myself. Essentially the traced loops are a series of straight lines. This program takes the slit, which is also a straight line, and tests to see if an infinitely long slit would intersect with that infinitely long loop segment. If it does, the program then tests to see if the intersection is actually within the limits of the finite slit length and the finite segment length. If it's not, then the program moves on to the next segment. If it is, the intersection is stored in an array cleverly titled 'intersect'. Again intersect is a complicated array, so I should explain. The first dimension is again the loop number, and the last dimension is the shift number. The middle dimension has 5 layers. 0 = loop num, 1 = segment number where they actually intersect, 2 = time at which they intersect, 3 = x coordinate of intersection, 4 = y coordinate of intersection. If the slit intersects the loops the program runs one final test to see if the loop was even formed at that time. If the intersection time is before the formation time of the loop, then the value is not saved in the array. Also if the intersection time is after the loop has disappeared, the value isn't saved in the array either. In the end, a typical output of 'intersection' would look like this:
print,intersect[27,*,250]
27.0000 10.0000 10.4168 1798.99 270.539  Here you can see the 27th loop is intersected between it's 10th and 11th point at 10:25 and the point of intersection is (1798.99,270.539) With the intersection information I'm now working on constructing a stack plot that will show the extent of the loops overlaid on the intensity. Once I have this I can withdraw indivual time graphs and identify which peaks match to which loops. Also on a plot like this I can simply read off the intensity at each pixel to find the intensity of the loop at said time. First though, I have quite a few loops that extended beyond the time set by pfl_stack, the program that withdraws the slit information and makes the stack plot. So I first wrote another program that extended the time out to the latest time I could with the FITS files I downloaded, which is almost 12. Below you can see the original plot and the extended one. I definitely think it was worth it.   Unfortunately, when I plotted the points over the stack plot I got the results below. As far as I can tell these aren't any comprehensive loops. They don't even seem to be over the bright spots.  It seems like some sort of coordinate problem. What I'm doing with my stack_plot program is creating an array of all the times and intensities. I then have to plot that with different axes, namely the time in hours along one side and the x distance from disk center on the other. To show it on these axes though I had to translate the x coordinate backwards in time to the x position at 8:24, which is on the y axis. I'm still very confused about the times here. I rolled all the coordinates back to 8:30 UT, but the x_cen and y_cen that I've been calculating dx and dy from is at 9:50. I have to tinker with moving the starting time around, but changing the starting time won't change which fits files any of the programs read, but it'll change the dx values, which are included in both the center array (in pfl_stack) and the coordinates array (in loops_to_arcsec). I'm wondering now if it'd be worth rewriting the program so the centers are originally at 7:30, the earliest time I have data for. Then dx should always be positive and the arrays would get larger as time increases. But the arrays I have now DO NOT do that. The x coordinates get more negative, then get positive. Which way makes sense? I want to say increasing because the sun rotates left to right, at least on the Solar Monitor Site. Another issue with the stack plot is illustrated below: 
You can see that the slit doesn't actually intersect a lot of the later loops, which would explain why almost none of them show up. It might be worthwhile to run two separate slit programs and create two separate stack plots. On the stack plot however there is a definite intensity reading at the later times, so some of the lower loops must be intersecting it. UPDATE: Stupid mistake, the later half of my coordinates array wasn't being filled in, so of course nothing intersected it. Here's the new stack plot: 
Pft yea problem solved, right? Also, I don't know how to combine my 3 structures containing the high,middle and low 171 loops into one structure. To overlay all my loops onto the stack plot I had to go through a little dance sequence of programs. If all the data was in one structure it'd be much simpler. However I couldn't get create_struct to do anything useful. Go figure. Ok I set the time back to FITS 237, which is 8:30, but since x_cen and y_cen have no dependence on time it didn't do much. Now the question is, what time is x_cen,y_cen for? Friday, June 24th To get the individual intensities for each loop I have to find out where the loops cross the slit. First I had to transform the coordinates of the slit. They were originally coordinates along the slit, specifically the distance from the slit center. Since the slit was tilted at about 60 I just had to do some trig to get the x,y coordinates in arcseconds. The issue was that the slit itself is repositioned every few hours to compensate for the sun's rotation. So the center of the slit moved. I made a new array containing the shifted centers and calculated the coordinates for each of them as well. Now the task is to convert the loops to the same coordinate system. Here I have the coordinates along the loop, but those coordinates change with time, so I'll have to do a similar transformation. In the end I want to see where the loops I traced intersect with the slit. Then I can match the intensities to a particular loop, and calculate more loop properties such as time delay, lifetime,electron denstiy,radiated power, emission measure, etc Wednesday, June 22th I'm running into a wall with intensity. To calculate the time delay I need the electron density, and to get a solid number for that I need the intensity of any given loop. Plus the paper I've been working from is really focused on calculating the abundance of iron, which I don't care about and have no clue how to get it. So I've decided the best thing is to move on and just try to get information from my data instead of from weird calculations. I still don't know how to connect a 335 loop to a 171 loop, but I've been going over Longcope 2005 et al and they use stack plots extensively. I can make a stack plot for the 171 data, although I'm not sure if pfl_stack.pro is doing all the same things as the program used in the paper. The stack plot is below: 
As far as I understand it, this stack plot is a plot of the intensity across a narrow slit from 8 to 11.The next thing I'm trying to do is separate out time slices from the stack plot so that I can get intensities for individual loops. In the 2005 paper this is done and peaks are identified automatically. I'm not sure if I have a program to do that, but if I can figure it out I'd have a way to get intensities for any number of loops I traced. I'm not sure what I'll be able to do with that information, but something will come up. Monday, June 20th Ok let's recap where I'm at. I've been reading a paper by Aschwanden from 2003 and I'm trying to relate my data to the data they calculated for several other loops. Dana looked at my plot of loop length against lifetime and realized that there was no dependence, meaning that the loops were cooling radiatively. That's actually to be expected since the temperatures we're looking at are 1-3MK, sort of beyond the range for conductive cooling.If we take a quick look at the equations below (taken from Dana and Aschwanden): 
You can see that the radiative lifetime has no dependence on length, just like the graph shows. Essentially at 1MK we have a higher electron density since more things are ionized, i.e. more things are radiating. I'm now trying to calculate the radiative cooling time, or how long it takes the loops to cool, and the time delay, which is the time between seeing a loop in 335 and then in 171. I've been looking at a ton of papers besides just ASchwanden et al. 2003, like Longcope 2005, Ashwanden 2000, even Rosner 1978. I'm also making a ton of assumptions to be able to get an actual number for the cooling time. I'm going to attempt to list them just so I have them down somewhere. Firstly, when I convert length from arcseconds to Megameters I'm assuming the sun is flat and not taking into account the radius we see is forshortened because of that. Secondly I'm assuming everything in the corona is fully ionized. So the number density of hydrogen is the same as the number density of electrons. Third, I'm taking the radiative loss function to be a constant, just as they do in Aschwanden et all 2003. Next, the cooling time is essentially the radiative cooling time. I'm ignoring any cooling due to conduction. Again, as they do in Aschwanden et all 2003. Lastly, I'm going to first assume the number density of electrons is just a billion, but I can tweak this later using equation 1 in Longcope et al 2005. I need to first find the response function of AIA ( I'm going to ask Dave for that), and use the bresenham programs to get a guess for the intensity. I'll be able to do a lot with this data, but my true goal is to plot delay time against length. According to the theory this should be a linear relationship. Meaning longer loops should have a longer delay. It's just a real ordeal to get that delay time. I'm having all sorts of issues estimate the abundance of Fe in the loops. I'm just aiming to do it for 5 to 10 loops. I don't know if I'll be able to write a program that does this for every loop I traced. That's over 200 just for the 171 data. Oh also, before I forget, I need to find some way to match the loops in 335 to the loops in 171. I should ask Dana cause I can't think of any obvious way to link them. Lastly I should say that I updated my loop_lifetime program so that it displays the following histograms: 
It also spits out the median and average lifetimes and lengths. I'll reproduce those here: Median Lifetime - 0.223 hours Average Lifetime - 0.303 hours Median Length - 63.02 arcsec/86.19 Mm Average Length - 69.88 arcsec/95.59 Mm Thursday, June 16th Ok well this was something of a tedious week.I went through mos tof the 335 data and traced a lot of loops, but I'll have to go back and sweep through it again. The data just didn't seem as good as the 171. Speaking of which, I did go back and edit loops in the 171 data, just making it cleaner and simpler now that I have a better eye for the loops and a better understanding of the program. I think that turned out very well, I now have 215 loops for the 171 wavelength. I also had great success today writing my program that would plot the number of loops against time. It took me a long time - a lot of sitting and contemplating what I actually needed from IDL- but in the end I have a decent plot. You can see after 12:00 all the loops are pretty much formed. Or at least that's where my data cuts off. See below: 
Monday, June 13th None of the advisors are here this week so this'll be something ofan adventure. So far I have a plot of length against the time of formation for all the loops I traced in 171. There might be an easier way to create the plots, but whatever. The program I wrote does what I want it to do so I'm happy. I also made a quick plot of loop length v. loop lifetime. This seemed to suggest that longer loops lived longer, but some points were all over the place and there were plenty of outliers. My tracing technique may be off and that could easily skew my data. On that plot I don't really know what I'm supposed to get so I can check my data for errors. Today was a bust in two respects though. I'm still trying to create a plot of number of loops v. time, which is related to the flux. I've run into all sorts of problems trying to plot that though. I sent Dana a fairly detailed email. Hopefully he'll get back to me. When that hit a dead end I decided to trace lops for the 335 angstrom data. This worked out ok, but the 335 images were really pixelated and I couldn't get an image to come up of the entire field. I just guesstimated and picked a decent portion of the flare. The loops are a lot broader and a lot fuzzier on this wavelength. I'm not sure if that's something instrinsic to the 335 angstrom, or if it's a problem reading the files. regardless it's something I can do without help and it's something that needs to get done. So if nothing else I can trace another wavelength this week. Ok here's my graphs: 
 Thursday, June 9th So this week I've been drawing loops using loop_tool. Here's a quick screenshot: 
 These are images of coronal loops taken by the AIA ( Atmospheric Image Assembly) on board the SDO (Solar Dynamics Observatory). AIA takes pictures every 10 seconds at 8 different wavelengths of UV. The first picture is a blow up of a large section of the sun, which I then have to zoom in on. The loops I've been drawing this week have all been at 171 angstroms, which is radiation from Fe IX, that's iron that's lost eight electrons, which corresponds to around 1 million degrees Kelvin. In the future I'll be tracing loops for the 335 angstrom emissions, (Fe XVI ~ 3 million Kelvin) and 94 angstroms(Fe XVIII ~ seven million Kelvin). If Dana thinks it'll be useful I could also download the 211 angstrom images and take a look at them. As of now though we already have the 335 and 94 data on hand. Unfortunately I have a lot of work to look forward to next week. I'm planning on making graphs of loop length v. initial time of formation, which will hopefully show that in the early stages of the flare short loops form, and then progressively longer loops follow. I'll also be calculating the overall lifetime of the loops I've traced. I still have to figure out what I'll use that information for, but I know it'll come in handy at some point. It'll also be crucial to plot the number of bright loops against time. The number of bright loops is roughly equivalent to the flux (up to a constant), and so a plot like that will give us an estimate of the flux, which is what we really want. Of course to get a true estimate we'd have to take into account the cross-sectional area of each loop, but I'm totally going to ignore that until later in the summer. Since Dana will be away next week I just want to make sure I have enough work to do. It'd be terrible to hit a dead end Tuesday and be spinning my wheels all week. Monday, June 6th Wow busy day. So Dana arrived back in Bozeman and I had a meeting with him. He explained all about the project I'll be working on, how the magnetic field reconnects and snaps downward, producing footpoint emission. It was a lot of material in a short time, so hopefully after a few days I'll be more clear on the ideas. What I've actually been doing is tracing more loops in the AIA data. I'm mostly getting a feel for what constitutes a loop and what doesn't. It's hard to be distinct because there are SO many loops in these pictures I can't possible trace them all, but at the same time they're different enough so that bunching them together into one group doesn't make sense. I've already restarted tracing twice, and I'll probably have to one more time. I also looked up info today about NASA's SDO, and AIA specifically. It's helpful knowing what I'm actually looking at, but I'm still fuzzy on the big picture. Tomorrow Dana is meeting with his grad students and REU students, so hopefully that will make things clearer. Friday, June 3rd Ok just got the website up and running today so I suppose I'll give a rundown of what I've been doing so far. I've been working with Silvina Guidoni, one of Dana Longcope's graduate students while Dana is out of town. She has me using a program Dana wrote called loop_tool to trace magnetic loops in the corona from a solar flare on August 1st of last year. Here's a quick video of the flare via NASA's SDO website: Aug 1st 2010 Flare 94 and 335 angstroms have particularly good flares. I figure for good measure I should include the magnetogram. 
 The active region is 11092, and the flare is a C-class flare. It occured between roughly 8:30 and 11. Lastly, here's the Xray flux from GOES. The flare stands out quite clearly. Although I admit I don't understand everything about this graph. Particularly the difference between the red and blue lines. 
As an exercise in IDL, I had to write a program that would measure the lengths of the loops I traced. It wasn't difficult, just a matter of using Pythagoras to find the distance between two points, and then summing up those distances. However it was much easier to say that's what I want the program to do than to actually write the program that did it. I've also been reading an article that Dana wrote called, get ready for it, "A Quantitative Model of Energy Release and Heating by Time-dependent, Localized Reconnection in a Flare with Thermal Loop-top X-ray Source". Yea just some light reading. I'm focusing on understanding the Abstract and Conclusion. I figure most of the important general ideas will be in there. OK more to come on Monday, when hopefully Dana will be back. |