So I finally have my 3D graphics working. It looks pretty sweet. I have yet to implement it in my actual programs, but I have a test program and it works. I've put up a movie that shows the new effect, as well as a description of my methods.

It turns out that my rotation was correct all along. The problem was what it was that I was trying to plot. I was trying to stay face-on to the slice after the spin (but before the tilt). But when I don't bother and just always look down the y-axis, everything looks alright. I think that this method is actually better. In this way, it will show the rotation of one slice through the rotation of the star. Nothing is to be gained physically, but it could be an interesting animation if nothing else.

I've put up an animation of slice 0 rotating through one phase, where obliquity (β) is 42 degrees and inclination (i) is 45 degrees. It does exactly what I expected it to, which is further proof that the rotations actually work.

I'm now trying to work it out so that the star whitens in such a way that material in front of the star visually occults the star. Tricky so far, but progress is being made...

I used equation 2 from the Gagne et al (2005) paper to map phase to viewing angle. I then figured out two different ways to implement this (see the IDL page). While testing this, I realized that my code for tilting about the y-axis is flawed (see the images page). So that needs to be fixed before I can move on with this.

While waiting for David to talk about the rotational flaw, I fixed up my GUI, including removing unnecessary parameters and lining things up so that they're pretty. A screenshot is on my images page. I also went through all of my view_*.pro programs and took out now-defunct parameters from them. At some point, I need to do thorough testing again on all of them and clean up the code a bit.

Looking at transformation matrices, I may have my rotations completely wrong, but in such a way that they still almost work. More on this tomorrow...

David sent me a lengthy email with a few things to change. I've put some stuff on my to-do list. I've edited a couple of the article summaries as well.

The network went down, so I couldn't update everything right away. If I remember correctly, I ran a few tests on the 3d simulation to make sure everything was happening the way I expect it to. I then started making notes for a users' manual, which is going to be pretty lengthy, actually.

Now that the World Cup has calmed down a bit, I can reshift my focus to this project again. So the first thing to do (among the many new items on my to-do list) was to set up the capability for putting random slices into the quasi-3D grid. It was tricky, but I managed to get it done. I've put up an image showing the (desired) asymmetry in the image.

So the massive interpolation that I ran last night didn't do significantly better. As such, I'm going to have to do a thorough re-evaluation of the entire process sometime soon.

David, Marc Gagne and I spent a goodly long time today discussing the whole interpolation project, and basically decided to back burner the entire thing. Not only are there computational difficulties, but there may be physicality difficulties. So, instead, we're going to focus on H-alpha emission (T<10^5 K), partly by finally implementing the quasi-3D model. Also, I need to broaden the widths of line-of-sight velocities at each point such that they are no longer delta functions.

I got what should be a pretty decent interpolation routine going, whereby I do a weighted average of the nearest n (usually 4) points. It runs properly, but whenever I create emission measure statistics, the total emission measure that I get after interpolation is about 1000 times what it is without interpolating (i.e. my old code). This is significant, especially considering that EM is proportional to volume, and the overall volume in the interpolation grid is actually less that that of the original grid. Increasing the number of grid points does seem to bring the overall EM down significantly, but not yet even by an order of magnitude. I'm going to create a huge grid today and let it run overnight and see what it looks like.

I did some more work on my interpolation routine. I finally got the grid the way I want it and implemented a first-order interpolation in sim_t.pro. I'm still working on putting it in sim_em.pro so that I can do some diagnostics on the interpolation and grid size. I've put up some images and some benchmarks on my images and IDL pages, respectively.

I also set up a website for the other project that David's going ot have me work on.

This morning, I managed to work out the volume calculation for the new grid points. I've put a little description of the results on my code page, but basically I've gotten the volume to be correct to within 0.1%, which should be good enough considering we're already working with a sparely-populated simulation grid that's going to be interpolated onto another sparesly-populated grid.

I spent most of the rest of the day trying to integrate the new grid into the postproc program for interpolation by the full 3D simulation subroutine. This has proven difficult considering the unusually large number of bugs in my grid creation program. I fixed the top-down view of the new grid on my images page. One tjing that I was doing wrong was that I wasn't converting my &theta to radians before converting cylindrical coordinates to cartesian for the plotting routine. Other than that, I'm kind of stumped at this point.

I managed to apply the keyword to the emission measure histograms in literally 5 minutes. My code could already handle it pretty well, and it didn't involve changing the x-axis at all (unlike the line profiles). I did have a bug in my emission measure histograms that basically set all of the 3rd quadrant to being occulted by the star, which was drastically throwing my histograms off, but that's fixed too.

I then began working on my "ray-shooting" data interpolation grid. I have a couple images of this up on my images page. Basically, I'm going to try to create a grid that's very dense where there's likely to be important data, yet sparse enough elsewhere so that computational limits don't crush my hopes and dreams. The preliminary volume calculations look decent, but not quite exact. I'm still overshooting the volume calculation somehow, but I'm not sure where. It's probably at the boundaries between the grid point density zones, but we'll see.

The first thing I did was finish up implementing the switch in the GUI for the line-of-sight velocity histograms (line profiles). I then spent a good bit of time commenting my code while I still remember why I did everything the way that I did. Both very tedious and painful processes, but worth it. I then put in code to ensure that an appropriate color table will be loaded whenever a histogram routine is run. Before, the histograms would just use the last color table that had been used; now, I load color table 39 (Rainbow + White, the default for EM contours) to make sure that everything looks right.

David and I also discussed possible ideas for interpolation routines. I'm going to start trying to implement the cylindrical and highly varying (but fixed) grid tomorrow.

Eric and I spent a good chunk of the morning trying to figure out why my images wouldn't display or save in color in Linux, which they would in Windows and Mac OS X. It turns out that the default color settings leave a lot to be desired, so two lines have to be added to any program:
device, true_color=24
device, retain=2
The former allows IDL to display color straight off by setting the visual class to TrueColor (4), while the second makes sure that whenever the window is covered by another window, it will retain its information and redraw appropriately when necessary. Have I ever mentioned that IDL sucks?

David and Asif each took a turn running my program, which went very well. They did find one bug, but I've fixed that now. I added a keyword for the user to enter the stellar radius in terms of solar radii. I've also added a 'Last good settings' button in the GUI so that the user doesn't have to go to the menu to restore the set of last good settings. Promoting laziness? Yes. Worth it? Of course.

Next, I added a flag to switch plotting in the line-of-sight velocity histograms (line profiles) between a linear and logarithmic y-axis. I'm still working out the kinks in the implementation, but it's well on it's way. In the linear plot, I'm recreating the histogram over the interval over which the overall distribution stays above 1% of the maximum value. That is, I create an initial histogram over the entire range of line-of-sight velocities. Then, I find the line-of-sight velocities on either end at which the binned emission measure drops below 1% of the maximum bin. I then recreate a histogram between those two values. This greatly increases the resolution (usually a factor of about 25 or 30) of the linear plot.

Of course, I found some bugs first thing this morning. The line-of-sight velocity histograms weren't, shall we say, "working." So I fixed that, and knocked some precision points off of the data values presented in that plot so that it looks a little cleaner.

Then I started working on the interpolation for the full-3D sims. This sucked. IDL doesn't have a good, predefined routine for interpolating between irregular grids. Right now, it's looking like it's going to be a really slow process, prohibitively so. So I talked to David, Eric, and even some CS profs to try to come up with a viable solution, but in the end, the lack of determitability of the polar grid was the limiting factor. I just never know what it's orientation is going to be, meaning that looping over every point in the new grid is a necessity. I made a couple of images with a nearest-neighbor interpolation, which works pretty well actually. They're up on my images page.

So I'm finally done with the viewing part of the program. I finished implementing the emission measure vs. time histogram. I've decided to give the files names that are as unique as possible; as such, they incorporate the data file name and the timesteps over which the histogram is created. I guess calling this a histogram is not only misleading but generally wrong. It's more like a plot of the totals for each time step, but whatever. Things appear to be happy.

One other little bit of robustness that I added was to not let the user try to run a simulation for more timesteps than are in the data file. So, in checkheader.pro, I've added a counter while it determines the maxima and minima of parameters. The end value of this counter is then added as the last item in the header, which can then be checked by the GUI, which I've finally renamed to postproc.pro.

Task number 1 for the day was to implement some rudimentary exception handling. This way, when the user gives a bad filename or file specs (i.e. header, subheader, or rotation), the program won't just crash, but will give at least moderately useful feedback.

The motivation for this was the addition of checkheader.pro. This program basically has one purpose, and that is to make sure that the data files being used all have a line in the header (the first line) that will give useful information for the rest of the post-processing. This information is the maxima and minima of different parameters, so that each image in the time series will have the same colors for each value in the contour plot, and to constrain the axes of the histograms. These constraints have now been implemented successfully.

The next little thing that I added is an 'ALL' option for the parameter, well, parameter. The only tricky part was getting each parameter to load its default color table and gamma value, but that's done too. So, barring any future bugs (which are sure to arise) and with the exception of the emission measure vs. time histogram, everything seems to be the way that I want it.

One last note: Eric informed me of something else in IDL that sucks. Check it out on my page devoted to the suckiness of IDL!

The GUI can now make the emission measure and line-of-sight velocity histograms. Two things still need to happen: I want to make the histograms adjust with the data, which they really don't do well right now; and I need to implement the emission measure vs. time histogram, which shouldn't be too difficult. I'm pretty sure that adjusting the plot dimensions to the data is working, but I need to test it more thoroughly to make sure.

I got a couple of things done today. First, I finished the postproc routine (for use with the GUI) for density, emission measure, velocity, and line-of-sight velocity. The histograms still aren't working, but I should be able to get that soon.

The other thing I started today was working on a shell script to make the grid images for my movies (and maybe the movies themselves eventually). This is also customizable, so I can make a grid with any 4 images in any order I choose. I'm using ImageMagick to montage the images together in a moderately convoluted manner, but it works very well, so I'm pleased with the process. It's kind of slow since it has to convert the images to .png before manipulation, but the final product is good and I think that overall, this is a better solution than creating the grids with my postproc routine.

This is the first day of work for the summer! I did a little bit of house-cleaning on the website, but not much. I read another paper (Wade et al), which talks about determining the magnetic field properties of &theta ¹ Ori C using line variations in the visible and UV. As always, the paper is now up on the website. This has led me to realize that my program should have fully adjustable ranges on the temperatures for the one-level contour (previously called "tgt6," or "temperature greater-than 10^6 K") and for the emission measure restrictor variable (formerly called "emthresh," or "emission measure threshold"). I now have an emission measure range instead.

The GUI, as far as I can tell, is completed, save for the inevitable bug fixes and tweaks down the road. I've put a screenshot up on my images page for viewing pleasure. Still ain't pretty, but it does what it needs to do.

So at this point, I actually have the temperature contouring routine fully operational, which is a lot farther along than I thought I'd be. I'm also paring it down so that it doesn't do a 3D polar grid anymore, since this is really just for viewing the output of the simulation now. From here, it should be pretty much trivial (although still time-consuming) to get the rest of the original routines running on the GUI.