So getsteps.pro appears to be working. I think maybe I just forgot to compile it last time I ran it on friday. Or, I could just be getting lucky with the random number generator. Hopefully the former is the case.

I finally got to test my thermal broadening. There are two sample images with and without thermal broadening. The line center is positive without but negative with, which concerns me. David also pointed out that the y-axis range changes quite dramatically, which makes me think that I'm taking into account the volume elements in one case but not the other, which could possibly throw the line center, but maybe not.

I worked some more on my user manual, including making some Word art to visualize the inclination and obliquity.

I also made a lot of improvements to imagecombine.sh. Mainly, I made it so that it asks for user input instead of the user having to change things in the file itself. I guess if I really wanted to I could make the file read-only, but what fun is that? I also knocked the final image size down from 1200x1200 pixels to 800x800 pixels so that it actually all fits on the screen. I wrote up a very detailed description of how to use the program in my user manual. I've posted the latest version of the manual on my IDL page.

Today I'm going to go through and basically try to touch up my program so that it's as polished as possible. First, I made it so that if a simulation file already exists, the program will use that and not create a new one. This should save tons of time. Granted, the user has to delete the old file before creating a new one, but I think it's a good solution. I then fixed the line profile plotting for the 3D sims. I then made all of the programs stop calling xloadct, which brings up the color table window, since it doesn't really do anything.

I fixed a bug in the GUI that didn't handle switching between the EM and VLOS parameters properly. I fixed a bug in the light curves: if there's no inclination or obliquity, then the total emission measure can't change, which wreaked havoc on my light curve axes. That problem's been fixed.

I also worked on my manual a little bit (although not significantly enough to put it up on the website yet) and tried to fix getsteps.pro so that it won't repeat timesteps. For some reason, it's not working the way it should yet...

I created a ton of light curves, which are on my images page. I think we've got it pretty well settled that everything's working properly, especially for H_α. All of the plots look good.

In addition, I did some major work on my user manual, which is linked from my IDL page.

So I've put up some images that suggest some interesting things. First of all, I put up the corresponding log plot to the linear one that I made yesterday. As usual, they look pretty much Identical. Then, I made 2 100-slice simulations of one zone, like I did before with zone 75. This time I picked zones 52 and 65. The light curves are on the images page. The light curves look completely different, almost opposite, while the color contours look very similar. But, I ran some quick numbers, and it turns out that in zone 65, which looks like zone 75, only 41% of the total emission (which is a little low since I counted X-ray emission for that value) is originally occulted in the beginning of the simulation. for zone 52, over 71% of the total emission is originally occulted. So, clearly what's happening is that the shapes of these light curves are very dependent upon the original geometry of the timestep that I'm using.

That being said, and recalling the wild variability that I was seeing in the light curves that had random slices, I don't think that the θ¹ Ori C simulation has enough timesteps to create a 3D simulation with consistent light curves. First of all, as shown by the light curves from July 7, 2005, I can't use any of the first 20 timesteps (1 step=5 ks) because the simulation was still settling down. That only leaves me with 63 timesteps to use.

I've put up two light curves from randomly-generated simulations. They just don't look anything like each other. I really wouldn't be surprised if the H_α with a lot more independent timesteps was fairly constant. It's hard to say, though.

Last night, David sent me 2 rather lengthy emails. Today I'll try to address his thoughts.

First of all, he suggested that I make sure that each hemisphere has the same volume, as a test of the volume calculations. Below are my results:

So I'm not sure what I did, but I managed to screw up my light curves. Nothing looks good, or even close to good really, and the linear plots are inconsistent with the log plots. So that's very bad. It turns out that I was messing with the volume array on every iteration. The volume calculation only happens once to save computation, a fact that I was not taking into account.

After keeping the randomization consistent (same selection of azimuathal slices for every run), the plots should look pretty consistent. I've put up one such image. That disturubing hump at φ=0.5 has returned...

I made another plot, and it was just completely backwards. I really can't tell if there's something wrong or if randomness is killing me.

I found a couple of things out today. First of all, my programs aren't using thresh.pro properly. Also, only the EM and VLOS programs are using it at all, which I'm not so sure about. I think I'm going to change that. Also, I found a routine called resolve_routine, which is basically a way to tell IDL to compile a program at runtime. Using this, I finally got all of my programs out of postproc.pro and into their own files. This should make working around in them a lot easier.

I'm now going through and modularizing my code so that it will be easier to read in the future. On the downside, this will result in a whole bunch of program files, but I guess I can't have my cake and eat it too. Although cake would be nice... anyway, so far I've modularized out the volume determination (volume.pro) and the output window setup (windowsetup.pro).

I discovered that I'm not using any of my threshold keywords in the view*.pro programs, so I'm going to put that on my to-do list.

At David's suggestion, I've changed my EM thresholding to be EM/Volume. I've put up some images on the H-alpha page that I created yesterday. While the comparisons between pairs of images aren't direct, it is interesting that switching to EM/Volume doesn't appear to shift many of the data points further away from the star down to 5 or so orders of magnitude. So I don't see any reason not to leave the code this way.

I finished touching up the GUI. All of the dependencies seem to be working properly.

I've implemented the emission measure data cutoff in sim_em.pro. It appears to be working properly. I wasn't sure whether to cut off based on EM or EM per unit volume, but that's a fairly trivial detail that will be worked out soon. In the meantime, I'm doing the cutoff based on EM. I played around with what cutoff would make for good movies, and I discovered that the majority of the H-alpha emission in coming from R=1 (or thereabouts). I made a page of images that I've linked from my images page that shows how the plots appear with varying EM cutoffs. All of the plots show H-alpha only.

This could go a long way to explaining the 30% drop in H-alpha emission in the light curve. As a matter of fact, the maximum radius for a point that was plotted in the righmost picture on that H-alpha images page is 1.62, and roughly 100 of the 600 points plotted have R=1. Many more have R<1.01.

My concern now is: since the points at R=1 are on the edge of the simulation, how much can we trust what they're saying?

I fixed the line-of-sight velocity histograms. I put the thermal broadening function in a new file so that it will compile properly at runtime. I finally learned how to create functions in a new file as well. There's an image up showing the results. Not sure how I feel about this just yet.

As it turns out, my code could already do linear EM vs phase plots. I've put one up on my images page.

I've restructured the GUI, which includes removing the tilty parameter. From now on, obliquity will serve its function for "view only" runs. Also, the occult keyword has been removed. It will either be used implicitly when needed (i.e. line profiles) or simply not used (i.e. 2D contours). I've also added a "Close" button at the bottom. Finally, I made sure that all of the appropriate parameters link up properly (i.e. the user shouldn't have a choice of histogram y-axis style if the image type is set to "Contour"). Almost everything seems to be linked up properly; it still messes up when loading settings, though.

Unfortunately, while doing all of this, I somehow rebroke the line profiles, so they need fixing again.

I've added a printout of the temperature range on all 3D "contour" plots (they aren't really contour plots, but take the place of them from the 2D output). Probably useful. I also created an emission measure vs phase plot, where I used 100 divisions all of the same timestep to test the H_α curve from yesterday. It has a few interesting features that I may or may not be able to explain.

Then, my line-of-sight velocity 3D plots broke (or never worked; v_los is the bane of my existence). I'm doing the coordinate transformations the same way as for everything else, but it still isn't right, which I just don't understand.

David came by and we talked about some stuff, including things for me to do in the future. Also, he suggested posting my rotation methods to see what I'm actually doing. David then printed out the "correct" (i.e. right-handed) way to do this. It turns out that my coordinate transformations are right-handed, at least for the positions. But my v_los is still doing crazy stuff...

One of my most productive days of the summer. I got the rotation error worked out, as described on my IDL page. It really wasn't very much more than I was doing already.

Naturally, then, I made a few movies. I fixed the point-plotting algorithm so that it uses the same color tables as the 2D contour plots, and they look much nicer. They'll also maintain colors no matter what the temperature threshold is. Speaking of which, the temperature threshold is now the method of selecting which points to plot in the 3D images. It works really well if the coolest points are omitted.

I implemented the new method in all but sim_vlos.pro, which is in progress. Something's still a little off, though, since I'm not always seeing the full range of colors that I expect.

I went through my thermal broadening again. It looks really smooth, which seems alright. Still, I'm not sure if I have the rotation down yet, so this might be completely wrong. I don't have an image of it, since I broke sim_vlos.pro at the end of the day. Sigh...

I also remade my emission measure vs phase plots. (Again, images on my images page). They look a lot better, without that little hump in the middle that was indicative of incorrect rotation.

So yesterday, David and I got really confused about what some of my movies were actually showing in relation to the EM vs. time histogram. We decided then that my rotation was wrong. However, I thought about it and made some movies where I just plot the points where log(t)>7, looking down the z-axis (as the observer would). After looking at this new movie and talking with Marc, I've realized that I haven't been doing anything like what I should be doing in terms of rotation, and that it's going to be more complicated than I thought. More to come on monday.

I read the Feldmeier et al paper. The requisites stuffs are on my articles page.

I also worked on determining if my thermal broadening matters at all. I couldn't get any of my linear plots to look different with thermal broadening, so I made up a quick little test. I made one grid zone, with a certain line-of-sight velocity, temperature, and emission measure value, then created a histogram using thermal broadening. Clearly, the broadening is having an effect on the line. I then made another image with a second point, where the two points had different values of all of the above parameters. The line-of-sight velocities were close enough that their curves should combine, and they did.

I began implementing my correction for thermal broadening of line profiles. While I feel like I'm close, the total emission measure is still off. The new value is low by about 20%. The loss seems to be coming close to v_los = 0, which clearly rules out the tails of distributions getting cut off by the edges of the plot. I could accept a couple percent difference there, but not 20%.

UPDATE: I've fixed the thermal broadening. I had to correct for when the z-values of the bin edges had opposite signs. I've put a write-up of my methods on my IDL.

I've decided to continue plotting 2 different plots on one image for the line profiles. However, instead of doing occulted/non-occulted, I'm doing all material/material that falls within the temperature threshold range. The latter is plotted only if is set (if is set, then by neccessity must also be set).

Also, I think I've found the solution to the axis problem for line profiles. For logarithmic y-axes, I've just set the range to [50,62]. I haven't seen any problems yet. There's an image of this on my images page.

For linear y-axes, it gets a little trickier, since the threshold-limited data is a few orders of magnitude lower than the non-limited data. So I'm only plotting one curve if the y-axis is linear. This will employ the temperature threshold veriables if they are set. To determine the y-axis range, I determine the maximum bin value of the first image and round that up to the nearest order of magnitude for the upper limit. The lower limit is always zero.

I've made a movie of the phase variability of the line profile. You can kind of see material moving to and from higher velocities, but overall I think it looks pretty constant.

I implemented line-of-sight velocity contouring and histogramming today, which took a lot longer than it should have. The vlos contours appear to keep the proper colors throughout rotation; this was the first real test of maintaining values that depend on rotation as the simulation rotates. In addition, I've decided that for histograms, information such as inclination and obliquity should go in the subtitle so as not to clutter the plot. This is actually difficult to implement because I have to resize the plot in relation to the window in order to make sure that the subtitle fits.

I tried making a couple of movies of the line-of-sight velocity histograms, but they just don't quite work. I need to find a good set of fixed axis ranges to use for the line profiles so that they have some consistency to them.

I made sim_d.pro, sim_v.pro, and sim_em.pro today. Everything is working, including the emisssion measure histogram (light curve) and emission measure vs time histogram, of which there's an example on my images page.

I went through and touched up a lot of the programs. I got rid of the rotational period variable, since it's pretty pointless. I fixed up sim_t.pro so that it can actually handle the rotational simulations (i.e. βcep), which I think worked fine all along, but it took me a while to remember what I was doing.

I've also started (and made a whole bunch of progress on) the first draft of my user manual. It's posted at the top of my IDL page.

The computers were down, so I worked a bit on my presentation for CS pizza wednesday in 2 weeks. Once they came back up, I transitioned all of my programs to the new version of starwhite (v2.0). Line-of-sight velocity plots no longer have a black-outlined white circle, but now just have a black circle. It's a lot easier and doesn't make a whole lot of difference.

The first thing I did was to put a black dot on the front and back sides of the star in the movies so that the viewer can more easily discern the direction of rotation. I've put up a movie showing this new effect.

I spent some time fooling around with ways to display various axes on the images. I have yet to come up with a tractable idea.

I then spent the rest of the day working on my user manual. I'm learning LaTeX in the process, so it's kind of slow going, but I still made a lot of progress today.

I implemented the 3D starwhite program in sim_t.pro today. I had some issues with passing arguments to the program (still not sure what that was all about), but hacked around it eventually. I then installed mpeg2encode in my home directory (I put a symbolic link to the executable file /home/sstvinc2/mpeg2/src/mpeg2encode/mpeg2encode in /home/sstvinc2/bin). I've successfully made a movie of θ¹ Ori C and put it up on my movies page. I think it looks pretty sweet.