This morning I made 10 images each for 5 different simulation zones as well as the flared disk analytic distribution. The images include: a temperature contour; a density contour; an emission measure contour; a line-of-sight velocity contour; and emission measure histogram; and line profiles at &theta = 0, 45, 90, 135, and 180 degrees of tilt. Each zone has it's own page, which is linked to from my images page.

I then downloaded the full simulation output from Asif of both the &theta¹ Ori C and the &beta Cephied models. I then added a temperature contour on my emission measure plots, and now I'm in the process of making images of just the hot regions from the line-of-sight velocity contours.

The first thing I did was to implement handling of the spin keyword. See my code page for more info on that. Next, I added subtitles to my contours to include: the slice being viewed; the angle of rotation; and the angle of tilt.

I then tried out my emission line profiles on an analytic data set (see my code page for details). After some mistakes on units and whatnot, I got it working, and it actually looks like it's right. So now my code does pretty much every contour and histogram on the analytic data set as well. I also went through and touched up the output histograms so that they give meaningful data in a readable manner.

So it looks like I'm pretty much finished making big changes to my code. Now I can start using the tools that I've created to do some actual science by comparing my results with actual data and then making predictions. The only other major thing that I have to do is to make a quasi-3D model using various time-steps for different slices, which shouldn't be too hard to implement I don't think.

Alright, here we go. First of all, my volume calculation was, once again, wrong. Turns out I didn't have sufficient precision in my rounding. So I fixed that by adding 2 more sig figs. Hooray, it looks good.

Next thing, the way I contour a restricted area was, you guessed it, wrong. So I had to go through both files and make sure that the contouring range only took into account data that was actually being plotted. I think it's right everywhere now, but I'll probably learn otherwise soon enough.

Then I discovered that D3grid.pro isn't overplotting my data points in all of the slices. I still can't figure this one out, but hopfully I'll get it soon. What's wierd is that it has no problem printing the magnetic field contours on all of the slices, but can't do the data points...

• Ok so I'm an idiot. It's working fine now.

Whenever I get finished with that, I need to switch my angle convention from radians to degrees, which shouldn't really be too difficult.

• Nor was it

Then I can fix my coordinate convention (right now I'm not satisfying the right-hand rule).

• Turns out I was right all along. Go me.

Oh, and my rotation method isn't any farther along today than it was last week.

• Although in a twist of fate it may (emphasis on "may") actually be right

When I was done with all of that, I tried to make a Velocity vs. Flux histogram. I got something... not quite sure what it is, what it means, or if this histogram would even be theoretically useful. But I made it, and no one can take that away from me.

I implemented (or at least tried to) David's rotation matrix for zone76. I'm not entirely sure that it's working at this point, but I have put up and image on my images page that shows both halves of the star (something new, I know) with a tilt of 2.6 radians and occultation.

David came back today, so I started getting some real work done again. We looked at the definition of emission measure and found that the definition that I was using needed to be changed, so I did so (see my IDL page for more on this). I then remade my histogram yet again and sent it off to Marc. The shape of my histogram didn't change noticably, but the value for EM (1-100 MK) decreased some.

So Chris sent me my backed up files, and I cross-referenced them and consolidated them so that D3grid.pro now has the best of both versions. Oh, and Godzilla rocks -- nothing like a fast color printer. I then proceeded to make a backup folder on my astro account that I'll back up to every week or so in addition to the files on my CS account, which will never again be tarred to send there. Ever.

I spent the morning reading a few papers trying to get a more exact definitino of emission measure. What I found wasn't all that helpful. I readRadiative Cooling of a Low-Density Plasma by Raymond, Cox, and Smith (1975), Soft X-Ray Spectrum of a Hot Plasma by Raymond and Smith (1977) and Temperature Determination and Emission Measure Modeling of the Coronae of &alpha Centauri and Procyon by Raassen et al. All I really got out of them was that the definition of emission measure should somehow include n_H instead of n_i. The latter paper gave n_H=0.85n_e. I tried to plug this into the EM equation and got EM = &rho / m_H, which seems a little too simplistic; the value of &mu was perfectly cancelled by the coefficients, which to me means that they're actually correlated and I did something wrong.

I then made the brilliant move of corrupting my D3grid.pro file by trying to tar it. So I spent the afternoon redoing that file because I couldn't find Chris immediately to restore the file. Hopefully I'll get the file tomorrow so I can compare the two, because I think my EM calculations are different in the two version of the file.

Finally, I put a routine for calculating and contouring the line-of-sight velocity after the star has been tilted/rotated. The contour at &phi = 0 and &theta = 0 is on my images page.

I tried to tie up a lot of my loose ends today. First of all, I went through zeuscontour.pro and grid.pro and commented them out better than I had done. I also cleaned up the organization a little bit. I gave D3grid.pro some of the inputs that are available to zeuscontour.pro, such as specifying the max and min x and y to plot and overplotting data points and magnetic field contours. I made sure that any input rotation angles to D3grid.pro fall within normal ranges (i.e. 0 to 2&pi).

I also synched D3grid.pro up with zeuscontour.pro a good bit. I made sure that volume and emission measure calculations were being done in the same way, which they now are. I then made an emission measure histogram with D3grid.pro, which of course is a histogram from a slice of the total data (here, 1/8 of the total data). The numbers seem to match up pretty well; with the total volume in zeuscontour.pro, I get a total emission measure above log T=6 of 8.18e55, and with D3grid.pro I get a total emission measure above log T=6 in the slice of 1.02e54 which is exactly 1/8 of what was expected (to within 1%, at least). Also, I checked to see if any of the occulted material would contribute to this value, and it did not, which is correct since the only material occulted is that directly below the southern magnetic hemisphere, a cylinder in which none of the shock-heated material resides.

Interestingly, this new histogram does not have quite the same shape as the one produced by zeuscontour.pro. I'm not sure why this is, but my hypothesis is that it is due to disproportionate changes in volumes when changing from representing the entire sphere to representing only a fraction of the sphere.

Ah yes, my first saturday in the lab. Touching. Anyway, as per Marc's request, I remade Figure 6 in their paper for them and sent it to Marc. But for some reason, since I made it on my linux box or because I didn't have the psopen.pro and psclose.pro files, it didn't look quite right. So I came in this morning and did it up right. I've put the resultant image on my images page.

So, now that everything is in order in terms of volume calculations, I went back and redid my emission measure histogram. Much as I expected, it did not change noticably. I emailed Marc and David about this, which led to some changes in the calculation of emission measure (see my code page). This, again, did not change the appearance of the histogram. However, it did lead to me getting very close to the observed value of emission measure - 8.18e55 cm³, which I'm obviously pretty happy about.

Other than that, I pretty much spent my day banging my head off the proverbial wall that is my spherical coordinate rotation algorithm. I still don't really have any coherent direction with this phase of my project, although I need some direction soon or else I'm going to be rather stymied.

First things first, I implemented Stephanie's volume calculation and it appears to have worked. My area calculation is now down the tubes, but I don't really care about that. I then went through and cleaned up my code, removing commented-out junk, print statements, and the like. I then proceeded to attempt to account for the occultion of portions of the stellar wind by the star in D3grid.pro. The details of this procedure are on my IDL page. It appears to have worked exactly as I expected, although the contours don't look so great (through no fault of my own; it's just a contouring error, not a data error).

First thing I did today was create a to-do list. Then I tried to knock things off the list. First, I fixed the text on the plots and color bars. No problem. I then tried to make a histogram of EM vs. T. This led to a bunch of problems. Turns out that mine doesn't match Marc Gagne's, but we don't know why. David and I found that my volume calculations are wrong, but I don't believe that this is causing my histogram to be so different. Still, my volume needs to be fixed, and that's the task for now.

My main hypothesis is that the points on the grid are not consistent in radial separation; lines of constant theta closer to the magnetic equator have more (or at least more bunched-up) points within 2 or 3 stellar radii. This could mean that the nominal values of r that I'm calculating are conflating those points, so that the values of rstep are too large and thus each point will be given too much area.

Today I took my first steps in the land of the third dimension. My new file, D3grid.pro, makes every array representable in three dimensions. Right now, it just puts the data from one file into every "slice" of the 3D grid. I can then go in and choose which slice to make a contour of (so far the only contour available is Emission Measure).

At this point I feel fairly comfortable working with my new spherical polar coordinates, but I still have a lot to do with them. I also fear that I'm going to have to consolidate my programs at some point, or break them up into smaller functions, neither of which I'm a big fan of doing. I think tomorrow's main task should be dealing with the occultion of portions of the wind by the star based on the viewing angle.

Today I did a number of things to zeuscontour.pro. First, as per direction yesterday, I added a clevels keyword, which allows the user to choose custom color levels for contour plots. I still can't see why you'd pick something other than what I did, but there it is anyway. In addition, I enabled the contour plotting of emission measure, which also prints out the total emission from the star.

I had to make a few fixes to my area and volume calcuations. I had to divide my area by two due to an error on my part in deriving the equations. I also had to come up with an entirely new equation for volume. I looked at Stephanie's, but found it cumbersome and not tailored to my particular methods, so I instead found one in a caculus textbook and used it with success. I also had some trouble casting floats to doubles, but that got straightened out as well. So all of the volumes and areas that I calculate now agree with what I found just punching in the overall numbers instead of doing the summations. They're a little bit off, but not all of the area is accounted for anyway, so I'm not terribly concerned.

Finally, I added a new threshold keyword, which sets a lower limit on the associated value of Log(T). Any point with a Log(T) value lower than threshold will not be counted in the emission meaure total or given a value on the contour plot. This will make it easier to see where exactly the hard X-rays are coming from.

So the next list of tasks is as follows:

• Rotate the simulation around the z-axis to make a fully 3-D grid
• So far, mine only does this implicitly, not explicitly
• Make a histogram of emission measure vs. temperature
• No idea how to go about this just yet, but give me time...
• Take into account the occultion by the star of the wind with respect to the viewing angle (position of the observer)
• I'll worry about this one when I get the 3-D stuff down pat

I got the grid problem worked out, although it ain't pretty. I had to use some rounding trickery, a bunch of where statements, and some overall cleverness. But it works to my satisfaction in 2 dimensions. I still have to set up the 3-D array and map the data points into it, but that's a task for another day (maybe monday, who knows).

My program now plots all of the things it used to, plus the a contour of the area represented by each data point and a contour of the volume represented by each data point, assuming &phi symmetry. Other than that there isn't a whole lot new to report. Below I'm posting the list of tasks for this week (which, I realize, is now over) and next week along with their current progress.

• Add option of showing locations of data points to contouring routine
• SO done. Just add '/points' when running the program
• Let the user define the viewing grid of the output contours
• Equally done. In fact, my code even recenters the output contour and maintains the aspect ratio so that the star always appears circular
• Make changing the contour levels somewhat user-friendly
• Don't touch the contour levels. Hands off. But seriously, they can be changed, but it's not user-friendly and I wouldn't reccomend it at this point. I'll probably just add it in as a keyword later.
• Enable plotting of density contours
• Done beyond the shadow of a doubt
• Make contour map of emission measure
• Still working on this one, but it's not far off

Sometime late yesterday I realized that there were closed loops of magnetic field intensity in my contour plots. I zoomed in to verify their existence and ran my program on another zone for further verification. After much discussion and many emails, Stan Owocki informed us that they are in fact natural. They would represent closed loops of field similar to those on the surface of the sun in 3D but only appear as loops in our 2D MHD simulations. Luckily, I didn't have to do anything to my code.

Today I also touched up my emission measure per unit volume routine in my newly-renamed zeuscontour.pro file. I also added a filename keyword (hence the more general program name) and documented the program in comments at the beginning of the program in the generic IDL style. The current project is mapping the data points onto a regular polar grid, which is difficult since the radii of each data point are not necessarily the same as the other points that are supposed to be on that radius. In addition, it appears that the change in radius is not constant, but is instead somehow logarithmic, which makes things extra tricky if I'm going to just do this with the data. Hopefully Asif will send us the algorithm for making the grid and I can somehow use that to determine the true locations of data points.

Today I added some serious functionality to my contouring program. First of all, I've added a color bar at the top of each plot. I changed the resizing to just resize the plot instead of just the window since I was having some overlap problems; no loss of zoom or anything, just a lot of whitespace sometimes. My program can now plot not only temperature and magnetic field lines, but also density and velocity.

I then went on to add optional user input, so the user can choose which of the plots to make, with or without magnetic field lines and with or without the locations of the original data points. At the end of the day I started working on the emission measure functions, but so far it's just a scaled verion of the density since I've used a uniform value for the volume per element.

Started the IDL phase of my project. Worked with Marc Gagne's new code a bit, but mostly used Stephanie's technique to produce images. I included in my code a little routine to make sure the aspect ratio of the image window stays constant so that the star itself does not appear distorted. Also, I made a little bit of code to white-out the star in the images, which was actually harder than it sounds. I made a couple of images and put them online as well. I just remembered, I also adjusted Marc's code to exclude anything that gets interpolated beyond the scope of the original data.

Today Marc Gange, Stan Owocki, and Rich Townsend (see my articles page... you might recognize the names) came to visit for the day. We spent the day with their students and of course with David discussing our projects. All day.

Pretty soon I'll be making nice images with my own hands. My interpolation method in testxy.java works marginally well, as can be seen in my images. It took some doing, but everything works, even if it isn't as effective as Origin. Soon I plan to consolidate my java files into one, but I think I might wait until my interpolation is where I want it to be for that.

Today Marc Gagne made his first visit of the summer and we discussed some things. Of particular interest is that to extract data from a .sav file in IDL, one just needs to call restore file.sav and it puts all of the data into the IDL registers.

As far as my interpolation goes, I'm still a long way off. My interpolation looks better now that I knocked the number of pixels per side down to 500, but I'm getting some wierd effects near the stellar surface, and the image still isn't really that good. I did a quick plot of where the data is spatially, and it seems like there are some serious holes. Marc's (and Origin's) interpolation either keeps data that I'm throwing away or somehow interpolates into features that aren't really there when just looking at the data.

I plan to look at my data reading methods in interpolate.java and make my interpolations better by taking the weighted average of the nearest point in each quadrant relative to the point being extrapolated.

Today I completed the first version of the interpolation portion of my imaging. The interpolation just averages surrounding pixels and results in rather pixelated images (and thus bad data). However, the entire process is now in place. I plan to either make my interpolation algoritm better or use an IDL function to perform the interpolations for me. As of yet I am having difficulty finding an IDL program to do this for me, but we'll see.