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]:
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):
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.
N11: It 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.
|