DAILY
LOG
Home
New Big Picture Forever
Correlation, Color, and
Tessellation Maps
July 31, 2008
You can now see
almost all of the presentation. I'm leaving conclusions and
introduction until everything is done. Starting at http://solar.physics.montana.edu/REU/2008/nhill/presentation_08/p2a.html,
all through almost all of energetics is prepared.
July 30, 2008
EDIT: So, I
fixed my continuity problem and now you can start at slide p2a and see
all the way through the beginnings of the energetics part of my
talk. It appears as if I've managed to decide to produce my
introduction
to the talk as my last task in preparation.
Continued working
on presentation. It now has some continuity to it. There
are still gaps though. You can start with:
http://solar.physics.montana.edu/REU/2008/nhill/presentation_08/p2a.html
and see some continuity for a few slides.
Then, I have a bump because I haven't created my slide for the
connectivity matrix with topology images yet. So, you can pick
back up at http://solar.physics.montana.edu/REU/2008/nhill/presentation_08/p6.html
July 29, 2008
A
plot with velocities, HXR photon counts, and spectral index.
There's a startling correlation at 10:24 among everything except the
photon counts. I looked at the HXR footpoint movie and can only
conclude that the peak there in the HXR velocity is not wholly
artificial because you can see that the concentration of contour lines
is moving eastward up to 10:24. In fact, I think I
intentionally picked 10:24 to move the HXT multi-image pointing
coordinates due to the seeming continuity in the movement of the
footpoint eastward.
So, maybe there's some type of acceleration of electrons occuring in
the singularity there at 10:24 which is then released as photon energy
and the shifting magnetic field lines are allowing this
acceleration. I'm not really sure, but it is oddly
fascinating.
Also, you can look at the development of my presentation by going
through the directory
http://solar.physics.montana.edu/REU/2008/nhill/presentation_08.
It's mostly in segments with severe continuity problems.
July 28, 2008
Today marks the
beginning of working on my presentation. Right now, I'm just
making slides that roughly sum up the stuff from last year. I'll
post new plots I may generate as I go and a link to the presentation
once it starts to come together. In the meantime, the first few
slides from last
year's presentation should be representative of what's going on now
in my world.
July 25, 2008
All right.
I resolved the HXR centroid movements into their actual velocities
(km/s) as opposed to difference in positions. All I did was also
divide by the difference in time (v = delta_x/delta_t believe it or
not). As you can tell by watching that HXR movie (do a ctrl+f and
search for "this movie is better"), there's not much perpendicular
movement. So, that's reassuring. I also went ahead and
smoothed the final data. It's a little less jumpy now and easier
to look at. Anyways, the plots which is just their velocities
(I'm about to make some using TRACE data ribbon movement because it's
extra special when I can get different satellites to agree with each
other):
Positive
Cells
Negative
Cells
All right. I finished the plots of ribbon velocity from TRACE and
HXR centroid velocities. For the parallel movements, I just used
the time derivative of the ribbon elongation (ie: pos_str.length), and
for the parallel movements, I used the time derivative of the ribbon
expansion (ie: pos_str.width). I also multiplied the
perpendicular TRACE velocities by 5 in order to see them a bit more
clearly. Otherwise, everything's in km/s and both plots agree
with the axes as presented
Positive
Velocities
Negative
Velocities
July 24, 2008
And finally
finished the program. Here are the results:
Parallel
Motion
Perpendicular
Motion
The dotted line at t =24 is from where we moved the coordinates.
So, any spike there is certainly an artificial one. I didn't plot
energy here, but I do like how the parallel motion coincides with the
peak in energy for SXR and HXR. Also, in the perpendicular plot,
there's certainly no change in perpendicular motion when we see the
peak in photon counts. Kind of interesting.
July 23, 2008
I made a
pretty helicity plot for the presentation. I also started
working on a program to calculate movement of HXR footpoints with
respect to the PIL in perpendicular and parallel directions based on
footpoint centroids that Jiong generated. I'm not sure how this
is going to end up faring, but I'm going to try. If I get it done
today, you'll see the plot on here.
In completely unrelated to anything involving solar physics news, today
was stage 17 of the Tour that ended with a climb up the historic and
legendary L'Alpe d'Huez (I like to refer to it as the climb that
destroys souls), and that makes me happy.
July 22, 2008
Ran the sequence
analysis a few times in attempt to get the sequence a little more
simple, especially during the middle stage when it seems every cell and
its mother is going with the reconnection process. The conclusion
was that by raising the correlation cut-off, I only eliminated cells in
the very beginning if any at all. Just to show, I ran it with
several different parameter and found that altering the cont keyword
from 3 to 4 did nothing to change the results of the program.
Changing cut_cor affected results the most, as one might think. I
also tended to use the binsize = 8 (+/- 2 min, as I'm working with a 30
sec cadence after the prepping of the flux). I tried it between 8
and 10 with cut_cut = .70, and the binsize didn't affect the results
either. I'm sure they would if I dropped it down to 6
though. I'll just post all the results as .eps files:
I also figured out where the problem was in the ribbon expansion
program. My polarity inversion program, while running perfectly
fine, wasn't passing the right information to the ribbon expansion
program. It was more subtle than just a misnamed variable
though. Because I would piece together pieces of stuff together
from multiple runs of the polyfit program for different sections of the
active region, the variable "res" which carried the coefficiencts of
the polynomial results were only carrying the coefficients of the last
run of the polyfit program, which was a linear combination. In
other words, my data was once again bunk. The ribbon expansion
program depended heavily upon the vector attitribute of the res
variable though. So, what I did was I saved a number of points
from my patching together of polyfit results and ran one final polyfit
to attempt to get a vector res variable for the ribbon expansion
program. I kind of succeeded. The red
line on this PIL is the result that was passed to the ribbon
expansion program, and here's the new ribbon expansion result:
Positive
ribbon
Negative
ribbon
As a result, this also means that my results for the heating rate are
incorrect as they were based on results from the ribbon expansion
program. So, corrected results for that (it's worth noting that
both maximum values have decreased a fair bit with the corrected data):


And as a result of the corrected ribbon expansion, the everything
plot highlighting elongation throughout the ribbons and the version
like last time (not highlighting elongation)
I also doubled checked the units and conversions for my heating rate,
and it's still correct for all that I can tell. It yields the
answer in ergs and ergs/s (the final scaling factor is 10^22 to convert
all the parameters into ergs). So, I have no explanation why the
HXR energy release requires a more drastic down-scaling than the SXR
energy release in the everything plots. (to scale HXR I multiply
it's energy release by 7.e-9 and the SXR by 9.e-8).
July 18, 2008
Okay.
Finally finished putting together what I'm calling the everything
plot (.eps file). It took a while to scale everything decently, and
that much
data is just confusing to deatl with. Regardless, there it
is. Everything is scaled to the reconnection rate on the order of
magnitude of 1.e19.
July 17, 2008
Regenerated plots
of ribbon elongation for this PIL.
I made two versions of the positive and negative sets. One
features more prominently the eastern distance of the ribbon expansion
along the PIL, and the western distance for the other. They are
all postscript files for easier viewing:
I looked a bit
more closely at the energy and spectral index data. Particularly
how the data shifted depending on whether the M1 channel was used in
the calculations. So, I made a qualitative table, and I'll follow
with some plots:
|
Cut_m2 enabled (ranges)
|
Cut_m2 disabled (ranges)
|
E1
|
1.e26 - 1.e28
|
6.e27 - 6.e29
|
I think
overall, there's nothing surprising about the values since with M1
being in the calculations (cut_m2 disabled column) the ranges are
overall higher, which you'd expect for allowing M1 to help determine
the slope of the energetics line. All this data with time array
is also saved in /disk/data/nhill/hxr in energetics.sav and
energetics_m2.sav where the energetics_m2.sav is the save file
generated with the cut_m2 keyword enabled.
E1:

July 16, 2008
So, I thought
more about that data skewed gap (where there isn't any data), and
thought about the general way in which data is prepped and concluded
that t = 0 was probably defined in the prepped data file as the
starting point of the data, which happens to be at about t = 11
min. Incidentally, the time array also stops an extra 11 minutes
before the data straight from YOHKOH does. So, I concluded the
plots from yesterday are trash, and I must move all of the plots
forward on the t-axis by 11 minutes. Redoing those now.
Done and done. The graphs make sense like I'd expect now.
I plotted both methods of calculations of the energy. The
patterns match, but the first manner (interpolation, I believe) is
about twice as large in magnitude as the other. Just to see them
side-by-side though:
It may be worth noting that in
those plots for energy 2, at 10:27, when all of the HXR footpoint cells
are the
cells participating in reconnection, we see the largest peak in
energy. I guess as you'd expect though. It's just that the
cells undergoing reconnection for that small peak are simply P1 and
N4. Even if you look at the reconnection sequence map, you'll see
that at 10:27, all cells pause in reconnection except for P1 and N4,
which is when we see that energy spike in the HXR.
As for the spectral index now:
Total
Footpoint
The interesting thing here is we see a spike in the spectral index at
~10:24, which is the largest phase of reconnection.
July 15, 2008
I did the
spectral analysis using the HXR data too plotted it against the
Bastille reconnection rates.
Concerning the energy output, the analysis output two different methods
for the energy, the first one, which I believe finds the energy through
an interpolation, was pretty fussy and gave a fair amount of infinities
when looked at closely. The second method, which I think did some
type of integration, was much less fussy. Both calculations were
close to the other, but the second was more well-behaved. So, I
plotted it against the footpoint reconnection rate and the total
reconnection rate. It's worth noting that as the footpoint flux
generally increases, the energy decreases. However, during the
skeleton phase of the flare (0<t<20), there is a period where the
total flux (there's not any measured footpoint flux here due to the
lack of HXR data), the energy goes right with the reconnection.
However, I am weary of this data because there's not supposed to be any
HXR data for 14<t<19. I'll have to ask Jiong about the
prepping of the data and the time variable for it, as I feel the data
is skewed too far back by about 5 minutes.
Total
and Energy
Zoomed
Total and Energy
Footpoint
and Energy
On the spectral index, I just plotted the mean of the spectral indices
found using the ratio of the HXR bands M2/M1 and H/M2. They
seemed to behave about the same. The only thing worth really
noting here is the the universal spike in all of the data at about t =
29 min.
Total
and Spectral
Footpoint
and Spectral
Zoomed
Footpoint and Spectral
After more trials and tribulations with absurd units (ie: 10^49 cm^-3.
really is that 10^49 necessary for my soul?) and figuring out that IDL
couldn't handle converting every variable into a sensible unit and
should instead do a sum of all the conversions into one equation to get
something sensible, I produced a thermal energy plot and then a heating
rate plot. I checked orders of magnitude with what Jiong said I
should be finding, and they match what she's said. The thermal
energy looks sensible, and the heating rate looks like a derivative of
the thermal energy with some additional loss (I also took the absolute
value of the derivative, but I'll post both). I'll point out that
the the thermal energy ranges from about 10^28 - 10^31 erg, and the
heating rate is about 10^26-10^29 erg/s :
Thermal Energy:

Heating Rate (with absolute value taken):

Heating Rate (no absoulute value:):

July 14, 2008
Today's lesson:
Astronomers use crazy units. I actually already knew that, but today
reaffirmed it.
In other words, I'm working on energy calculations for my flare and
after spending part of the day thinking of ways to calculate flare
ribbon lengths, I realized I had already done that with the ribbon
elongation programs and then started drowning in unit conversions.
July 11, 2008
I redid the model
vs. observed plot as a log-log plot in order to see everything:
Also, for quick access, a plot of HXR
overlayed on normalized reconnection rates of cells.
I also went ahead and removed the cells where observed reconnection
does not occur from the connectivity matrix to see what the
connectivity balance is then. Somewhat surprisingly, the balance
holds pretty well. The discrepancy between reconnection flux and
excess flux from connectivity of course worsens.
|
Connectivity (1e21 Mx) |
TRACE (1e21 Mx)
|
Positive/Giving
|
9.75
|
14.10
|
| Negative/Receiving: |
-9.06
|
-15.34
|
Balance:
|
92.93%
|
91.92%
|
Then, I overlaid the footpoint reconnection rate over the ribbon
expansion plots:
Positive
Cells
Negative
Cells
I also re-did the hard x-ray plots with the units in
Mx/sec, and I did a continuous taking of the derivative (well as
contiuous as the data would allow me to be) for the total reconnection
rate:
Total,
Footpoint, HXR
Total,
Footpoint
Footpoint,
HXR
Total,
HXR
I also have managed to download the GOES data for temperature
measurements, emission, and energy loss of the Bastille Day flare.
July 10, 2008
Put together the
model and observed plots, and they're not very happy. I checked
the matrix to make sure they were reflecting what they should, and as
far as I could tell, the plots were unfortunately and painfully
correct. The spread in flux is large enough that I needed to
generate two plots, and due to that, I was unable to take advantage of
Eric's program that put cell ID's next to points without bothering to
rewrite the whole program. I think it's okay though because the
plots are extra sad. Also, positive cells are diamonds and
negative cells are * (asterisks). I'm pretty certain that if you
look at my matrix and the top plot of the two, the one point that's
dead on the dashed line is N7 at around 1.3e21 Mx.


July 9, 2008
Regenerated my
HXR plots, but with the reconnection rates separated into positive and
negative cells. I also found the problem concerning how I was
getting more footpoint reconnection than total reconnection. The
problem was in the negative cells like I hypothesized. However,
it wasn't due to the averaging thing (which I did away with entirely
now), but because the program that found footpoint cells would count
cells more than once if they had more than one HXR source in them, and
I unknowingly was then summing up the reconnection rate for that cell
each time the program found a source in that cell. So, my N4 cell
would sometimes have 2 sources in it, and I would then calculate it's
reconnection rate twice. So, I just added some lines to cause the
program to trip out of the loop if that happened, and all is now
well. I also made sure to use the deriv function in IDL to
calculate the reconnection rate, and it's a bit more pleasant (not too
mention correct as I forgot about the idea that average rate of change
is actually the change in flux divided by change in time because I am
not actually all that bright). The pictures are a bit big now
since I did positive and negative flux graphs right next to each
other. So, links:
Total
Flux, Footpoint Flux, and HXR Counts
Total
Flux, Footpoint Flux
Total
Flux, HXR Counts
Footpoint
Flux, HXR Counts
Also, the
return of the connectivity matrix. This time, I just went
straight through and took the matrices that resulted from using the
connectivity function on the mask files at July 13 @ 0:00 UT and July
14 @ 9:36 UT, and subtracted the initial matrix from the flare time
matrix (difference = flare - initial). Then, I summed up positive
values and negative values. And it works!
|
Connectivity (1e21 Mx)
|
TRACE (1e21 Mx)
|
Positive/Giving
|
10.50
|
14.10
|
Negative/Receiving:
|
-10.20
|
-15.34
|
Balance (small/large)
|
97.15%
|
91.92%
|
So, there! It of course doesn't perfectly agree with my
reconnection flux, but tomorrow, I'll work on producing plots of the
model flux vs. the observed flux for individual cells and see if unity
emerges.
July 8, 2008
Okay. After
talking to Jiong yesterday and noticing the flaws in all previous
connectivity matrices, I put a connectivity
matrix together again. I summed all the positive cells into
one cell (C27) and all the negative cells into one cell (C28). I
also this time took the maximum absolute values of flux generated in
the cells from the TRACE data instead of summing it all up over a time
period. Consequently, the measured reconnection flux is a little
bit closer to it all. However, the calculated connectivity flux
between giving and receiving cells isn't exactly balanced. As a
look at numbers:
|
Connectivity (1e21 Mx)
|
TRACE(1e21 Mx)
|
Positive/Giving:
|
11.85
|
14.10
|
Negative/Receiving:
|
-4.810
|
-15.34
|
Balance (small/large):
|
40.59%
|
91.92%
|
So,
the matrix is slightly disheartening, I guess, due to the heavy
imbalance. Individually, the magnitudes make a bit more sense now
though. That's something.
And I did the calculations today on the HXR stuff.
First, I have a
really, really long table of values. I think it's pretty
self-explanatory. The footpoint reconnection rate is just the
reconnection rate where we see HXR footpoints. If you find that
its value is 0, it's because the program didn't pick them up.
Now, I have a few graphs, and all of the flux values you see listed as
"flux" are actually reconnection rates of either all the cells of the
magnetogram (Total Flux) or cells where we find HXR footpoints
(Footpoint Flux). I might say my favorite fact is that the most
intense emission of HXR coincides with the smallest relative maximum
during the main ribbon expansion stage (10:27-ish). I'll also add
that the reason the footpoint flux supercedes the total flux at 10:27
(how should that be possible?) is because to calculate the total flux,
I took the absolute mean of the reconnection rate of positive and
negative cells seeing as how they're different (more negative than
positive), the situation below is possible. It's just an artifact
of the programming.
July 7, 2008
This morning,
I've just been writing out the pseudocode for the HXR program I'm going
to write that gives me the flux of cells with HXR footpoints and just
trying to make sure I've got all the details figured out that I need
for when Jiong finishes developing the code that will give the me the
cells on the tessellation map where the footpoints occur.
So, I've gone through and wrote out some program code to calculate the
flux generated for any time of HXR data. I just kind of just
fudged the part where I calculate specific cells as that will be taken
care of shortly. Right now, I have the code written so as to
calculate the area under the reconnection rate curve between two TRACE
frames at 30 s cadence, where the upper bound of the photon integration
time determines the temporal TRACE frames I integrate under (ie: if the
upper bound is 10:19:58, I would integrate under the two frames with
times 10:19:50 and 10:19:20). However, the upper bound must be
outside of a 4 second range of those boundaries because I want to make
sure I integrate over the time where most of the photon counting
occurred, and each of the counts are done over a dt = 8 s. I'm
sure this is being nit-picky when you go ahead and consider the already
existing error, but whatever. Anyways, this integration is done
with all the cells and then with cells coinciding with HXR
footpoints. I then calculate the percentage of flux generated
where we see footpoints in regards to that flux of all cells. I
output all of that to a text file along with the photon counts of the
M2 band and plot it (minus the percent calculation) to the
screen.
July 3, 2008
So, it occurred
to me at some point last night that I was making a mistake when I just
assigned the initial poles structure to the difference connectivity
matrix. I only wanted to give it the flux values from the initial
poles structure because we theoretically don't want flux to be created
in the magnetic reconnection and flux rope model. We only want
already existing flux at t = 0 to see how much flux is transferred into
a magnetic potential field. Thus, this morning, I went through
and did just that. The
resulting matrix.
Things that should be noticed from this (hopefully correct) matrix:
- The flux
ratio for the connectivity matrix is extraordinarily close to 1.
- Connectivity
flux is still about 25 times less than my measured reconnection flux...
Otherwise, that's
what I've got. It's now off to Glacier for camping, backpacking,
and hiking. Come Monday, it's time to get to work on creating a
nice table and plot of total reconnection flux vs. reconnection flux of
spatial correspondence to HXR footpoints and to make sure the
anti-correlation property I found to exist last summer exists still
upon closer temporal inspection.
July 2, 2008
3 days until the
Tour...
I put together a quick plot
of the flux generated by my flare separated by positive and
negative regions temporally. It looks fine other than a slight
imbalance due to more flux in the negative cells, which I was pretty
sure of. I just wanted to see it all together. Div(B) = 0
is still all good.
Also, talked to Masha, and hopefully, I have the connectivity
matrix done right this time. I have strong doubts though, as
my reconnection flux is about 20 times greater than my connectivity
flux. I made sure to assign the flux of the initial poles
structure (generated from msk_str(0))to the final connectivity matrix
and eliminate any emerging flux cells in the flare time connectivity
matrix. Then, I also eliminated from the matrix any cells where
my TRACE footribbons did not traverse (ie: cell where flx from
flux_rate was equal to 0). The balance between positive and
negative cells isn't too bad at all. I just don't like the
difference between TRACE and the topology model. Anyways, I'll
give it another shot tomorrow morning before I head out for the weekend.
July 1, 2008
First of
July. That means four days until the Tour and 13 days until
Bastille Day, when my flare will be 8 years old.
Anyways, I look at the tessellation Masha used for her connectivity
matrix in relation to mine. The one I've been using has a larger
smoothing parameter (h = 10 as opposed to h = 5) resulting in a
tessellation with fewer cells (41 in the case of h = 10 and 60 in the
case of h = 5). The flux evolution between both cases appears
fine. In the h = 10 case, some smaller cells have been merged to
form fewer larger cells is all due to the smoothing of the field
data. There appears to be no troubling flux cell emergence in the
h = 10 or h = 5 case. So, hopefully is all well, and I'll
continue with the calculations of reconnection flux between connected
cells. And then because I can't tell exactly what cells connect
with what cells (since there's multiple reconnections going on all the
time), I'll just have to do a summation. Here are the h = 5 and h
= 10 active region evolutions though:
h
= 5
h
= 10
I also went ahead and did a calculation of total flux between my
positive and negative cells during my whole flare time just because I
couldn't remember what the ratio was between the two entities.
The ratio of total flux of positive to negative cells from the
flux_rate proram with cut = 10 is then:
P/N = 0.886129
Which appears to be a mostly nice number. Also, if I choose to
just focus on cells that generate more 10^22 Mx of reconnection flux,
then that ration suffers a little bit to yield:
P/N = 0.875618
Now on to that connectivity matrix business...
Okay, I calculated simply the flux from any given cell over the full
duration of the flare. Regardless, the excel
spreadsheet. Near the bottom, you see a bunch of little
calculations. The top two rows in that little group include in
the summation of total flux from positive in negative cells via the
connectivity matrix, the mysterious P00 and N00 cells, which I'm going
to believe are field lines at infinity. I'm not sure if that's
something I should be believing though. The bottom two rows have
omitted those P00 and N00 cells. Interestingly enough, stuff
seems to be well balanced as a result of those omissions, though
magnitudes are certainly off. The signs do appear to be
backwards. I'm not sure if taking absolute values is a legal
operation in this instance and am thus letting it be.
June 30, 2008
So, I started
looking at the flaring
region in relation to my PIL to make sure my PIL wasn't cutting out
important ribbon expansion in relation to the generation of
reconnection flux. I decided on the right side, where you see the
linear function for the PIL that the positive cells on the left of it
(P3, P9) are not nearly as important in the reconnection flux as are
the positive cells to the right of it (P4, P7, P13). I made these
conclusions by looking at my big
picture image. In any case, N6 is the main arbiter in
any reconnection for the time all these aformentioned cells are
involved (0 <= t <= 10). So, I'm not sure if I should try
to just completely readjust the line to get it on the right side of N6,
or just leave it as it is. My ribbon expansion plots make sense
with the PIL as it is, but how important it is to the over all
interpretation of the data remains the question. I'll just see
what Jiong says.
Then, Masha passed along to me her connectivity matrix. After
looking at it though, I had a sneaking suspicion we were using
different tessellation maps, and lo and behold, I did the connectivity
matrix for the mask files I have been using so far this summer, and the
stuff definitely came out different. I'm not sure if this means I
need to start over on the actual data analysis, or if it simply means,
I need to generate slightly different numbers than Masha.
Regardless, here's the connectivity
matrix in .xls. I'd put it up as a text file, but that's utterly
incomprehensible. I need to then stick it up with my TRACE
reconnection rate numbers. I can say the numbers are certainly on
the right magnitude, but without looking very closely, I'm unable to
determine at the time how well it agrees with how the reconnection
sequence goes in my flare.
June 26, 2008
Worked on cleaning
up the PIL for the ribbon program. I wanted to automaPe it in
some way. However, the best I could do was overload the
polynomial fit function with so many points that were close to my PIL
that it had to give me a decent function for the PIL. To do this,
I cleaned up the program I wrote yesterday by taking the distance
between horizontally and vertically aligned pixels from the flare
ribbon and aligning and taking the distance between them and adding
that distance to the base of the positive flare ribbon. I also
just went ahead and threw in more points for the polyfit via the base
of the flare ribbon because they were all close to the PIL. This
did a pretty good job except there on the right side of the map, where
you can probably notice I just used a straight linear fit, and then
even had to shift it around a little to get it decent. So, the
find_pil.pro program is far from automated still. It seems the
method of throwing tons of points close to the PIL works decently
though. To make clear, I used Jiong's method of the minimized
gradient, where you'd expect the PIL to be, my distance between flare
ribbons, and then base of the positive flare ribbon to create that darn
thing.
Anyways, as the goal of this PIL business was to run the ribbon
elongation program with the nicer PIL, I did that. The
results are a bit more logical than my initial run with the
program. The image is of course a screen shot off of my computer
because I have trouble converting ps files into jpegs that are nicely
visible.
June 26, 2008
Okay. So,
here's that shot at finding
a PIL. It definitely needs work, and I know there are glitches in
the code that would need fixing if I decide to pursue this, but using
this "flare ribbon method," it can manage to pick spots fairly
well. I definitely need to add some ways out via if statements
and whatnot, as this was a very roughly written program. But
yeah.
June 25, 2008
So, in the time
that stuff's been back up (by the way, Keiji is pretty sweet with the
computer business, and kudos to him if we decides to magically read my
log some day), I've started working on ways to calculate the PIL
inversion line in a more ideal fashion. I'm working on code to
generate a function (or more aptly a ton of points that don't
necessarily fit what we think of as a function but would pass the
algebra I vertical line definition of a function) that comes from the
median distance between two vertical points that define the positive
and negative ribbons because as Jiong pointed out, the ribbons seemed
to pick out a PIL inversion line all their own. So, I'm going to
try to capitalize on that idea, and see if I can make the code that
picks out the flare ribbons also pick out a pretty nice PIL that
doesn't have the nasty un-natural characteristics of a multi-degree
polynomial fit-function. I'll probably work on this until
lunch-ish tomorrow (assuming it works as desired). Then,
hopefully I can get back to that HXR business which I find a little
oddly fascinating and, dare I say, exhilarating.
June 23, 2008
Made a nicer,
higher cadence movie after taking at least an hour to figure out
that where I intended a plus sign to be, there was a negative sign.
So, this movie has 8 second counts with contour lines defined as levels
= (findgen(6)*40) + 70 I may need to go back and change that to a
higher count integration, but during the flaring time, where I actually
care about the HXR stuff, we appear to have nice solid
footpoints. I have to say that I still am not comfortable with
the pointing coordinates here. The footpoints always seem too far
to the right in the image. I think I'm just going to have to tell
the program specifically what coordinates I want for the HXT images
though. I'll try that and post the movie later.
I do know from the Fletcher and Hudson paper that the HXR sources have
an uncertainty of 3.2", and I should probably keep that in mind as I
cycle through these images. Also, as a reference, the M2
light curve
Next I want to generate a table that picks out what cells the HXR
footpoints are found, and then calculate the reconnection flux
then. I probably want this to match the cadence of that
movie. So, I probably need to write a program to do that for me,
but I'm not sure how to execute that. I'll go talk to Jiong and
see what she thinks.
Howver, I think I may be able to produce a coaligned HXR image to my
MDI data (so I need to make the HXR images 520 x 376). My HXR
images would be contour images. I would have to give the lines
valus of 1 and all else values of 0. Then, I'll have a program
use my tessellation map, which has each cell with a different integer
value, pick out what cells are > 0 as cells with HXR
footpoints. Then, I need to calculate the sum of reconnection
flux of those cells the program finds for that time, which would simply
be the TRACE frame closest in time to the HXR photon integration as the
TRACE cadence is not nearly as nice as the HXR cadence. Then, I
want to compare that for the total reconnection flux of the whole flare
and see what I find. I'm not sure how to fulfill all those steps
in programming just yet. So, definitely talk to Jiong.
And ran through my mapping program and just input HXR coordinates
manually in order to obtain images something similar in nature to what
Fletcher and Hudson have instead of reading points from the SXT
scope. I think it looks a little better. So, hopefully this
movie is better. I should also point out that I added a line
of code to the program. So, what you see in the right corner is
the upper bound of the HXR time interval, and in the lower right corner
is the TRACE flare brightening time you're seeing. And the movie
looks more akin to what I see in Fletcher and Hudson's paper.
I must also point out, and this didn't occur to me last summer that at
about 10:33 - 10:34, we get nice footpoints back in the HXR data, and
what do I find in the reconnection rate!?! Another peak!
Albeit a much smaller one, but it's certainly there. I definitely
need to get that table I mention above worked out.
June 20, 2008
Okay, spent
yesterday troubleshooting my HXR program. Finally have an HXR
movie that might be at least mildly comprehensible to show for
it. I used a fixed level contour with a dt time interval of 8 s at
the M2 band and WITHOUT a necessary count
accumulation in hopes that there would be stuff to discern. If I
am thinking properly, where we have flooded areas without discernable
footpoints is simply because of a lack of photon counts. I should
also say that the red lines are hard x-rays and yellow lines are flare
brightenings with the time displayed in the upper right (disregard the
time atop the map) being the upper limit of the hard x-ray data
accumulation time of 8 seconds. So, that's telling me that there
is a peak of photons where I see the nice concentrated rings since it
was integrated over a uniform time scale (at least, I think so).
So, it appears, without looking at those images too closely because
I've been looking at them for too long, that there is as we saw last
summer a correlation between peaks in photon counts and flare
brightening. Of course, I need to actually look numerically at
what's going on with the reconnection sequence and reconnection flux
when and where I see those photon count peaks. That will probably
come next week.
Anyways, for future reference to myself as my written notebook is
scattered since I keep pretty extra scattered state of affairs, if I
ever have to coalign TRACE and YOHKOH HDA onto MDI:
For the TRACE, which you will have coaligned already to the MDI and to
give it mapping coordinates:
dx = median(deriv(MDI_image.x)) and same with dy
xc = mean(MDI_image.x) and same with xc.
Make sure to give the subsequent TRACE map a reference time for which
to assign arcsecond values to
For the HXT:
Get index and data structures: .run yodat
Get pointing data from SXT: xy0 = get_hxt_pos(sxt_struct =
sxt_index)
Then, use hxt_multimg something to the tone of:
hxt_multimg, hxt_index, hxt_data, index_out, data_out,
/new_mod_patterns, xy = xy0, img_trange=[hxt_min, hxt_max], bck_trange
= ['14-jul-00 10:54:00', '14-jul-00 10:55:00'], channels = 2,
dt_resolution = 8
Then, to plot the HXT onto MDI, which likes to use arcsecond reference
points:
Convert the HXT coordinates back to SXT coordinates: mid_coor =
conv_hxt2p(hxt_coor)
Then, convert it to arcseconds, and praaay you give it a reference
date, or you'll be scratching your head for an hour figuring out why
your maps don't line up (answer: because 2008 is 8 years after 2000):
fin_coor = conv_p2a(mid_coor, '00-Jul-14 10:19:50')
Then, make your maps, as you normally would (always include a time!)
with the make_map function. Use plot_map to make the actual
coaligned maps with the /overlay keyword.
Also, I remember now that I had to apply a correction to the pointing
coordinates of my HXT map because the footpoints just weren't making
sense otherwise. So, I also applied the following corrections to
the mapped HXT data:
x = -4.272 as
y = -1.1977 as
I obtained those numbers from the maps I created last year that were
pretty spot on and simply calculated how far off the xc and yc
coordinates were off for the two different maps. Done and done.
And I also put together the hopefully generalized show_flux_rate.pro
for Eric. I think he's working with it right now and deciding
whether or not I successfully generalized it. He's looking
exasperated and successfully giving me a feeling of ultimate failure as
an IDL programmer.
For the time-being, I think I'm going to fiddle with the calculation of
the PIL for the Bastille. (P.S. 24 days until that spectacular day in
1789 when Rousseau came into just more than slight prominence)
June 18, 2008
For the time
right now, I'm working on making a higher cadence movie of the hard
x-ray footpoints and TRACE flare brightening overlaid on my MDI
magnetogram. This is a little bit more difficult than the last
one though. Right now, I'm putting together all the code that
creates data maps for MDI, TRACE, and YOHKOH HXT data and creating a
time series of them at a cadence of 30 s per frame. Once I get
the code done, it should be pretty quick to getting the movie done.
June 17, 2008
Re-began work on
my hard x-ray (HXR) data today. Referring to the HXR
maps I created last summer, my plan of attack is to analyze the
regions when and where I found those HXR footpoints to occur and to
generate calculations on the ribbon expansion at the time (doing a
brief interval of time since we obviously can't calculate an
instantaneous velocity) and locations of peaks in the hard x-ray data
and see what I find. Right now, I'm stuck trying to generate the
ribbon expansion data, which finds me stating to any OS X 10.5 using
astronomer that to enable the functions using a cursor in IDL via an
X11 terminal, you should type in the following command at the X11
terminal window:
defaults write org.x.x11 wmclickthrough -bool true
It'll make life better. I promise. After having solved that
problem, I'm trying to figure out how the !err variable works.
I'll keep you posted, log, on how I manage.
As promised, !err comes back >1 if the middle or right mouse button
was pressed last. I feel a little like a not-so-sly-genius.
But I'm still struggling to have the program calculating ribbon
expansion to run error free because I probably need to modify a few
more things within it to work for the time and location I want to focus
on, and it's that time. So, I'll work more on it later tonight,
or just wait until morning.
June 16, 2008
Okay. So, I
went ahead and tried getting through the programs to calculate
components of the ribbon
velocity with regard to the PIL
I calculated last Friday. The left side plots are positive cells,
and the right side plots are negative cells. They also go from
top to bottom: Ribbon Length, Distance along PIL, Distance Perp
to PIL. Though, the middle positive plot confuses me a little
bit. The rest seem to imply what I've noticed before: the
ribbon is formed early on (as seen in the top plots), and then the
ribbon expands outward from the PIL while keeping roughly the same
length. Of course, as I said, these plots need tweaking as some
more work should probably be done on defining the PIL.
June 13, 2008
Here's a map of
my PIL
June 12, 2008
Finally got the
color map created with everything I wanted for it. I included a
nice screenshot of the correlation, color, and tessellation maps all
laid together for future references at the top. That may change
in due time as I generate new data though. I should run the
correlation program with the different cuts I have for the reconnection
rate though. Beyond that, I need to start working with the
porgram to find the PIL for my AR.
Altering the binsize and cut off correlation for the correlation maps,
it seems that binsize = 8 (+/ - 2 min) seems to work the best for my
flare. Using the default cut_cor = .7 seems to work the best
too. This is using a multitude of flux rate flare brightening
cut-off parameters ranging from 5 to 12. They all seem to be
telling the same reconnection story concerning the cells, except with
the smaller binsize (8 as opposed to the default 10), the stages become
much more distinct. Here's the correlation
map with binsize = 8 and cut_cor = .7. This is now the same
as the one on the top, just alone. I think the most interesting
thing to note is that at about 10:19 UT and 10:24 UT, the same cells
seemed to be involved in the reconnection, though there is a very
clear pause between those two spikes in reconnection rate.
Starting my work on the calculation for the
PIL, I can tell immediately that for my AR I need to break the
calculation of the polynomial for the PIL into segments, or the AR is
just too much to handle for the calculation of a polynomial. So,
I'm going to construct a loop that works for smaller segments of the AR
and then connect the different segments into one large array.
Hopefully, that will work well. I'll start that this afternoon
and work more arduously on it tomorrow, but it should be straight
forward to code.
June 10, 2008
Nothing new to
log today. Worked to make the reconnection analysis program work
for any flare reconnection rate data (hopefully). Currently, I'm
working on developing a new/better color map. Hopefully, I can
work on that for a bit tomorrow to fit to my flare data and get that
done. Then, on Thursday, I should start working on the stuff for
the polarity inversion line (PIL) and measuring the expansion of my
flare with respect to the PIL. Bis dann.
June 9, 2008
All right, I
think I've managed to modify Jiong's series of programs that pick out
the reconnection
sequence. The top graph looks phenomenal! It picks out
just about everything! The total ratio of flux from positive to
negative reconnecting cells appears to 0.869848, if I'm reading the
output of the program correctly, which is kind of definitely nice to
see. I'm not so sure about the bottom graph though because if the
ratio between cells is that value, the bottom plot would appear to
undermine that result. Right now, my eyes are hurting too much to
go through the code carefully enough to make sure it's doing what I
want it to. I'll leave that to the morning, and if it does turn
out to be incorrect, I'll replace that link above with the correct plot.
June 6, 2008
In the brief time
I've got today, I'm running flux_rate for different cut thresholds for
flare brightening (default = 10., which is what I've been using).
For the time, I'm allowing cut = 5., but pending how prep_flux ends up
functioning with this new run of flux_rate, I may do more with
different cuts, which reminds me:
Kudos to Keiji for making the servers about a 1000 times faster this
summer. flux_rate takes less than 20 minutes to complete now and
doesn't hog the server. I am pleased.
June 4, 2008
Went ahead and
made another one of my numerous time-scale color maps of the flare
evolution with the new tessellation map. It certainly has fewer
cells to deal with. I've put it at the top as a permanent
reference for myself.
The next thing to accomplish is to perform the reconnection analysis on
the new tessellation. Then, I want to compute the topological
model flux and compare it the observed via some tables. Then,
work on energetics with my hard x-ray data and the reconnection
business.
June 3, 2008
Okay. Back
at it. Recalculating the flux rate of the Bastille Flare with a
new tessellation map that Masha has constructed.
Note to self for future reference:
In the future, make better notes to yourself about what in the world is
in a save file.
|