DAILY LOG

Home

Final Presentation


The Big Picture Forever

August 2, 2007

As of today, my portion of the presentation is temporarily done.  You can view it here.  Clicking one of the other links will ultimately take you to dead links because Peter doesn't have all of his cells done.  I'm sure it will begin changing as of tomorrow though.

August 1, 2007

Wow.  August.

But I've merely been progressing on the presentation.  It can be checked on via the link here or on the homepage.

July 31, 2007

Finally have started piecing together the presentation, and I've included a link to it at the top of the log here and the home page.  Right now it's missing Peter's part of the presentation.  So, it just jumps from the first slide to my part of the presentation.

Put together movies finally with active flare regions on top of the MDI with the HXR contours on top.  Took me a while to figure out how to get it all on there without looking like trash, but I think it finally gets across the point Jiong wanted it to.

M2 Band
H Band

Also, I put together histogram plots to show the flux generated in the HXR regions compared to the total reconnection flux and the cell with the second highest generating flux.  That's a bit wordy.  But:

Positive Flux
Negative Flux

Anyways, I'm just hammering out my final presentation now.  It's kind of relieving.

July 30, 2007

I've just been outputting images and movies for the presentation today.  Tomorrow, I'll start piecing stuff together in a slide show and writing up notes for it all.  And once I get done figuring out whether the stuff I'm generating is junk or not, I'll post it.

July 27, 2007

Okay, I cleaned up the contour lines by inputting some keywords to define the contour levels and have tried picking out the cells I can see involved where the hard x-ray points are.  So, without further adieu, I present a table.  In it you will also find the cells picked out where the hard x-ray points lie and the comparison of flux rate for that time frame to them.  For the hard x-ray contours, the links from yesterday's log have been fixed to go the proper contours.  Also, the flux is [Mx/s] and the time is minutes after 10:00 UT.  I just ran out of space in the table:

TRACE Time
HXR Time
HXR Cells
Recon. Cells
HXR Flux (P/N)
Recon. Flux
Ratio (%)
19:01-20:09
19:50-19:58
P: 3
N: 4,6,9,14
P: 2,3,4,9
N: 4,6,9,11,12,13,14
1.27e21
2.04e21
2.92e21
3.77e21
43.5
54.1
21:20-22:26
21:40-21:48
P: 3
N: 4,9,14
P: 2,3,4
N: 1,4,7,9,12,14
2.40e20
3.28e20
6.11e20
4.90e20
39.3
66.9
24:10-25:17
24:08-24:16
P: 2,4
N: 4,5,12,14
P: 2,3,4,7,9
N: 1,2,4,5,7,8,9,11,12,13,14
2.78e21
1.18e21
4.22e21
3.05e21
65.9
38.7
26:56-28:01
26:58-27:05
P: 4
N: 1,2
P: 2,4
N: 1,2,5,9
6.50e20
3.15e20
6.86e20
3.97e20
94.8
79.3
28:01-29:47
29:08-29:16
P: 4
N: 1,2,9
P: 3,4
N: 1,2,4,5,7,9,10,14
1.71e21
1.07e21
1.75e21
1.92e21
97.7
55.7

July 26, 2007

And with some help from Jiong this morning, I got the hard x-ray data over my MDI stuff.There are overlays for the following times with each time period being a flux rate or photon count peak and represent the time of the hard x-ray data.  The MDI image is of course set at 9:36 before the flare begins:

Peak Type
Hard X-Ray Time
Bands
Photon peak 10:19:50 - 10:19:58: M2, H
Photon peak 10:21:40 - 10:21:48: M2, H
Flux rate
10:24:08 - 10:24:16: M2, H
Flux rate and Photon
10:26:58 - 10:27:05
M2, H
Flux rate
10:29:08 - 10:29:16
M2, H

And last, a movie of the stages and reconnections picked out by Jiong's program with the active parts of the flare during a stage brightened (yellow).


July 25, 2007

Been working with the hard x-ray stuff.  I figured out that my stuff from yesterday was wrong.  In so many words, I just wasn't aligning them properly with regard to area to each other.  Which also brings me to the conclusion that I need to see if it's possible to make the program that creates my hard x-ray images to increase the area of the disk it picks up as I think I've concluded that the reason why I can't see the hard x-rays in the M2 and H bands in my seconds peak isn't because the coordinates are off (as the L band is aligned with the SXT), but because the flare footpoints have spread farther apart in area than the area shown to me in the image given to me by the program.  I'll inspect that tomorrow.  However, I did manage to get the coaligned images for the H band and the M2 band.  I took a screen capture with the magnetogram marked with arcsecond coordinates to give an idea of its location on the active region as the overlayed map doesn't give too much of an idea itself.  If you'll notice though the hard x-rays are coming from what are regions P2, P6, N4, and N14.  And those regions are all reconnecting at that point in time.  Though, I'm not entirely certain how the two minute lapse between the flux reconnection peaks and the hard x-ray peaks play into this.  And because of where the hard x-rays are occurring, I couldn't try to determine that because of those peaks, it is referring to one flux reconnection peak or another because those cells are active in several peaks.  That may not make sense, but I may very well be speaking gibberish presently.

After figuring that stuff out, I played with Jiong's program that finds the reconnection sequence and because it tends to give me reconnections like this due to my large number of cells, I decided to make it output text to me telling me the reconnections, which was just a bit trickier than I thought it would've been.  So, here it is in a text file format broken into stages that the program picked out:

Stage 1
Stage 2
Stage 3
Stage 4
Stage 5

And just in case, a color map.

I really considered formatting the text files, but then I realized how late it was getting and tired I'm getting and how painstaking formatting text files is and said, "This will do for now.  You can do that later if necessary."  But looking at the cells it's picked out for reconnection, it agrees quite well with what I've picked out.  So, the program seems to work pretty well.  I would seriously need to limit the correlation cut-off and flux cut-off as well.  I haven't looked to closely at the rest of the program though.  Anyways, that's all for now.

July 24, 2007

I think I've got the hard x-ray overplotted on my MDI for my first hard x-ray peak at 10:22.  The M2 band and the H band.  I'm not a hundred percent sure that they're plotting dead on.  While the hard x-ray in both plots for the positive region appears to be exactly where I expect it to be, the contour in the negative region doesn't seem be where I think it should, but I could be wrong because I don't have the flare outline on there.  Anyways, when I tried plotting those contours properly over the TRACE data, I ran into a few more problems.  I'll try dealing with those tomorrow. 

The other problem I found was with the second hard x-ray peak at 10:27.  The HXT data I'm generating doesn't look right in anyway.  After figuring out that I should get the HXT coordinates of the flare from the SXT data and working wonderfully for the first peak, it doesn't seem to work at all for the second with the exception of the L band.  I'm not really seeing any activity in the other bands.  ie:  H band for 2nd peak, and the proper looking L band for 2nd peak over the SXT images.  However, I'm not sure how to attack that problem yet.  As I have an idea of you how it should look and the fact that it's not looking like that, my inclination is to say that the coordinates are incorrect, but I fail to see how there could be that much shift in a span of five minutes.  I'll play with it some more tomorrow.

July 23, 2007

Today's been spent trying in vain to get the my HXT data to contour overplot onto TRACE data for my flare.  The problem has seemed to come from when I try to create a map from my index and data files on HXT.  The HXT data doesn't really enjoy having its position converted into arcseconds from its HXT coordinates.  In fact, it hates it so much that it decides that its position is no longer on the solar disk.  Thus, when I try to overplot HXT on the TRACE centered at about (15,240) in arcseconds, the HXT centered at about (-5000, 20000) in arcseconds unsuprisingly doesn't overplot.

Working with some conversion programs that converted HXT coordinates to SXT pixels and then to arcseconds on the day of my flare did yield the position the map I created did [(-5000, 20000)].  So, it seems something is askew in the conversions or something because I'm assuming that my HXT coordinates I'm gaining from flare catologues are correct. 

Though, in my search of trying to solve my problem, I found a paper, "The Magnetic Structure and Generation of EUV Flare Ribbons" by L. Fletcher and H. Hudson, where they contour plotted the M2 band over 195Ǻ TRACE data for my flare, and the M2 band does indeed seem to be over the largest regions of reconnection that I've picked out.  Since the TRACE isn't at 1600
Ǻ, I can't really tell for certain which of my corresponding cells the HXT footpoints fall on.  So, hopefully, I'll finally get it right tomorrow.

July 20, 2007

Jiong wrote a program to analyze reconnection sequences.  The output thus far is a reconnection sequence plot.  I'm kind of writing out a way to make that display sensible, but today's one of those days when my brain doesn't want to cooperate.  Beyond that, I'm still working on the hard x-ray stuff, but again the brain's not working today, and my progress is going slow.  This weekend I'm going to try to coalign the HXT data to the MDI data (because my TRACE stuff is coaligned with the MDI) and hopefully get that done and finally see the hard x-ray stuff over the TRACE flare.

July 19, 2007

Okay, generated the correlation and flux rate plots with the new defined periods.  I also realized that to make the sequence chart to look a little bit neater that I could raise the flux cut off rate and limit the number of cells analyzed in the diagrams.  So, as a result:

Flux rate Plot (which hasn't actually changed other than the lines defining stages)
Correlation Plot
Correlation Sequences

Also, I overlayed the hard x-ray counts/sec on top of the flux rate plot.  The units obviously for the hard x-ray plots obviously don't mean anything in this plot, but it shows how the peaks coincide with the reconnection peaks.

I made images of the hard x-rays centered around their peaks (10:20 - 10:25).  So, the first peaks at 10:22 in their bands:
L
M1
M2
H

And peak at 10:27 ranging 10:25 - 10:30 in bands:
L
M1
M2
H

Tomorrow, I'm going to get them properly aligned using the SXT data and then try to overlay them on the color map and try to see if it bears any semblance to my flare.  At first glance, it seems that the lower energy levels correspond to the flare beginnings, and the higher energy levels correspond to the location of larger flux generation.  I'll see what tomorrow yields.

July 18, 2007

I debugged the stages program this morning.  I had to spend some time altering parameters and whatnot, but it gave me results that were pretty dead-on to what I came up with by looking at the graphs.  The flux rate plots for reference and a table:

Stage
My Times
Program TRACE Frame
Program Times
Pre-impulsive
10:02 - 10:20
71:98
10:03 - 10:21
Impulsive
10:22 - 10:31
98:114
10:21 - 10:31
Secondary Peaks
10:31 - *
114 - 132
10:31 - 10:42

On Jiong's suggestion, I tried writing it so that the peak occuring at 10:18 ends up included in the impulsive stage instead of the pre-impulsive stage, but I just couldn't get the program to do it without changing the logic that went into writing the code or using nonsensical multiplication factors.  I need to run these numbers through the correlation programs, but I want to take a break from these programs and look at the YOHKOH stuff again.

And rather unfortunately for my soul, my .cshrc file was missing several start-ups, including the one that contains the software for YOHKOH's HXT data.  So, I've spent my afternoon trying to fix that, and just did.  I'll take care of the HXT stuff first thing tomorrow and get an overplot there.  Then, I'll get my correlation maps and plots created.

July 17, 2007

First thing I've done is actually take the magnitudes of flux rates for my given sequences.  First, I manually calculated the total flux rates for the cells I've noted as being involved in the reconnection.  That gives me the following:


Time
Max Pos. Flux (Mx/min)
Max Neg. Flux (Mx/min)
Peak Time
10:22 -10:25
1.71e21
1.36e21
10:24:11
10:25 - 10:28
7.11e20
7.76e20
10:26:24
10:28 - 10:31
7.87e20
8.32e20
10:29:11

I then ran it through with all the cells to try to get a better account of the total generated flux rate as opposed to my more simplistic view of the reconnections:

Time
Max Pos. Flux (Mx/min)
Max Neg. Flux (Mx/min)
Peak Time
10:22 - 10:25
1.72e21
1.47e21
10:24:11
10:25 - 10:28
7.76e20
8.67e20
10:26:24
10:28 - 10:31
8.08e20
9.21e20
10:29:11

So, if the hard x-ray data matches up with the two largest peaks in the tables (the ones at 10:24 and 10:29), then the hard x-ray peaks  occur before both of the flare peaks.  If you recall from yesterday's work, the first peak in the hard x-rays occurs at 10:22:43 (from the H band).  The supposed corresponding flux peak occurs at 10:24:11.  That gives a difference of 88 s.  With the second peak, the hard x-ray is at 10:27:03 (this is again from the H band).  With the flux peak at 10:29:11, that's a time difference of 124 s.  So, by my assumption I've made here with the larger peaks in flux corresponding to the closer hard x-ray peak, there's something to be had between these flux rates and hard x-ray peaks.  The next thing to do is look at the location of the hard x-ray footpoints relative to my ribbon footpoints.

Okay, I've begun reworking my program to determine the flare stages.  I talked to Jiong today, and I'm going to try a different approach this time.  What I'll do is find the first peak that occurs in my "flare" range that will be up to the user to define.  I've left it so the program still has to work to find the supposed beginning of the flare so that the user can also come up with a threshold value for the minimum that the peaks drop in order to define a stage's ending/beginning.

Then, I'll find the range that one peak occurs in.  I'll then take all the cells that have peaks during that range and come up with a range that encompasses all of those peaks and the time that they go past the previously mentioned threshold.  Hopefully, attacking it this way will rid me of the patch solutions I contrived involving statistical modes and whatever else I've previously done.  Anways, I just finished writing the code for it, and to save myself from a painful night of determined debugging, I'll start that process in the morning.   I've actively been trying to channel my Fortran programming days and make the code as automated and efficient as I can without forcing the user to go into the program to change any code.

Also, Jiong showed me a few programs I can use to look at the hard x-ray data and gave me a book full of YOHKOH flare data.  So, to quench my curiosity, I plan on looking at the hard x-ray footpoints at some later point.

And last thing I did today was take Dana's suggestion from last Friday's topology meeting and re-did my helicity graphs.  He suggested by looking at this pretty incorrect one with the following legend that it looked as if the dashed line from the model appeared to be twice the LCT velocity braid helicity:

solid line = total helicity from LCT velocity
(+) = total spin helicity from LCT velocity
(x) = total braiding helicity from LCT velocity
(*) = sum of total braiding and spin helicity
dashed line = braiding helicity from the mask files (ie: smoothed poles model)

Well, I tried that correction factor of one half and found the braiding helicity from the mask files kind of fixed itself.  So, at some point it may be worth looking into the function programs, "parr_model" and "parr_helicity" to see if there's just some weird typo that magnifies the theoretical braiding helicity by a factor of two. 

July 16, 2007

Produced the color map with spine lines plotted over it.  I tried altering Jiong's program she wrote for this to get it into the color map I've been producing with the MDI right next to the color map as opposed to the color map on top of the MDI, but I failed, or better yet, realized that it was taking me way too long to do.  So, that link is what I have for now until I take some extra time and get the image the other way.

Anyways, the point is that it's pretty clear that the spine lines go right over the main ribbons of my flare with the exception of those negative spines up near the northern region of the map.

I started looking at the YOHKOH hard x-ray data for the flare.  So, first of all, links to the graphs:

L:  14 - 23 keV
M1:  23 - 33 keV
M2: 33 - 53 keV
H:  53 - 93 keV

So, the peaks I found in each of those graphs kind of correspond with my graph.  I say kind of because the peaks from the hard x-rays precede my peaks in the flux rate by 1-2 minutes.  As in, my flux rate has a peak at 10:24.  The hard x-rays have a peak at 10:22.  Same instance with a flux rate peak at 10:28:30 and a hard x-ray peak at 10:27.  However, I have more flux rate peaks than hard x-ray peaks.  During 10:22 - 10:31, I measure three flux rate peaks and only two hard x-ray peaks. 

Furthermore, I have peaks occurring at 10:20 UT for the L and M1 bands at 10:20.  I have a corresponding flux rate peak at 10:18, but that's not matching with the trend I have in the above paragraph.  According to it, I should have a hard x-ray peak at approximately 10:16 or so, but there's no data for the times of 10:13 - 10:19.  So, I can't check against that.  Anyways, that peak there also indicates to me that there's a high photon count in the lower end of the M1 band during that 10:20 time frame.  The peaks in the above paragraph occur across the M1, M2, and H bands though telling me that there's a higher photon count at the higher end of the M1 band, which matches with my description of the sequences I made based on the flux rate with the first main sequence ending at about 10:20. 

The most unfortunate part of this is that the missing YOHKOH data is keeping me from seeing if the hard x-rays are reflecting the sequences of the flux reconnections.  I would like to say so, but I can't be certain.  Tomorrow, I want to look at the images of the hard x-rays and see how they evolve on the solar disk and see how they relate to my flare evolution, and if the hard x-ray footpoints match with my flux cells that are active during a given sequence.  Beyond that, I should compare the flux rates for my defined sequences to see which ones are the highest reconnection rates.  Then, with information on those two things I might be able to draw some connection between the hard x-rays and reconnection rates. 

July 13, 2007

Friday the 13th...

But I put together plots of the magnitudes of the flux time derivatives during each of the main sequences I picked out yesterday.  They're not perfect, but they're all fairly close. 

10:02 - 10:18
.  The left graph is 10:02 - 10:06.  Middle is 10:06 - 10:10.  Last is the whole period 10:02 - 10:18

10:18 - 10:20.  This is the "big" marking the territory phase, as I like to call it.

10:22 - 10:31.  Left is 10:22 - 10:26.  Middle is 10:26 - 10:28.  Right is 10:28 - 10:31.

10:31 - 10:43.

The cells involved in the sequence's reconnection are placed in the legend at the top.

July 12, 2007

Today, I looked some more into the reconnection sequences of my flare.  I did a screenshot of all the stuff I was looking at for this.  It kind of gives a bigger picture and idea of the flare.  So, I'll try to give some idea of what's going on with the flare:
  • 10:02 -10:18  (Making out the flare region)
    • 10:02 - 10:06
      • On the far right, reconnection begins with (P8):(N6,N11)
    • 10:06 - 10:10
      • Reconnection in that region begins to include more positive cells to have (P1,P5,P8,P10):(N6,N11)
    • 10:10 - 10:18
      • Then moves down the left side to mark out that component of the flare with (P2,P3,P6):(N5,N13)
  • 10:18 - 10:20
    • Seems to be marking out what will soon be the major flare region along the ribbons similar to the first part, but flux time derivative is such a larger magnitude.  (P2,P3,P4,P9):(N4,N11,N12,N13,N14)
- A break occurs right here.  It's almost like the calm before a big storm.
  • 10:22 - 10:31 (Major flaring section)
    • 10:22 - 10:26
      • The big peak of the flare.  We have reconnection (P2,P3,P4,P7,P9):(N1,N2,N4,N7,N8,N9,N11,N12,N13,N14).  It appears to completely follow along the two main ribbons (maybe explaining hard x-ray ribbon observation)
    •  10:26 - 10:28
      • Begins slowing down a bit now.  The positive cell reconnection is mainly with P4 now, but still rather akin to the whole ribbon idea:  (P4):(N1,N2,N5,N9)
    • 10:28 - 10:31
      • Maintains a peak the same the period just above, but spreads across tons more negative cells to be completely along the negative part of AR:  (P4):(N1,N2,N4,N5,N7,N9,N10,N14)
  • 10:31 - 10:35
    • Seems to be pretty much done at about 10:37.  Just kind of resting after 10:35 with little activity, but continues completely along the negative AR:  (P4):(N2,N9,N12,N14)
I think it's pretty interesting how the flare literally ribbons out, but first must kind of mark its territory.  Almost like it must relieve some of the stress of the active region all over before it can begin releasing even more massive amounts of energy through reconnection.

I tried throwing together a .eps file with the color map and the topology map produced over the TRACE from yesterday.  But I ran into problems getting Dana's program that plots the topology to work with my programs.  So, the best I could do using Dana's programs was to get the topology over the MDI data this time around.

And until I have time to properly figure out how to get the topology map over the color map, I have placed them side by side for comparison with another screenshot of mine.   There appears to be a spine along the ribbons I was mentioning above.

July 11, 2007

This morning, I've concluded that there is a certain threshold that you can reach concerning merging cells.  In the "lct2pns_adv.pro" program, the saddle keyword is the one that effectively merges cells.  I believe it does this by comparing cells that border each other on saddlepoints.  Anyways, at least for my flare's active region, that threshold is about 500.  If I start going above that, it starts to merge cells that look like they should be separate and giving large regions rather incorrect values.  The downside to this is that I have twenty-six cells to look at for reconnection that way.

So, the tessellation map.  If you look at the region labeled P01 located at about (0, 225), it's value is rather close to zero, and that agrees with tessellation maps created before any merging was done.  There is simply a cell with very small magnetism measured there.  If I do any more merging because that cell engulfs P04 directly to the left of it giving me a huge region with little flux which isn't good at all for very many reasons.  All these reasons are mainly related to the fact that P04 is a rather active during the flare. 

If I look first to the flare map for this given tessellation map as a reference to the cells and where P4 is located on it.  It corresponds to the P04 in the tessellation.  P2 corresponds to the P01 in the tessellation.  Looking at the flux rate plots P2 isn't as active as P4 later in the flare.  So, it just sehttp://solar.physics.montana.edu/REU/2007/nhill/images/trace/helicity.jpgems that breaking that 500 threshold for the saddle would yield too inaccurate of a result.

Last I can look at reconnection sequences.  Certain parts of it look like gibberish at the 20-30 time frame because so many things are overlapping.   My guess is that just several cells are reconnecting at a given time and consequently have about the same measured correllations.  If I blow up the image though, I can see that it looks to be cells P2, P4, P12 reconnecting with N12, N4, N8 and probably more cells along those positive and negative ribbons seen in the flare map.  That might correspond to the ribbon hard x-rays that Jiong told me were observed with this flare.  Last I can look at the correllation plot, just to get a better idea of the actual reconnections. 

As for this afternoon, I've taken to looking at the topology of the flare.  Masha showed Peter and me how to get the footprints, nulls, and poles.  So, for the two following images, I quote from Dana's header that calculated these things, "Footprints are shown as dashed and solid lines.   Solid lines denote photospheric spines, dashed lines are  the footprints of separatrices. dotted lines are the spines of coronal null points."  I quote as I have not yet picked up on the terminology of this part of topology.

Anyways, I successfully managed to produce two overlays  with the TRACE data.  This is TRACE at 171Ǻ
with the mentioned overlay.  And TRACE at 195Ǻ.  The times at the top of the charts refer to time of the TRACE image.  The topology overlay is from my MDI mask file from 9:36 UT.  So, at 171Ǻ, there is a time difference of about 13-14 minutes.  At 195Ǻ, there's maybe ten seconds difference.  Though, I don't know how long the exposure for these ultraviolet wavelengths are on TRACE.

Lastly, one final plot to measure the helicity.  The solid line is the total helicity measured with the LCT velocity.  (+) marks the total spin helicity and (x) the total braiding helicity.  The (*) marks the summation of the spin and braiding helicities.  The dashed line is the braiding helicity from the smoothed poles model, which is the data coming from the tessellation program, and there appears to be discrepancy.

Also, something I have recently noticed that I may have to go back and fix.  When I assigned titles to the cells in programs I used after producing the tessellation map, I gave them numbers in counting order without holes between them (ie: 1,2,3,4,..) because I just thought it looked nicer.  It wasn't a problem until now when I start looking at the topology because they are assigned their names from the cells in the tessellation program, and it would be troublesome to fix all of these programs.  That'll be an easy fix though, as I changed the code in the aforementioned programs easily.  Anyways, that's all for now.

July 10, 2007

Went through the data that came out of running the flux rate program.  It was mostly okay with the exception of one cell that was merged to have flux close to zero, which was clearly not right.  So, I emailed Masha, and she suggested some parameters to change.  So, I've done that.  Then I'll look at the tessellation maps when they're done being produced and see what comes out to be the most accurate. 

Beyond that, I rewrote portions of the program I spent all of last week on.  It seems that with correct data, my original idea for defining the period worked.  It tends to define to two main sequences instead of three, which I kind of forced it to do earlier.  I ran Peter's flux data through it, and it produced times for the two main sequences of his flare.  So, the program seems not to be complete rubbish. 

I again had the problem of cells going missing in my flare evolution maps.  I created a map with my flux data that I produced late last night and P1 went missing.  I again went through the code to find the coordinates, and they weren't even on my MDI image.  Where it should be looks to be where I have that one cell with flux close to zero.  So, I'm thinking that an improper cell merging causes cells to go missing.  Maybe?  I'll see once I get these new tessellation maps.

So, I'll make a list of things I wish to get done by lunch tomorrow to give myself some goal:
- Go through tessellation maps and decide which is most accurate by comparing it to data in 'msk55.sav'
- Run chosen map through flux rate program
- See how many cells I have and hope it's reasonable
- Create flare evolution map and hope that no cells magically go missing
- Define the sequence frames
- Run all of that through the sequence program to get plots of reconnection

July 9, 2007

First thing I did today was go in search of the mysteriously missing cell N13 from my evolution map and to relocate P4 in it as well.  I found P4 with no problem.  N13 was a bit more elusive however.  So, I manually went through the code that generated its (x,y) coordinate location and found that the calculations gave me a location that isn't even on my MDI map.  So, just by looking at the flux rate plot and the flare evolution map, my guess is that N13 is that whole location where N1 is located since N13 seems to reconnect from beginning to end of the flare, and that region seems to not be accounted for by N1 flux rate plot, but would by N13's flux rate.  I'll need to ask Jiong why the coordinates I'm getting for N13 aren't sensical.

Anyways, I then tried lowering the threshold for the positive cells  that determines what cells to look at from the flux variable that comes from the flux rate program, to 1e20 instead of 1e21 (that's Maxwells).  The idea was that maybe there was some conglomeration of positive cells that were being ruled out by that threshold that were contributing to the reconnections in the flare's start (around 10:03 - 10:09), since positive cells weren't being seen reconnecting during that time.  I got one new positive cell, which shows up as P8 on this map.  Conveniently, it's flux rate (time derivative) changed at the same time as the negative cells did.  So, within that time period, I looked at N7, N8 and P4, P6, and this new P8.  The total flux generated between the positive cells and negative cells during that early time frame is off by a magnitude of 10  (negative cells = 5e21 Mx, positive cells = 3.4e20 Mx). 

Well, then I start considering the fact that there have to be some positive cells somewhere that I'm not seeing because flux has to come from some positive cell somewhere to go into a negative cell!  And I'm just seeing these negative cells with mysterious flux levels.  So, my next guess is to look back at my tessellation maps because a few weeks ago I had to try to merge cells because there were just too many to deal with.  That's where I found my problem.  This tessellation map was the one that generated too many cells.  It noticeably takes into account the whole active region but has numerous cells.  This tessellation map was the one that's been used in all the stuff I've done in the past week or two or so.  It clearly is lacking portions of the active region.  And I'm imagining that's where my positive cells are.  When I changed parameters to try to get the cells merged and to a manageable number, I didn't think to look at the tessellation map and was happy with the decreased number of cells. 

Now, I have programs running that will take a few hours to finish running to give me new tesselation maps.  After running these programs with just one MDI image, I figured out the right variable to change to make cells merge is the "saddle" keyword.  By increasing it, cells merge like magic and don't eliminate cells, like I did by adjusting the "bthr" keyword.  Anyways, as soon as the programs are done, I'll look to see which parameter gives me the best image and run it through the flux rate program and pick up my work with correct/unskewed data.

July 6, 2007

Finished incorporating my program into Jiong's program and fixing graph parameters and whatnot for my data.  That was actually the entirety of my day.  So, the graphs:

Correlation Plot
Correlation Sequence
Flux Rate Plot

When I did my analysis for this, I cut out more, what I deemed, unimportant cells.  Looking at the flux rate plot, it definitely seems like there are certain cells more active in reconnection than others, but just from that graph it's quite easy to see what graphs are reconnecting.  Both of the correlation graphs get quite cluttered though because there are so many cells, and the program seems to have grabbed all the cells reconnecting during a reconnection.  But if I look at my log for June 26, 2007, where I gave the first groundwork of my flare evolution before I started cutting them off, the program seems to have grabbed everyone of those reconnections approximately above the 75% correlation line in the sequence graph.  So, putting the threshold at 75% for the correlation gives me the following sequence and makes things slightly more readable:  Sequence at 75%

The one thing that I might need to consider is the fact that all my reconnections are quite focused between fifteen and thirty-five minutes, so maybe some reworking of my program to define the sequences needs to be done.  It seems to be mostly accurate though.

July 5, 2007

Continuing work on the program, I added a line of code that smoothed my flux data before I started analyzing it for peaks on Jiong's suggestion.  That has enabled me to do a few things:

First of all, I now have some type of method of picking out the threshold because I can make them the same now.  That would namely be by knowing the begin and end times of the flare.  That can then be adjusted until it starts giving proper times for that.  Then, and this is where I probably need to look at more flares to get an idea of it, for the middle part of the flare the same threshold gives decent times, but if I double the value of the threshold for the code the calculates the middle sequence times, the values become closer to the ones I observed.  It's not a huge difference, but there is some:

Sequence
TRACE Frame
Time (UT)
1st
71:77
10:02.8 - 10:05.8
2nd
77:131
10:05.8 - 10:41.6
3rd
131:138
10:41.6 - 10:45.8
Full Threshold = 2.75e17
Mid Threshold = 2.75e17
Sequence
TRACE Frame
Time (UT)
1st
71:79
10:02.8 - 10:06.8
2nd
77:121
10:06.8 - 10:35.6
3rd
121:138
10:35.6 - 10:45.8
Full Threshold = 2.75e17
Mid Threshold = 5.5e17

Doubling the mid threshold value relative to the full threshold value thus gives values closer to the periods I manually came up with last week.  I observed the third period beginning at about 10:30 UT as a rather rough approximation, and I think five minutes is an agreeable difference between my observed and calculated. 

Now, the other changes:
I added some lines of code that would take the smallest mode if the lines that calculated the mode returned more than one value for the mode.  I also removed some lines of code that limited the cells analyzed in determining the sequences to ones that have a peak at the same frame as the one that is being used as the starting point for determining the sequence times.  The logic there being that by smoothing the data, those lines are extemporaneous and cause more uncertainty because of fewer cells being analyzed.  So, now all the cells are analyzed in determining the sequence times.

After working on the code for Jiong's program that picks out the reconnecting cells, I've just about got it working with my program.  I just need to go through and tweak some things graphically and figure out which correlation and flux cut-offs to use in order to get meaningful results.  But I've grown rather exhausted from staring too closely at my computer screen and am going to take a break for the evening.

July 4, 2007

Let's see if I can synthesize my thoughts now:

So, going through the debugging process today took a while.  First off, my method I outlined yesterday didn't entirely work.  The main problem was that I had to set a manual threshold in order for a sequence to be defined.  That caused problems because in the middle of a solar flare, there is more flux change and the flux is going to bottom out at a higher value than at the very beginning and very end of the flare. 

The second problem was that using the method of picking out the first peak that occurs in a given time frame skewed the data.  So, I would get back results that said the middle of the flare was occuring before the flare even actually began.

So, I came up with two solutions to these problems.  First, when a flare is really undergoing reconnection, more cells are going to be involved than fewer.  Consequently, I made an array containing the first temporal peaks for a cell denoted by the TRACE frame.  I then took the statistical mode of that array (in other words the frame that shows up with the most number of cells having peaks during it) and used that to give me a starting point that would give me an idea of the sequence of the flare as a whole.  I then put that through my method I outlined yesterday of giving me a preliminary sequence and finding the largest amount of flux change in that preliminary period and then defining the sequence around that peak.  I did this with the smaller threshold of 1e17 Mx/s.  It resulted in me getting the frames for the very beginning and very end of the flare.

I then repeated the process by gaining the statistical mode, but this time I found it with an array containing the TRACE frames of the last recorded peaks for all the cells.  I then put that through the same process as mentioned in the above paragraph, but with a threshold of 3e18 Mx/s.  It gave me the middle sequence of the flare (impulsive).  So, then to gain the bounds of the first and third sequences, I just used the beginning of the middle as the end of the first and the end of the middle as the beginning of the third.  So, all in all, I got these results with the TRACE frames beginning with zero and not one:

Sequence
TRACE Frames
Time (UT)
Pre-impulsive
72:100
10:03 - 10:22
Impulsive
100:108
10:22 - 10:27
Second Peak
108:138
10:27 - 10:45

The only qualms I have concerning this method is the picking of the threshold values.  They are the only things that must be picked manually, and the only shot you have at getting them right is trial and error and having a decent knowledge of the flare already.  The only guide you have for them it seems is that the threshold for the whole flare is about an order of magnitude smaller than the threshold for the middle flare sequence.

July 3, 2007

I started working on Jiong's program that analyzes the flux of the flare cells to try to find the reconnecting cells for a given time period of a flare.  The goal is to break the flare into its time frames of pre-impulsive, impulsive, and second peak (doing so will make the program as a whole automated without any human-derived input about the flare's evolution other than its flux).  So, I spent the first half of my day coming up with some idea of how to make this work and the rest of the afternoon attempting to code it.  I just finished (I hope at least) writing the code.  I'll look at it again tomorrow when my mind is fresh and can actually analyze it more carefully and hopefully start debugging it.

But the main idea I worked with was using Jiong's program that finds the peaks (these peaks are based on the derivative of the flux) for a cell and tells me at what frame it occurs in the TRACE data.  Then, from all the cells, I used the first time frame with a peak (ie: say of eighteen cells the first peak occurs at frame 90, but there are peaks from other cells occuring at 99, 100, etc, but none before frame 90, then that frame 90 is what I use) and came up with a preliminary period by finding at what TRACE frame all the cells dropped below a certain flux rate (I am not certain of this method of defining the periods just yet though.  I'll have to play and see and possibly change it).  Then, within in that given period, I find the absolute maximum flux rate from all the cells under the idea that the absolute maximum during that frame will be showing the major action of that sequence (I want to think that doing this extra step won't actually really change anything concerning what frames define a given period, but again I'll have to just wait and see what I get back).  From there, I have the pre-impulsive sequence defined.  I then repeat the same steps as above to define the impulsive and second peak sequences by assigning the first frame of a sequence to be the last of the sequence before it and repeat the steps just as I did before but with an already defined start to the sequence.

So, anyways, hopefully that all works.  I'll find out in the morning for fear that if I try running it to see what my results are now, and it doesn't go perfectly that I'll sit at my computer all night trying to fix it.  Consequently, I'll wait until tomorrow.

June 29, 2007

Okay.  So, I plotted the intensity of a given cell against its time derivative of the flux squared [(d(Phi)/dt)^2]:

P1
N1
P2
N3
P3
N5
P5
N9
P8
N11

N12

Some of the cells (P5 and N5) didn't plot too many points because they had an overflow of digits causing IDL to have a fit, and I failed to find a way of exponentiating with extra precision (maybe I declare the variable as such?  I'm sure there's a way.  I just didn't have enough time to read up on doing so).  The interesting thing that problem brought to my mind was that those cells must consequently have a large maximum time derivative of flux.  But beyond that, the graphs for the most part either show a horizontal line correlation or nothing at all. 

Anyways, next week, I get to begin work on something sort of new.  The idea is to modify this program Jiong wrote to automate it so that it will find the reconnections going on for a given time frame based on their temporal maximum rate of flux change.  But for now, it is off to Glacier National Park for a three-day weekend!

June 28, 2007

So, taking yesterday's results of the linear fit, I gained this chart (I've changed the color scheme to be more distinguishable and thickened the lines for visibility).  The x-axis is the time derivative of the flux, and the y-axis is the time derivative of the intesity.  The left is the positive cells with the intensity multiplied by a scaling factor of 2.83e16.  The right is the negative cells multiplied by the scaling factor of 1.62e16.  It's a bit difficult to see the correlation suggested by yesterday's data output.  So, just to better see it, I graphed each individual cell in a plot.  For the positive cells and the negative cells.   The scales are too small to really see.  I just wanted to see the correlation and actually believe it.

And putting my view of the flare evolution in a table based on time with the correct time references (unlike yesterday's mishap):

Time (10:00 UT)
Reconnecting Cells
Peak Flux Rate (Mx/min)
:03-:15
P5:N1, P5:N3, P5:N11
1e20
:05-:25
P2:N12
5e20
:05-:30
P2:N11
5e20
:13-:20
P3:N12
2e20
:18-:25
P1:N6, P1:N11
2.5e20
:20-:25
P3:N5, P3: N:11
7e20
:25-:30
P8:N1, P8:N3, P8:N6
9e19
:30-:35
P2:N11
4e19
:30-:42
P2:N9, P2:N10
4e19

The P2:P11 pairing is continuous for 05-35, but I broke them up because at 30-35 shows a different reconnection.  Also, the peak flux rate is just my eyeball measurement from the graphs.  So, they are in no way dead-on.  But the reconnections are in order of their begin time, and if they have the same begin time, then it's  further ordered by their end time.  Also, I view most of the reconnections in reference to the positive cells since there are fewer of them and are thus connecting to multiple negative cells at a given time, so that the flux going into those given negative cells summed together tends to be about the same as the flux coming out of the positive cells.  The last thing of note that I found interesting (and I guess it makes perfect sense with the model) is that the flare does build up to a peak of reconnection rate, and also that there seems to be a point in the middle where the flare slows down a bit and then reconnection rate picks up again, but not nearly as high as during the first reconnection session.  The first session looks to end at about 10:25-ish UT and the second session begins at about 10:30 UT, and all action stops for the most part a few minutes after 10:40 UT. 


June 27, 2007

Going through all the data I kind of put together yesterday to get some type of image in my head as to the flare's evolution:

[note: the times I say in the following three paragraphs are off by ten minutes as explained later.  So, the flare does begin as observed.  I just can't type properly.]

It seems that until almost 15 minutes after the flare actually began (10:03 UT) that the reconnection action is minimal.  It isn't until about 10:20 that the flare really picks up.  It's easier to reference the action of the flare with respect to the positive cells (since there are fewer of them).  So, the first big sequence of reconnection occurs at about 10:20 and lasts until about 10:30.  It also is the sequence that generates the most flux reaching the magnitude of 10^20 Mx.  Most of that activity is focused on P5 which is reconnecting with N1, N3, and N11.  There is less flux generating activity with N12-P3.

The next large sequence is at about 10:30.  The largest generator of flux there is P3, which peaks at about 5e20 Mx reconnecting with N5 and N12.  Of a lesser magntude ranging from 9e19 Mx to 1e20 Mx is P8 with N4 and N0.  In this case, P8 seems to initiate the reconnection, and the reconnection then moves and continues with P1 reconnecting with N11 and N6.

The last sequences are smaller on the flux scale.  At 10:40, P8, which on the whole has a magnitude of 10^19 Mx reconnects with N1, N3, N6, and N9.  But as I said, that only reaches about 1e19 Mx.  Remnants of flux are seen at 10:50 with P7 reconnecting with N9, N3, and N5 on the similar scale of 1e19 Mx. 

Next, when I started looking at the flux derivative and the intensity derivative, I found that my times from yesterday's graphs weren't matching, but the flux was fine.  It seems to be due to a 'min_value' keyword I mistyped in to the plot function.  However, the shift is off by about ten minutes.  So, anything that I said happened at 10:15 above really occurred at about 10:05, which makes me feel better because the conclusions I was arriving at were showing the flare occurring about ten minutes later than it should have.

With that said, I focused on a few of the cells to compare the changes in intesity and flux with blue lines being the change in flux, the red ones the change in intensity and the time is in minutes after 9:00 UT (the time being correct this time).  Also, the intesities were multiplied by a scaling factor of 2.83e16 for the positive cells and 1.62e16 for the negative cells:

The positive ones:  P1, P2, P3, P5, P7, P8

Negative cells:  N1, N3, N5, N9, N11

Next, I did a linear fit for each of the above given cells and got the following values for A and B with the x-value being the change in flux and y-value being change in intensity.  The same factors for the intensity were used for the cells as earlier based on whether it was a positive or negative cell  Let the linear relationship be y = A + Bx and R is the correlation coefficient:


Cell ID
A
B
R
P1
6.763e17
1.096
0.9763
P2
1.362e18
0.4112
0.9804
P3
5.817e17
0.5346
0.9544
P5
7.728e17
2.436
0.9861
P7
8.933e17
1.263
0.9265
P8
3.733e17
2.063
0.9952
N1
3.045e16
1.515
0.9985
N3
6.209e17
2.028
0.9889
N5
1.857e17
1.216
0.9987
N9
7.691e17
1.432
0.9534
N11
7.773e17
0.9958
0.9489


June 26, 2007

Went through the flux with respect to time for each given cell today.  I also finally got the flare map with a fair amount of cells, totaling 12 negative cells and 8 positive.  So, attempting to analyze the reconnections of the cells, I did them all in reference to a given negative cell (ie: between time x and y, negative cell 1 (N1) seems to reconnect with positive cell 5 (P5) and between time a and b, N1 with P3).  The cell notations all reference the aforementioned flare map.  Also, in all the maps, the x-axis is the time in minutes after 9:00 UT and the y-axis is absolute value of the first derivative of flux with respect to time in Mx/min.  The blue line is the positive flux, and the red line is the negative flux.  Thus, beginning with N1:

N1:  It begins with P5 at about t=78 to t=90.  P8 interacts at about t=100.  It also conincides with P1 at t=85 during its flux increase

N2:
  It starts with P8 and at t=90 and goes through a decrease in P6 at 105 min.  The flux increases and decreases again at P1 and P2
at 100 min

N3: 
Initiates at P5 at t=80 and follows it until t=100-ish.  It has a second rise and fall with P8 and P7 acting at t=105

N4:
  Starts with P8 at 88 min.  and mostly follows it minus a brief interaction with P6 at 105 min. that might push it to the peak it has

N5:
  It follows P1 and P3 for minutes 95-105.  Then for it's next increase in flux follows P7 at t=110 to t=120.

N6:
  It seems to start with P1 at t=85, but mostly follows evolution with P8 after that.  The minor flux increases occur at t=110 with P2 and t=130 with P7

N7:
  It's a small magnitude flux here.  Thus, I can't account for 60<t<70.  But at t=80, it stays with P7 until t=120.  It seems to interact with P5 at 80 min and P2 at t=90 and t=110

N8: 
It's increase in flux seems to be due to P5 at t=70 and then it's fall follows P8 at 80 min.  My thoughts are that it's isolated in its region and only has a brief reconnection near the flare's beginning.  Still, I can't find anything interacting with it right when its flux increases

N9: 
It begins its increase with P8 at t=100 and falls  and has its peak accounted by P6 at 105 minutes.  Its second large increase at t=110 follows P7 and P2 to t=120

N10:  It begins flux increase at 90 min with P8 and falls at 100 min within P1, P2, and P8.  It rises and falls again at 115<t<120 with P3.

N11It roughly follows P8 for 80<t<120 and first increases largely due to P5 at 80 min.  It follows closely to P7 for 105<t<120 and P1 for 90<t<120. 

N12:  It follows almost perfectly P1 for 80<t<105.  It has a rise with P2 at 80-90 min and P3 seems to also be included in flux increase at 90-105 min.  P2 and P3 seem to add to the flux not fully seen in the P1 reconnection.

June 25, 2007

As mentioned before, I needed to go back over the tessellation program and attempt to merge cells together.  So, running that program took a bit of time.  Subsequently running the flux rate program took a bit of time as well.  And just looking at the results of the tessellation mapping, the negative cells don't seem to want to merge (some have, but it's still on the verge of twenty negative cells).  So, I guess I will run the program again with some higher thresholds and try to get cells that look like the should be together together and see if areas that should merge together merge.  That should be done by morning since I only have to run the programs and wait.  Then, I need to start trying to put some formative picture of the reconnections going on during the flare tomorrow.   But here was the result of the first trial of cell-merging giving a total of 17 negative cells and 9 positive ones.  It still looks like the area with N1, N4, N7, and N18 could be merged somehow along with the negative cells positive near the flares beginning and N10, N9, and N14.

June 22, 2007

After going over the results from yesterday's work, there were some things that needed to be fixed.  Today was spent fixing those things.  First off, I mentioned in the log yesterday that despite the differing fluxes for the given positive and negative cells that the total positive flux and negative flux should be equal (or roughly equivalent in this analysis set-up).  So, I put together a graph with the absolute values of the positive and negative fluxes graphed as two different lines dependent on the progression of the TRACE data frames used for analysis.  As the graph shows, the assumption is true.

Back to the problems I mentioned earlier.  First, the color scale of my flare evolution map did not quite match with the graph of the flux dependent on time.  So, I went back through the code that generated the map and eventually figured out that my time scales were off between the generation of the color bar at the bottom of the right side of the map and the coloring of flare on the right.  So, I fixed that, and it showed the flare starting at 10:03 UT, when it was actually recorded to start, instead of at 10:10, which is what the map was showing me.  Next, the placement of cell centroids wasn't properly placed.  The map was showing me negative regions that just didn't have negative regions.  So, Jiong prepared some code that calculated the centroid based immediately on the information in the tessellation map of the MDI frame used to calculate the flux, whereas I was getting the data probably from an incorrect variable in the tessellation program.  I put her code into the program, and the positioning of the cell centroids ended up making sense.  The last problem consisted of attempting to remove a part of the flare map that wasn't actually a flaring region, but was showing up on the map because it was a brief eruption in my active region during the time the flare occurred.  So, Jiong had me change a parameter in the program that calculates the evolution of the flux itself that caused integration to occur over three given TRACE cells for a given time frame as a mean instead of each frame individually in hopes that it would wash out the brief emissions it gave off in its small time frame.  The result can be seen by the diminished blue section in the lower left of the colored flare map in contrast to the one I produced yesterday.  So, in culmination, the new flare evolution map with previously mentioned corrections. 

The last concern which might be addressed later is the large number of flux cells (a grand total of thirty).  Several of them may need to be merged during the tessellation of the magnetograms.  So, a larger "smoothing" parameter may need to be used  that would reduce the number of local maxima used to create flux cells. 

June 21, 2007

Well, I finally finished putting together a temporal representation of the flare reconnection.  By the color display on the right, it's pretty clear to see that the flare follows the model for flares with reconnection.  New field lines reconnect by overlapping field lines that have connected prior to its reconnection.  We can see that in the image the flare began very small at about ten minutes after 10:00 UT (purple/blue regions) and grew as the field lines reconnected over the initial beginning location.  It not only expanded vertically (as can be seen by the lines that change to yellow and then red in portions, but also horizontally because in the right image, the portion(the purple/blue spots) that is to the right began before portions (lighter blue/green spots) on the left.  By looking at the cell designations on the left magnetogram and then their corresponding locations on the right flare image, it seems that cells N1 and P3 were the last reconnecting portions of the flare at around 10:50 UT as can be seen by their being red on the flare image (it is merely a guess that they shared reconnection by looking at the time the flux changed and their location to each other and how the flare expanded  By looking at the flux of their cells at time t, it would be possible to conclude whether they did actually share in reconnection).

If I look at a plot of the flux, I can actually see the level of the flux and also that for each line that begins gaining in positive flux, there seems to be a line gaining in negative flux at the same time.  For example, at about t=5 min, there seems to be two green lines diverging in that manner.  Now this isn't true for each line having a certain cell that it reconnects with (a one-to-one connection,so to say) and thus generates equal amounts of positive and negative flux because there are more negative lines corresponding to cells in the magnetograms (18) than there are positive ones (12).  However, that's seems sensical as there is that one positive flux line that approaches 6E21 Mx.  It only means that one given cell is reconnecting with more than one negative cell.  The total positive flux generated by the reconnection is equal to the absolute value of the negative flux (or should be close in this case since there is surely error in the calculations),  If they do not end up equal, then charged particles would be crossing magnetic field lines which just doesn't sit well with plasma physics.

So, at this point, it seems that the analysis of the flare agrees with the model of flare ribbon reconnection, which could allow one to sleep a little better at night.

June 20, 2007

Spent the whole of the day trying to graphically represent the rate of flux reconnection on the Bastille flare using one of Jiong's programs.  The morning was spent better understanding how each line of the code functioned and making it work for my particular flare, and the afternoon was then used tweaking parameters on it.  I've just about got it.  I should have it done this evening or tomorrow morning at the latest unless something unexpected troubles me with it. 

And to offer some larger explanation as to what I've been doing here:
By first doing a local correlation tracking (LCT) between two subsequent MDI images by having a program analyze the changing position of any given area of pixels, I am offered some insight into how the magnetic flux of the active region (AR) is changing and where, so to say, its "parts" are moving and how they're moving.   Then, running that data through a tessellation program to give us distinct cells of flux, we then have the ability to see how given magnetic field lines have changed prior to a solar flare, in the sense of becoming twisted or sheared much in the same way as tectonic plates on Earth.  That knowledge can give some idea of how the magnetic reconnections that occur as a result of the solar flare may form the helical flux rope that would result in a coronal mass ejection (CME).  If that is truly how flux rope is formed ("in situ" is the term, I believe), then there should be some connection to the magnetic cloud flux resulting from the CME and the flux in the flare.  And we are able to obtain the flux in the flare by Maxwell's equations and the knowledge that plasma must travel and be conserved along given magnetic field lines.  Thus, the change in flux can be observed by us in the sun's photosphere, which is where our MDI data is obtained. 

June 19, 2007

Finally got the coalignment done early this afternoon.  I have to make sure that the MDI and TRACE data have both the same resolution  and pixel size.  Then to coalign the different images, I need to find a few prominent spots and use them as a reference until I can see them overlapping between the TRACE and MDI data. 

I then ran the data through the flux rate program and have the data from it.  The next thing to do is to put the output data into a graph so it can actually be read.  The next step to complete is getting the output into a format that makes sense.

June 18, 2007

I've put together movies of the tessellation of the MDI data prior to the flare.  I looked at the time of the last flare prior to the Bastille flare on my active region and my begin time of my analysis of the MDI data is fine.  However, I noticed that my last image of MDI I'm using proceeds into the start of the Bastille flare.  Consequently, that last image must be discarded because of it's inaccuracy.  So, of all my total 23 frames, the 22nd will be used when I finally analyze the MDI data with the TRACE data.  Eyeballing the movies to see which minimum threshold for partitioning and the order in which they analyzed, the data with the threshold set at 55 Gauss in the reverse direction seems to be the most stable throughout the time frame, excluding the last frame which came after the flare and with a consequently different active region.  However, partitions do pop in and out through the movie even in the previously mentioned outside the main active region.  Anyways, the movies:

45 Gauss Chronological
45 Gauss Reverse Chronological
50 Gauss Chronological
50 Gauss Reverse Chronological
55 Gauss Chronological
55 Gauss Reverse Chronological

After talking to Jiong and deciding I should proceed with the tessellation with the 45 Gauss threshold analyzed chronologically, I spent the rest of my afternoon fumbling around trying to understand how to properly coalign the TRACE and MDI data.  I finally figured that out, but now I am forced to consider the pixel sizes of my MDI data relative to my TRACE data which is at 384 x 384 and how that affects the running of the flux rate program.  So, as it is getting late and my fumbling led me to some frustration, I'm going to pick up with this in the morning.

June 15, 2007

The last few days have been a bit off.  As a result, I've just finally completed the tessellation of the MDI data of the Bastille flare.  I should be done with analyzing the MDI data for the flare and should be able to begin the TRACE data and the subsequent coaligning of TRACE and MDI data and obtain flux for the flare.  This tessellation of the MDI data seems to be more sophisticated than the MDI stuff I was using last week to find the flux of the same flare because by finding the velocities of the moving flux in magnetograms, the subsequent tessellation was able to follow the evolution of the active region.  So, the wait for the data to be analyzed should be worth it.  At least this is my understanding of the project from the papers I've read and talks I've had with Masha and Jiong.

June 12, 2007

The day was mostly spent as a continuation of yesterday's work.  After discovering that most of the resultant data from yesterday's work wasn't any good due to a line of code that was needed to extend the number of pixels analyzed between shifts in the MDI data between two given images.  Since I ran the program to analyze the velocities of the frames with only three pixels analyzed between two frames, the resultant data was skewed.  So, I extended that to seven from Masha's suggestion.  With the analysis of more pixels though, the program takes about four times as long to run.  As such, most of the day was spent correcting any frames that were simply useless.  The other part of the day was spent realizing the problem.  However, the results I've received so far are looking better, and I should have something tangible to display and view by tomorrow.

June 11, 2007

Today was spent analyzing velocities of MDI data for the Bastille flare starting with July 13, 2000.  There was trouble getting the programs to work initially for mine and Peter's flares due to the directories that were already coded into the programs.  Masha spent some time correcting them and then all was well.

While she did that, Peter and I tried our hands at making an mpeg movie from several LCT jpeg files Masha had on her directory using IDL.  However, we eventually resorted to using Quicktime to make the movie, as we couldn't get the jpeg's properly read into an array.   Afterwards, we began running the programs to analyze the MDI velocity vectors of the fields, which takes a fair amount of time as I am presently waiting for all the data to be computed and saved.  Once that is done, I will change the resultant data into jpegs and most likely create an mpeg of the jpegs to better understand how the active region for the Bastille flare is changing up to the flaring. 

June 8, 2007

To serve as some culmination of the things learned throughout this whole past week:
  • Began creating .mpeg movies of the Bastille Day flare from MDI data taken a day or two before the flare and through it:
    • One consisted of the full solar disk with frames every nintey-six minutes
    • Another was focused in on the active flare region
    • I did however notice that IDL managed to turn my .mpeg upside down from the original images, so I found on Jada's log from last year the same problem and wrote her correction (image=rotate('filename',7)) into the program and all was right in the world again.
  • By looking at the .mpeg closed in on the active region, I can see the emergence of magnetic elements (the growing white blob in the movie).  I'm not a hundred percent what I'm exactly seeing.  Knowing that an X-class solar flare is soon to emerge from it, I can assume the magnetic field is a bit turbulent and unrestful and that is probably what I'm seeing in what I'm supposing is an emerging magnetic field.