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:

cut_corr
binsize
cont

.70
10
3
Result
.70
10
4
Result
.70
8
4
Result
.80
8
4
Result
.85
8
4
Result
.90
8
4
Result

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:


Positive
Negative
Western Expansion
Positive PS
Negative PS
Eastern Expansion
Positive PS
Negative PS

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:

Energy 1
Energy 2
Total Reconnection Rate
Total
Total and Zoomed
Total and Zoomed
Footpoints of HXR
Same as Left

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.