Eric Wolf's Daily Research Log



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 ri over time interval T for cell i. Then Ci=ri*T is the connectivity change for cell i over time T. If Ri is the observed reconnection flux for cell i, then, ideally, we would have:

 Ci/Ri=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 T0, then our total connectivity change is ri*(T-T0), and the "scatter plot slope" is

ri*(T-T0)/Ri = Ci/Ri - ri*T0/Ri = 1 - T0/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:


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:



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!

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
---


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

All Cells, Excluding P0/N0
all cells except P0/N0

Reconnecting Cells Only, Including P0/N0
reconnecting cells and P0/N0

Reconnecting Cells, Excluding P0/N0
reconnecting cells except 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:

flux plot

  I redid the topological overlay for a time later in the flare:
topological overlay

  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
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:

fixed 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

All Cells, Except P0/N0
all cells except P0/N0

Reconnecting Cells, Including P0/N0
reconnecting cells, and P0/N0

Reconnecting Cells, without 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

All Cells, Except P0/N0
all cells, except p0/n0

Reconnecting Cells, Including P0/N0
reconnecting cells

Reconnecting Cells, Not Including P0/N0
reconnecting cells, no 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:

sum over rec. cells only

So most cells seem to have larger flux from observation. I'll now try summing over all cells, including P0 and N0:

all cells

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:

all cells except 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:

reconnecting cells only

reconnecting cells only

reconnecting cells only
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.

cut=1.6,int=2,extrapolated field

cut=1.6,int=2,extrapolated field

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:
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:

cut=1.5

cut=1.6

cut=1.7

I then ran flux_rate again using the extrapolated field and cut=1.55:

cut=1.55, extrapolated field

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.

cut=1.5,int=10,extrapolated field

cut=1.5,int=10



July 3, 2008
 
I am going to run through flux_rate again this morning before we leave for Glacier.

Extrapolated Field, Cut=1.7
cut=1.7, extrapolated field

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
cut=1.5, extrapolated field

This does improve the flux imbalance. I will try some other choices for the cut parameter:

cut=1.6
cut=1.6, extrapolated field

I also updated cell_flux_plot to include some code from show_flux_rate to determine the cell names, which results in these plots:

cut=1.5cut=1.6


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.5

Cut = 1.65
cut = 1.65

Cut = 1.7
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
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:

cell flux

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
cut = 1.55

For cut = 1.6
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:
Flux Ratio


  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:

BGCV

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:
Topology Overlay

With separators:
Topology with Separators

Helicity:
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
23:59 UT 02 Nov 98


Tessellation just before flare time

19:12UT 05 Nov 98

Plot of the sources, nulls and footprints at 23:59UT 02 Nov 98

23:59 UT 02 Nov 98

And just before the flare time

Flare Time

An overlay of the previous plot on the first Halpha image

Halpha topology overlay

And a plot of the helicities:

Helicity

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:

LCT00

LCT01

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 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:

lct00

lct01


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.