August 1, 2008
I threw together a plot of the energy
release rate and reconnection rate. I scaled the energy reconnection
rate by a factor of (max(Rec. Rate)/max(En. Rel. Rate)) so that the
plots lined up better. The plot can be found at
/disk/data/ewolf/MDI/energy_rec_rates.eps
July 31, 2008
Ok, I've summed up the model reconnection
fluxes
for positive and negative cells. Of course, there are a few options for
the sums:
1. Sum over all positive/negative cells, including their reconnections
to infinity
2. Similarly, excluding connections to infinity (this actually forces
flux balance)
3. Sum over flaring positive/negative cells, including reconnections to
infinity
4. Similarly, excluding connections to infinity (again, flux balance is
forced here)
5. Summing for flaring cells, but summing over their connections to all
other cells
6. Similarly, but excluding the connections to infinity
A table of results
|
Positive ( 10^21 Mx)
|
Negative (10^21 Mx)
|
All Cells + Infinity
|
6.07
|
5.23
|
All Cells Only
|
4.45
|
4.45
|
Flaring Cells + Infinity
|
2.88
|
1.25
|
Flaring Cells Only
|
1.25
|
1.25
|
Flaring Cells to All Cells
+Infinity
|
4.71
|
2.36
|
Flaring Cells to All Cells Only
|
3.09
|
2.36
|
So, we have the best agreement with observation when summing over all
cells.
July 29,
2008
Since most of the flux emergence seems to
happen before Nov 5, 06:24, I redid the connectivity calculations using
this time as the initial time and flare time as the final time (frames
33 and 41 of the mask file, respectively). Some results:
Spreadsheet
|
All Cells + Inf.
|
All Cells Only
|
Reconnecting Cells + Inf.
|
Reconnecting Cells Only
|
Halpha (Max Values)
|
Halpha (At 110 min after 19:00UT)
|
Postive/Receiving (Mx)
|
4.02e21
|
3.67e21
|
1.00e21
|
1.00e21
|
4.08e21
|
3.97e21
|
Negative/Giving (Mx)
|
-5.08e21
|
-3.66e21
|
-2.52e21
|
-1.10e21
|
-6.22e21 |
-5.00e21
|
Balance (Small/Large)
|
79.03%
|
99.54%
|
39.73%
|
91.01%
|
65.59%
|
79.4%
|
So the giving/receiving flux balance is very good when not including
infinity. Could this mean that the donor domains are giving flux to
some Infinity-Infinity domains, that is, some domains that lie outside
the field of view that are still involved in reconnection? That is,
something like this situation:
Net Giving Situation
In this case, a too-small field of view would cause the given flux to
be larger than the received flux, and since this flux is transferred
away from Infinity domains, we would expect that when we exclude
infinity from the calculations, we wouldn't see this source of flux
imbalance - which seems to be the case here, as the balance is much
better when excluding infinity.
Scatterplots
Ok, the balance isn't very good here, but we can explain this by saying
that the cells that are furthest away from the unity line (P1, N1, N2,
N7, N8) are the oldest cells. Since we are taking such a short time
span to calculate the connectivity change, we are probably missing a
significant portion of the footpoint motion, which gives us less of a
change in connectivity.
Also, these points seem to lie on a line, which could also suggest we
are missing footpoint motion that contributes to connectivity change:
Suppose the connectivity change happens at a rate of r
i over
time interval T for cell i. Then C
i=r
i*T is the
connectivity change for cell i over time T. If R
i is the
observed reconnection flux for cell i, then, ideally, we would have:
C
i/R
i=1 for each i,
which gives the slope of a line fitted to the scatter plot. Suppose we
only start calculating the connectivity change from T
0, then
our total connectivity change is r
i*(T-T
0), and
the "scatter plot slope" is
r
i*(T-T
0)/R
i = C
i/R
i
- r
i*T
0/R
i = 1 - T
0/T for
each i.
So we would get a constant, but reduced, slope for the scatter plot
points, which is close to what we see.
July 28,
2008
I plotted the total flux in all named
cells (from msk.img) over time:
Total Flux
I used a simple method of projection effect correction. When adding the
flux of each pixel to the total flux, I divided the this pixel's flux by
cos(msk[i].x(x)/1000.*!pi/2)
This produced these plots:
Total Flux (Corrected for Projection Effect)
P01 Flux (Corrected for Projection
Effect)
The active region crosses solar center at approximately November 4,
12:00UT (~36 hours in the plots above); at this time, P01 is rapidly
increasing in flux, according to the plot above. However, since the
active region is moving away from solar center after this, correcting
for the projection effect actually increases the size of the change in
flux over this time.
I plotted the flux in N00 (i.e. in flx(*,0)), and came up with this
plot:
N00 Flux
From 19:40 to ~20:00UT there is a change of ~4.4e20 Mx in N00
reconnection flux, with a short plateau occuring at ~19:50UT.
Ok, I also plotted the flux from the mask file
N00 Flux from Mask File
I obtained this by adding the absolute values of flux of all pixels in
the msk.msk eq 0 area.
Now, I plotted the postive and negative flux in unnamed regions. This
does not account for the projection effect:
Unnamed Region Flux
Ok, I also plotted all flux in named cells and unnamed regions - this
should be everything, again not accounting for the projection effect:
All Flux
July 25,
2008
I fixed the error in my histogram program
that was resulting in counting only one pixel's worth of flux, made the
bin width and centers constant, and added options to overlay another
frame's histogram, and to normalize the pixel count and flux to the
total pixel count and flux of P01 at that time. The programs:
Here are some histograms for frames 23 and 41:
I think the last histogram is the most telling - it does show that the
distribution of flux shifts to lower field strengths from frame 23 to
41. Adding up the difference in flux for field strengths less than 2000
G, I get approximately 3e21 Mx, and for field strengths greater than
2000 G, I get about 6e20 Mx.
I'm trying to determine the area that the saturation spot covers in
each frame, and as Masha suggested yesterday, I'm trying out the
contour function. Here's an image of one contour around P01, from frame
23:
Contour Image
I also made some surface plots to look at the shape of the saturation:
Saturation Plot 1
Saturation Plot 2
Saturation Plot 3
Well, looking at the contour image, I estimated the saturation spot as
an ellipse of semimajor axis 6 and semiminor axis 3. Using the formula,
A = 0.5*Pi*a*b
where a is the semimajor axis and b is the semiminor axis, I get A=9*Pi
square pixels.
If I assume this area to have a magnetic field strength equal to the
maximum (calibrated) field strength in P01, which is about 3300 G, I
get magnetic flux:
Flux = 9*Pi*(3300 G)*7.3e7^2 = 4.97e20 Mx
So even if the magnetic field in the saturation spot were double what I
assumed (i.e., 6600 G), we would only get magnetic flux of about 1e21
Mx. This is less than a third of the value I calculated above as the
difference in magnetic flux in P01 between frame 23 and 41.
July 24,
2008
Today I started to work on the
presentation. I decided which plots and movies I would want for each
slide, and I made some better quality versions of some of these plots.
Here's a summary:
Slide
|
Image/Plot/Video
|
Location
|
1
|
|
|
2
|
Reconnection Animation
|
Peter's Presentaion
|
3
|
Reconnection Rate Image
|
|
4
|
In-situ flux rope formation
(Movement of footpoints)
|
|
5
|
Twisted Flux Rope Picture
|
Masha's Poster
|
6
|
Tessellation Movie/Image
Magnetic Topology Image
|
/www/reu/2008/ewolf/nmask.mov
Masha's Poster
|
7
|
|
|
8
|
GOES Light Curve
Magnetogram Movie
Halpha Movie
|
Solar Monitor
/www/reu/2008/ewolf/halpha_time.mpg
|
9
|
LCT Movie
Helicity Plot
|
lct_jpg_2.mov
|
10
|
Color Map
Flux Plot
|
/www/reu/2008/ewolf/flux_cell_nm.eps
/disk/data/ewolf/MDI/flux_plot_2.eps
|
11
|
Scatter Plot (Observed vs
Connectivity Reconnection Flux)
|
|
12
|
Halpha Overlay Plot
|
|
13
|
|
|
14
|
|
|
July 23,
2008
Tessellation Movie
Connectivity Matrix Spreadsheet
Color Map
Footpoint Plot
Pole Movement Plot
Helicity Plot
Observational Reconnection Flux By Cell
Scatterplots
Maximum Reconnection Flux By Cell:
Cell
|
Observational
Flux (Mx)
|
Connectivity Change
All Cells (Mx)
|
Cell
|
Observational
Flux (Mx)
|
Connectivity Change
All Cells (Mx)
|
P01
|
3.29e21
|
3.03e21
|
N00
|
-3.69e20
|
1.62e21
|
P03
|
1.05e20
|
3.18e20
|
N01
|
-1.55e21
|
3.45e20
|
P04
|
1.15e20
|
1.05e21
|
N02
|
-1.02e21
|
6.46e20
|
P05
|
1.38e20
|
7.09e18
|
N07
|
-8.72e20
|
6.17e20
|
P08
|
2.43e20
|
2.37e20
|
N08
|
-1.82e21
|
3.65e20
|
P10
|
7.94e19
|
6.67e19
|
N11
|
-1.46e20
|
3.87e20
|
P14
|
4.13e19
|
N/A
|
N24
|
-4.13e20
|
N/A
|
Connectivity Summary:
|
All Cells + Inf.
|
All Cells Only
|
Reconnecting Cells + Inf.
|
Reconnecting Cells Only
|
Halpha (Max Values)
|
Halpha (At 110 min after 19:00UT)
|
Postive/Receiving (Mx)
|
7.39e21
|
4.14e21
|
4.15e21
|
9.06e20
|
4.08e21
|
3.97e21
|
Negative/Giving (Mx)
|
-6.32e21
|
-4.75e21
|
-1.60e21
|
-1.60e21
|
-6.22e21 |
-5.00e21
|
Balance (Small/Large)
|
85.57%
|
87.12%
|
38.57%
|
56.59%
|
65.59%
|
79.4%
|
I have been messing around with estimating the number of saturated
pixels in P01, however I haven't gotten anything useful at all for
that! I used this program:
est_sat.pro
I can also use it to generate a histogram of the number of pixels in
P01 at bins of magnetic field strength. I use this program to help:
plot_s_hist.pro
I made a movie of these histograms from frame 23 to 41:
Magnetic Field Histogram Movie
July 22,
2008
Since within the flaring cells there is a
large change between the receiving (positive) flux when excluding
infinity, but no change in the giving (negative) flux, there should be
non-flaring cells connected to infinity that give up flux from these
domains. These non-flaring donor domains are:
Domain
|
Flux Given (Mx)
|
P00-N03
|
-2.88e20
|
P00-N06
|
-3.16e20
|
P00-N10
|
-4.62e20
|
P00-N12
|
-7.02e17
|
P00-N13
|
-1.13e20
|
P00-N14
|
-3.4e20
|
P00-N16
|
-4.75e19
|
Total (P00-NXX)
|
-1.57e21
|
N03, N06, and N10 are close to the flaring region, but the rest of the
negative cells are further away from the flare ribbons. However, there
does appear to be some brightening near N12 and N13, and N14 and N16
are not visible in the Halpha image.
Masha and I checked the overlaying separators, and we came up with
this, which does account for the switching of P10 and P11 in the
tessellation (see plsnlsspr41_fix.pns):
Separator
|
Domain
|
A01-B09
|
P11-N04
|
A03-B04
|
P12-N06
|
A13-B12
|
P15-N24
|
A16-B08
|
P01-N01
P15-N01
|
A16-B12
|
P15-N01
P15-N24
|
A16-B14
|
P05-N01
P08-N01
|
A17-B11
|
P10-N08
|
A20-B06
|
P02-N02
P08-N02
|
A21-B04
|
P01-N18
P02-N18
P03-N02
P07-N02
|
A21-B05
|
P01-N18
P02-N18
P03-N18
P07-N02
P12-N18
|
A21-B06
|
P03-N02
P07-N02
|
A21-B08
|
P02-N02
P02-N18
P07-N03
P08-N02
|
A22-B08
|
P02-N01
P05-N01
P08-N01
P08-N08
|
A22-B14
|
P08-N01
P08-N08
|
A23-B19
|
---
|
A24-B10
|
P01-N08
P01-N11
P01-N24
P08-N08
P15-N01
|
Using this information, and the latest connectivity matrices, I ran the
program psi_find, and saved the output in the file
/disk/data/ewolf/MDI/si_psi_find.sav.
I made some new versions of plots:
- Movement of Poles: /disk/data/ewolf/MDI/move_pls.eps
- Footpoints: /disk/data/ewolf/MDI/footpoints.eps
- Correlation Sequence: /disk/data/ewolf/MDI/corr_pair_nmsk.eps
July 21,
2008
So, I've done some work with the new
version of the tessellation mask that I produced on Friday. Here's what
I've done:
- Using the new mask, I ran flux_rate again. The results are stored
in /disk/data/ewolf/flux_save/flx_rate_cut21.sav. Here's a plot: flux plot.
- I ran show_flux_rate: /disk/data/ewolf/MDI/nmsk_flux_cell2.eps
- Ran plot_corr_sequence: /disk/data/ewolf/MDI/corr_pair_nmsk.eps
- I did the connectivity calculations again, using the reduced
model (throwing out emergent flux). Here's a spreadsheet of the
connectivity matrices: spreadsheet.
And here are the results of the calculations:
|
All Cells + Inf.
|
All Cells Only
|
Reconnecting Cells + Inf.
|
Reconnecting Cells Only
|
Halpha (Max Values)
|
Halpha (At 110 min after 19:00UT)
|
Postive (Mx)
|
7.26e21
|
5.65e21
|
2.95e21
|
1.5e21
|
4.08e21
|
3.97e21
|
Negative (Mx)
|
-7.27e21
|
-5.28e21
|
-4.22e20
|
-4.22e20
|
-6.22e21 |
-5.00e21
|
Balance (Small/Large)
|
99.9%
|
93.48%
|
14.29%
|
28.18%
|
65.59%
|
79.4%
|
I think the balance here over all cells is
remarkable!
- I made scatter plots using these new calculations.
- I made a plot of the movement of the poles:
/disk/data/ewolf/MDI/pls_move.eps
- Using this footpoint plot, I
determined the separators that overlay domains:
Separator
|
Domain
|
A01-B09
|
P10-N04
|
A03-B04
|
P12-N06
|
A13-B12
|
P15-N01
|
A16-B08
|
P01-N01
P15-N01
|
A16-B12
|
P15-N08
|
A16-B14
|
P08-N01
|
A17-B11
|
P11-N11
|
A20-B06
|
P02-N02
P08-N02
|
A21-B04
|
P01-N18
P02-N18
P07-N02
|
A21-B05
|
P01-N18
P02-N18
P12-N18
|
A21-B06
|
P03-N02
P07-N02
|
A21-B08
|
P02-N18
P03-N02
P07-N02
|
A22-B08
|
P01-N01
P08-N08
|
A22-B14
|
P08-N01
P08-N08
|
A23-B19
|
---
|
A24-B10
|
---
|
- Plugging this information into psi_find, I ran that program, and
saved the results in /disk/data/ewolf/MDI/si_nmsk.sav.
- I also made a new topology overlay on the Halpha image: image.
Ok, I looked more closely at the tessellation. I decided that the P10
and P11 labels should be reversed in frames 28-41, for consistency with
the previous frames. I've also noticed that P05 (which is a flaring
cell) doesn't appear in frame 22, so I think this may pose a problem
when comparing the connectivity and observation reconnection fluxes. So
I will repeat the connectivity calculations again, this time using the
newly changed tessellation and frame 23 as the initial time, since P05
emerges in that frame. Aside from the connectivity calculations, these
changes shouldn't affect the results above. Just switch P10 and P11!
I made a new movie of the fixed tessellation. It should be consistent
in the area around the flare from frame 22 (Nov 4, 12:48UT), on.
Tessellation Movie
Here is the spreadsheet for the connectivity matrices from the latest
mask:
spreadsheet.
And here are the numbers:
|
All Cells + Inf.
|
All Cells Only
|
Reconnecting Cells + Inf.
|
Reconnecting Cells Only
|
Halpha (Max Values)
|
Halpha (At 110 min after 19:00UT)
|
Postive (Mx)
|
7.39e21
|
4.14e21
|
4.15e21
|
9.06e20
|
4.08e21
|
3.97e21
|
Negative (Mx)
|
-6.32e21
|
-4.75e21
|
-1.60e21
|
-1.60e21
|
-6.22e21 |
-5.00e21
|
Balance (Small/Large)
|
85.57%
|
87.12%
|
38.57%
|
56.59%
|
65.59%
|
79.4%
|
And some scatter plots:
July 18,
2008
In order to run psi_find, I had to cut out
the separators from the spr structure that weren't overlaying a domain,
or else there would be a conflict in the dimensions of some arrays in
the program. I used the information from the second table below to
figure out which separators should be cut out. I saved the pls, nls,
and the new spr structures in the file
'/disk/data/ewolf/MDIplsnlsspr41_cut.pns'. I saved the resulting
structure, si, in the file '/disk/data/ewolf/MDI/si.sav'.
Problem! I noticed that my mask is even still incorrect! There
are some negative cells that switch names that I didn't correct before.
So I updated my
program to change these
cells, and am starting over again.
July 17,
2008
I am working on determining which domains
are overlaid by each seperator, using this
plot
of the footpoints and this
graph from
sum_graph. Here are my initial results, which I want to check over
again for accuracy.
Separator
|
Domain
|
A04-B03
|
P10-N04
|
A07-B06
|
P15-N05
|
A12-B06
|
P15-N08
|
A12-B08
|
P01-N01
P15-N01
|
A12-B10
|
P08-N01
|
A13-B08
|
P08-N08
P15-N01
|
A13-B10
|
P08-N01
P08-N08
|
A15-B09
|
P02-N02
P08-N02
|
A16-B08
|
P02-N18
P03-N02
P07-N02
|
A16-B09
|
P03-N02
P07-N02
|
A16-B19
|
P01-N18 OR P12-N18
|
I tried again, this time selecting more nulls. I got this
footpoint plot and this
separator diagram. In the table below, I
have italicized the domains that I identified from the footpoint plot
that aren't listed in the separator diagram.
Separator
|
Domain
|
A01-B16
|
P08-N02
P02-N02
|
A02-B13
|
P02-N18
P03-N18
|
A02-B16
|
P02-N02
P03-N18
|
A02-B17
|
---
|
A02-B19
|
P12-N18
|
A04-B13
|
P02-N02
P02-N18
P08-N01
|
A04-B14
|
P08-N02
|
A06-B08
|
P15-N01
P15-N05
|
A06-B13
|
P15-N01
|
A06-B14
|
---
|
A07-B08
|
P15-N05
|
A12-B11
|
P10-N04
|
A18-B19
|
P12-N06
|
July 16,
2008
I made some scatter plots using the
reduced model connectivity matrix:
All Cells, Including P0/N0
All Cells, Excluding P0/N0
Reconnecting Cells Only, Including P0/N0
Reconnecting Cells, Excluding P0/N0
July 15,
2008
As Masha was curious, I got the positive
and negative reconnection fluxes from the Halpha data using the program
flux_plot, and simply have the program
return the appropriate values from the phi_p and phi_n arrays. Using
the fixed tessellation, cut=1.5 and int=1, I ran flux_rate and stored
the results in /disk/data/ewolf/flux_save/flx_rate_cut19.sav. Then I
used flux_plot to make this plot and get the flux values:
I redid the topological overlay for a time later in the flare:
I redid all of the connectivity stuff using the reduced model -
that is, throwing out the emergent flux. I wrote a small program,
pls_flux_fix, to cut out emergent cells
and set the flux in the remaining cells at flair time equal to the
value at the initial time. I made a new connectivity matrix
spreadsheet, and obtained these numbers:
|
All Cells + Inf.
|
All Cells Only
|
Reconnecting Cells + Inf.
|
Reconnecting Cells Only
|
Halpha (Max Values)
|
Halpha (At 110 min after 19:00UT)
|
Postive/Giving (Mx)
|
7.54e21
|
6.99e21
|
3.27e21
|
2.72e21
|
4.08e21 |
3.97e21
|
Negative/Receiving (Mx)
|
-7.2e21
|
-4.94e21
|
-5.43e20
|
-5.43e20
|
-6.22e21 |
-5.00e21
|
Balance (Small/Large)
|
95.48%
|
70.68%
|
16.61%
|
19.97%
|
65.59%
|
79.4%
|
I fixed my
program
that calculates the thermal energy and energy release rate, the maximum
thermal energy is on the order of 10^23 J, and the maximum energy
release rate is on the order of 10^20. This is smaller than expected,
and I am still checking out my unit conversions to make sure I haven't
made an error, but it could be reasonable, still. Here are some plots:
Thermal Energy
Nick
pointed out that my arguments in deriv in energy.pro were reversed
originally, so
I wasn't getting the right thing for the energy release rate. I changed
it, and now I get the maxium energy release rate to be on the order of
10^21 J/s, which is about what we expected. Here's a new plot of the
energy release rate:
July 14,
2008
I changed the mask file again, this time
in a way that should work (
program), and
repeated the work I did on Friday. Here
is the new connectivity matrix
spreadsheet, and
here are some new numbers:
|
All Cells + Inf.
|
All Cells Only
|
Reconnecting Cells + Inf.
|
Reconnecting Cells Only
|
Halpha (Max Values)
|
Halpha (At 110 min after 19:00UT)
|
Postive (Mx)
|
1.33e22
|
9.75e21
|
7.92e21
|
4.72e21
|
4.08e21 |
3.97e21
|
Negative (Mx)
|
-9.7e21
|
-7.21e21
|
-1.1e20
|
-1.08e21
|
-6.22e21 |
-5.00e21
|
Balance (Small/Large)
|
72.75%
|
73.96%
|
13.84%
|
22.82%
|
65.59%
|
79.4%
|
And some new scatter plots:
All Cells, Including P0/N0
All Cells, Except P0/N0
Reconnecting Cells, Including P0/N0
Reconnecting Cells, without P0/N0
Ok, next I will be looking at the energy release by the flare. Using
the formulas that Jiong sent, I obtained the following equation:
Eth (t) = 3kT(t)*sqrt((pi*d/2)*Width(t)*Length(t)*EM(t))
Where k is the Boltzmann constant, T is the temperature and EM is the
emission measure (both found from the GOES data), d is the thickness of
the flare loop (assumed to be a constant 1"/730km), Width is the
average separation of the flare ribbons and Length is the length of the
flare ribbons. I wrote a program,
find_width,
to determine the Width and Length values from the results of flux_rate.
I'm now working on calculating the thermal energy, as well as the
energy release rate, but I'm running into some computational problems.
July 11,
2008
By looking at the tessellation movie, I
tried to determine all of the sudden name changes that occur, and then
I wrote some
code that would make
the
cell names consistent over the 30 hours before the flare (that is,
frames 22 to 41). I'm running flux_rate again, using the new mask file.
Well, there does seem to be a problem here! I made a
show_flux_rate plot using the new mask
file, but it seems like P13, one of the cells I wanted to change,
wasn't changed at all! Furthermore, show_msk isn't working, so I
haven't been able to see what is going on very well yet. The following
stuff I did before I realized this, but here it is anyway:
I redid the connectivity matrix calculations (
spreadsheet), and I came up with these
numbers:
|
All Cells + Inf.
|
All Cells Only
|
Reconnecting Cells + Inf.
|
Reconnecting Cells Only
|
Postive (Mx)
|
1.31e22
|
9.27e21
|
7.91e21
|
4.69e21
|
Negative (Mx)
|
-1.2e22
|
-9.64e21
|
-9.71e20
|
-9.71e20
|
Balance (Small/Large)
|
91.6%
|
96.12%
|
12.27%
|
20.72%
|
I aslo made some new scatter plots:
All Cells, Including P0/N0
All Cells, Except P0/N0
Reconnecting Cells, Including P0/N0
Reconnecting Cells, Not Including P0/N0
July 10,
2008
I've finished writing the program,
flux_compare, that makes the scatter plot
of reconnection flux from the connectivity matrix vs from observation.
I'm going to try out a few ways of calculating the reconnection flux
from the connectivity matrix. In general, I am summing the absolute
values of a row or column and dividing by two to get the reconnection
flux for the corresponding positive or negative cell. The first method
I used was to sum only over the cells that covered by the flare, namely
P1, P4, P8, P13, N1, N2, N5, N7, N8, N11. This gives this plot:
So most cells seem to have larger flux from observation. I'll now try
summing over all cells, including P0 and N0:
Well, this reverses the situation. However, now there is very good
agreement for most of the negative cells. Now I'll try it without
including P0/N0:
Well, that looks a little better for P1 and P4, and the others don't
seem to change much.
I made a show_flux_rate
plot for a
slightly larger FOV, and for a longer time range, and some
plot_corr_sequence plots for three time ranges:
0
to 150,
35 to 60, and
60 to 110.
July 9,
2008
We discovered that plot_corr_sequence does
work after all, and for some inexplicable reason I was simply unable to
properly display the results yesterday. I have been looking at the flux
balance today, and to help with that, I modified a few programs to
produce plots that only include flux from the reconnecting cells, which
were found by plot_corr_sequence. These programs are
With these progams I produced the following plots, using the cut=1.6,
int=1 results using the extrapolated field:

Well, I improved
show_flux_rate so
that the lower axis label is now readable for most time ranges. I have
also started writing a program that will plot the connectivity
reconnection flux versus the observed reconnection flux in a scatter
plot, but the program isn't working quite yet.
July 8,
2008
I
am going to try one more thing with flux_rate, using cut=1.6 and int=2,
just to see what happens.


Ok, for now I am going to proceed with the cut=1.6, int=1
results from the extrapolated field, which are found in
/disk/data/ewolf/flux_save/flx_rate_cut12.sav. Ok, to use
plot_corr_sequence, I need multiple flux_rate save files. So I'll use
the previously listed file, and flx_rate_cut16.sav, the file from
cut=1.6, int=2 as above. I put a copy of each in
/disk/data/ewolf/flux_save/prep.
When I attempt to run plot_corr_sequence, I get this error:
% Program caused arithmetic error: Floating underflow
% Program caused arithmetic error: Floating overflow
% Program caused arithmetic error: Floating illegal operand
I'm trying to see what is going on. Well, the program does generate the
blank frames with coordinate axes and labels and so on, so it does get
somewhere. Indeed, the program seems to run almost the whole way
through, but it doesn't manage to plot any real data. So it might be
that the programs it calls, prep_flux, multi_evol_corr and evol_corr
are somehow giving some bad results, although they do seem to run, too.
So, I'm looking at the code for these programs to see what is going on.
So for I have come up these possible issues:
- index might be different, since it now comes from Halpha data,
rather than TRACE (line 42 and following in prep_flux)
- it seems strange to take the 30 s cadence data, then interpolate
it to 10 s cadence, and then go back to 30 s cadence (prep_flux)
- there are some mysterious lines: idx1=s1-13, idx2=s2-13
(prep_flux lines 33/34), I may need to change the 13 to some other
value, when I figure out what it is (these don't show up elsewhere -
may be irrelevant)
- when calling multi_evol_corr (plot_corr_sequence line 26), rflx1
and rflx2 are divided by 1e18, which might need to be changed
- seeing that the axes do get plotted, the problem might lie in the
for loops with:
- ss = where(seq(*, i) eq 1, nss)
if nss gt 0 then oplot, ctim(ss), replicate(i+1, nss), psym = 6, thick
= 3 (plot_corr_sequence lines 55+)
Well, now that I have a better understanding of what is going on in the
program, I can test out some of these ideas tomorrow to see if anything
helps.
July
7,
2008
I made show_flux_rate plots for the
extrapolated field results with
cut=1.5,
cut=1.55,
cut=1.6, and
cut=1.7. I also plotted the flux ratios
for these parameter choices:
I then ran flux_rate again using the extrapolated field and cut=1.55:
I altered flux_rate slightly, so that it allows values of int greater
than 1. However, this means that the outputs will have entries of zero
for the first int frames.
July 3,
2008
I am going to run through flux_rate again
this morning before we leave for Glacier.
Extrapolated Field, Cut=1.7
The curves seem to match each other well in this one; however, now they
both display the strange features of the inflection point at ~60 min
and the following concave up region.
Well, I was going to try to vary the int parameter, but it seems as
though int=1 is the only possible choice, by the very construction of
flux_rate. Flux_rate calls test2 on increasingly large portions of the
data, but the length of the data must be greater than or equal to int
for test2 to work. So, any choice of int greater than 1 will cause the
first data selection to have a length smaller than int, which causes
the program to crash. I'll need to look further at the program to
determine what changes would be necessary to allow other values for int.
July 2,
2008
Once again I am trying different out
different things in flux_rate. I extrapolated the magnetic field to
2000km from the magnetogram in 'mmap_41.sav' using lff_field.pro, and
saved the resulting field as pmmap in 'pmmap_41.sav'. I then ran
flux_rate using this data:
cut=1.5
This does improve the flux imbalance. I will try some other choices for
the cut parameter:
cut=1.6
I also updated
cell_flux_plot to
include some code from show_flux_rate to determine the cell names,
which results in these plots:

July 1,
2008
Today I am varying some parameters in the
flux_rate program in order to minimize the flux imbalance that we have
previously seen. I started by varying the cut parameter some more:
Cut=1.5
Cut = 1.65
Cut = 1.7
It looks like an inflection point is present at roughly 60 minutes,
especially in the positive flux curves, and that this becomes more
pronounced, in both curves, as the cut parameter is raised. The
imbalance also decreases, so I will now vary the int parameter using
cut =1.7.
Int=1
This is nearly identical to the previous image, which had int=10, so
perhaps it would be better if I tried varying other parameters before I
try other values for int. Actually, the previous image had int=1, too,
so the settings were actually identical.
I wrote a program,
cell_flux_plot,
to
plot the flux of each cell over time. However, I don't think the labels
are right yet for the cells:
June 30,
2008
A note on the mystery of P09: In the
calculations from the connectivity matrix, we had noted that P09 had a
strange amount of reconnection flux for it's size and brightness in the
magnetogram. However, I looked again at the tessellation movie, and P09
actually starts off as a rather large cell that is to the left of the
FOV that I used in flux_rate. Two frames before the flare, this P09 is
suddenly renamed P15, and a very small emergent cell in the main FOV
gets the name P09. So it is no wonder that we find such a large change
in flux, since the first cell to be named P09 must have had much more
flux than the second.
I ran
flux_rate twice more, using the
Halpha coalignment I did on Friday, and using cut =1.55 and 1.6, using
the normalization that is generated within the program. I wrote a short
program,
flux_plot, that plots the
positive and negative fluxes over time from the flx array produced by
flux_rate. This program generated these plots:
For cut = 1.55
For cut = 1.6
Using the lower cut of course increases the total flux counted, and
also the absolute difference between positive and negative flux, but
the trend seems overall unchanged by the change in the parameter. I
made show_flux_rate images for
cut=1.55
and
cut=1.6, and it seems that,
especially at the end, that cut=1.55 produces more continuous regions,
so this is perhaps the better choice here. I made a
movie of the show_flux_rate images made
from this data at 25 frame intervals.
I plotted the ratio of positive to negative flux for cut=1.55:
I also made a
movie of the
coaligned Halpha data also displaying the time.
June 27,
2008
I did the coalignment of the Halpha data
again, this time using the keyword MISSING = bgcv(i) in poly_2d. I was
surprised that a wider swath of interpolated pixels appears on the left
side than in the previous attempt, but I suppose this can vary
depending on the selection of points. I noticed that the output of LCT
has
dimensions twice that of the original MDI image ((316, 220) versus
(158, 110)) and that I had rebinned the MDI and Halpha images
previously to make everything have the same dimensions, though I wonder
if this might cause some artificially brightened regions due to
interpolation, causing the large number of pixels counted in flux_rate.
For now I will rebin the Halpha data again to get the same dimensions,
and save it in the file halpha_data3.sav. I also made a
movie of the coaligned Halpha images.
I reran flux_rate on the new coalignment using cut=1.6 and bgcv
from data. However, this resulted in the strange result of the pos
images being all black except for the first several frames. I am not
sure what causes this! I modified
run_sfr08375,
adding a keyword that creates multiple images, each spanning several
frames. Since it will take a while to run flux_rate again, I used the
same flux_rate results as before
(/disk/data/ewolf/flux_save/flx_rate_cut2.sav). Here are the images
produced using intervals of
15 frames and
25 frames.
June 26,
2008
I have been continuing to work with
flux_rate and show_flux rate, varying some parameters in each program.
First, I ran flux_rate again, cutting out the 25 left most pixels from
the image, since there appears to be a bit of blurring from the
coalignment in the corner. However, this blurring is quite small,
especially compared to the previous selection; I think this results
from using a much smaller field of view of the magnetogram. So while
this may have affected the previous results, the effect might have been
small. Due to the change in dimensions of the resulting arrays, which
are not present in the msk file, I have needed to adjust
show_flux_rate. However, this isn't working quite yet!
On Jiong's suggestion, I ran show_flux_rate again, this time
including frames 75 to 300 (where before I only used frames 75 to 140),
as there appears to be more activity later on. This produced this
image. In the later times not shown in the
previous image, there appears to be greater overall northward expansion
of the flare ribbon, as well as westward expansion into N11 and
widening of the eastern part of the flare ribbon. Based on the new
image, I decided that the cells covered by the Halpha flare ribbon are:
P1, P5, P8, P9, P13, P14, N1, N2, N3, N5, N7, N8, N11, and N18.
I then produced connectivity matrices for frames 41 (just before
flare time) and 22 (about 30 hours before flare time) from the mask
file, using connectivity.pro, and then used mkcm2csv.pro to convert
these matrices into text files. I imported these text files into a
spreadsheet editor to cut out rows and columns of just zeros. I also
noticed that there are three unlabeled rows and columns present, and I
am not sure what to make of them! I also used the spreadsheet program
to find dcm = cm(flare time) - cm(earlier time), then cut out
everything except for the cells listed above. Adding up the positive
and negative fluxes, I found a total positive flux of 3.36e+21 Mx and a
total negative flux of -6.36e+21 Mx, which gives a difference of -3e+21
Mx. The dcm matrix can be seen
here.
As a side note, I had forgotten earlier to post a link to the
images for the
helicity plot
and the
topology overlay on
the Halpha image produced using the tessellation with 535 G saddle
point value.
June 23,
2008
I modified
show_flux_rate
some more so that it is now more generic. It now calculates nx, ny,
x_nex, and y_nex from other keywords, and it has a keyword htim that
can be set to use the htim array from the Halpha data instead of index.
At this time, beg_xr must be the same as end_xr, and likewise for
beg_yr and end_yr, for the program to run correctly. I added in some
code that produces the time axis (the lower, color coded axis) from the
inputs, instead of having to figure out the appropriate limits
manually. I ran flux_rate (without using the bgcv keyword), and after
the changes to show_flux_rate, I got this
image
(in EPS format).
I also worked on
flux_rate so that
it will work with the bgcv keyword, and that it applies the correction
factor of 1.56 only when the keyword /correct is used. However, after
running flux_rate with the bgcv keyword and
cut = 1.55, I found that there were so many pixels being counted
by the program as having a value greater than bgcv(i)*cut that the
limit of a for loop would get too large. I was able to get around this
by setting the data type of the limit to long, but I was curious
whether this indicated other problems. In fact, putting this data into
show_flux_rate caused an error that hadn't occured previously. I had
noted that the value for bgcv calculated by the program when the bgcv
keyword is not used is roughly 10% higher than the bgcv data, but they
share the same general trend:
So, using the bgcv keyword, the program is certainly counting more
pixels. I am running flux_rate again, this time using cut = 1.6 to see
if this will resolve the issue.
June 20,
2008
Today I made another movie of the
tessellation with the saddle point value of 535 G, this time with a
higher display cutoff of 2000.0 G. This movie can be found
here. It shows the features of
the region more clearly, and it shows a darkening in the middle of the
largest positive area, which could be saturation. Nick gave me a new
version of
show_flux_rate.pro,
which
is much more generic than the previous version. I wrote a small
program,
run_sfr08375.pro, which
handles restoring the necessary files and providing the correct
parameters to run show_rate_flux. Show_rate_flux still requires a few
tweaks so that it will run without errors, as it still won't run all
the way through. I am planning on removing the nx, ny, etc keywords and
instead calculating them from the other keywords to simplify the
process. I also wrote a short program,
htim2UT.pro,
that interprets the htim array from the Halpha data in HR:MIN:SEC UT
form.
June 19,
2008
I tried more settings for the saddle
point, and I found that some the appearance of many smaller cells was
suppressed at the setting of 535 G. I made another movie of the
tessellation and of the
flux histograms. A new cell,
P06, does emerge in the main positive flux region, but we decided to
merge it with another cell. I started using flux_rate.pro and
show_flux_rate.pro, which both still require some work before they will
be usable for my flare.
June 18,
2008
I redid the tessellation with different
saddle point settings, and made movies, for settings of 375 G (
movie) and 415 G (
movie). I also used the program
pls_phi_hist to look at the magnetic flux of each cell and of the
complete region for each tessellation (
375 G movie and
415 G movie). Both settings
produced very similar results, but as the 415 G setting produced fewer
finely divided, small cells, I think it is preferable to procede with
that setting. I prepared to run flux_rate.pro and show_flux_rate.pro;
however, show_flux_rate.pro will need a few more modifications before
it will work.
June 17,
2008
The LCT and tessellation is now complete.
I coaligned the Halpha data with the new field of view, and made a
movie for the
LCT and for
the
tessellation, and
a new set of images:
Topology overlayed on Halpha image:
With separators:
Helicity:
June 16,
2008
In order to have a reasonable
tessellation, I reselected the active region, cutting out a smaller
area around the main poles, and I changed a parameter so that the
magnetic fields were not scaled by the weak field factor in the program
mdi_rd. I am doing the LCT again, and then I will do the tessellation.
I also made a tessellation movie
(/disk/hl2/data/ewolf/MDI/movies/Tessellation.mov) and a
better quality version of the LCT movie
(/disk/hl2/data/ewolf/MDI/movies/LCT_JPEG.mov).
June 13,
2008
I modified the program
mmovie to rotate the Halpha images so that
they were oriented correctly. I also added a keyword to produce MPEG
movies at the highest quality available from MPEG_OPEN. I used this
program to make a movie from the coaligned Halpha data, which can be
found at
/disk/hl2/data/ewolf/MDI/movies/08375halpha_coaligned_hq_rebin.mpg. I
used
the program lct2pns_adv to do the tessellation for the magnetograms. As
discussed with Jiong and Masha, the results are too complicated to be
useful, so we will need to make some changes so that we get a managable
result. Some results are:
Tessellation at 23:59UT 02 November 98
Tessellation just before flare time
Plot of the sources, nulls and footprints at 23:59UT 02 Nov 98
And just before the flare time
An overlay of the previous plot on the first Halpha image
And a plot of the helicities:
June 12, 2008
The LCT has finished now, and the images can be
seen in this
folder. However, a problem arose,
since the last image had one fewer row than the others. To get around
this, I copied the last row of this image and added it on to the image
again, and so produced a new image that had the same dimensions as the
others. I wrote a program,
make_movie_jpeg,
to produce a movie (/disk/hl2/data/ewolf/MDI/movies/lct_movie_jpg.mpg)
from these images,
but the quality is quite poor, and I think it will be necessary to
produce a movie from the data without first converting it into a jpeg.
I also began tessellation on this data, using prep_msk_mk and
lct2pns_adv.
June 11, 2008
To preserve the validity of the MDI header
information, I repeated the mkst07nov04 process, while using the
following code that Jiong provided for the rotation:
nimg = rot(img, p,
mag, x0, y0, /pivot)
This preserves the center of the solar disk, and does not cause the
error that was occuring when using square brackets in the argument. I
will now start the LCT for all of the images generated from this. The
first two results can be seen below. I also downloaded the Halpha data,
and as a first step made a movie
(/disk/hl2/data/ewolf/MDI/movies/08375halpha.mpg) using a
program,
mmovie, similar to the previous
movie-making programs I've made. With Masha's help, I coaligned the
Halpha images and the magnetograms, using the programs setpts and
poly_2d, and stored the results in this file (6/18/08: link removed due
to size - /disk/data/ewolf/MDI/08375coaligned.sav). I still need to
normalize the Halpha
images using the bgcv curve.
The first two LCT images:
June 10, 2008
We
discovered that the magnetograms I've been working with are not
corrected for the tilt of the solar rotation axis, which for these
times is approximately 9 degrees. This angle is stored in the header of
the fits files as 'SOLAR_P0', so using the following code, we were able
to correct for the tilt:
p = sxpar(hdr,'SOLAR_P0')
nimg = rot(img, p)
I tried to rotate about the center of the solar disk, using the [mag,
x0, y0] input and the /PIVOT keyword, but it resulted in errors.
Luckily, it seems to work well without them. I then used mkst07nov04
and make_movie_dat to make a movie from the data from 03 to 05 Nov 98,
which can be found at
/disk/hl2/data/ewolf/MDI/movies/08375ar03_05nov98.mpg. I will
run LCT overnight, and prepare to do the next steps.
June 9,
2008
Today, I followed
Masha's
instructions to cut out the active region from the fits files and
begin local correlation tracking. I also made a movie from these
cropped images. To accomplish these tasks, I modified the programs as
in Masha's instructions, and used
- comp_seq_1 and comp_seq_2,
two batch files that simplified the compiling process given in Masha's
instructions, and
- make_movie_dat, a modified
version of make_movie that uses the files given by mkst07nov04 to make
a movie.
It became apparent that my first attempt
(/disk/hl2/data/ewolf/MDI/movies/08375movie_cut.mpg)
did not contain the full active region, so I tried again
(/disk/hl2/data/ewolf/MDI/movies/08375movie_recut.mpg) by reselecting
the active
region. This now contains some area outside of the disk, and I am not
yet certain if this will be troublesome. In the meantime, local
correlation tracking finished on the first two frames of the first
attempt. The results of which are:
June 5,
2008
As of today, I have produced a movie from the 96 minute cadence
MDI
magnetograms of the active region NOAA 03875 from November 3 to
November 5, 1998 (see
Solar
Monitor for comparision). To do this, I wrote some code:
- read_MDI, a program that uses rd_mdi
to create a 3D data cube of
the magnetograms, based on the code given in Jiong's daily
REU instructions for 2007/06/07,
- co_sel, a batch file that makes it easier to
use wdefroi to
select the active region over the total timespan, and
- make_movie, a program that uses the
results from read_MDI, the parameters found using co_sel, and
MPEG_OPEN to make a movie.
I found that the features of the active region were most easily seen
when restricting the data range of the images from -300 to 300. There
are many small
bright and dark spots diffusely spread out around the active region,
and
it was not immediately apparent to me how many of them I should
include. I cropped the image, on Nick's advice, to exclude other active
regions as much as possible. I found it necessary to rotate the images
by 180 degrees and reverse them to get the correct orientation, which I
accomplished using ROTATE(
image,2)
and REVERSE(). The movie can be found at
/disk/hl2/data/ewolf/MDI/movies/08375movie.mpg.