My GUI is now capable of calling the proper programs to do the post-processing. None of the actual post-processing programs are complete, but the view-only ones should be fairly trivial to implement.

I've decided to just pass around the data structure from the GUI to all subsequent programs. As it stands, the GUI file calls redirect.pro, which checks the parameter and simulation type ("View only" does the old stuff, while "Full 3D sim" will do the new stuff) and passes the data structure to one of 16 possible post-processing programs.

I've decided to just put the metal abundances on the main frame of the GUI for now. Not the greatest solution, but it works and won't cause any problems.

The GUI is for all intents up and running. It doesn't link to a program yet, but that should be fairly trivial. The only problem that I'm having is with adjusting the metallicities in a pop-up window. I might give up on that and just create more text-entry fields in the main window, although I'm not thrilled about that idea. So a few more things have been knocked off of my to-do list, which makes me happy. Yesterday I saved Cartesian grids of density 100, 150, and 200 points per 9 stellar radii. My GUI reflects this adjustability as well. As far as the to-do list goes, I'm considering the GUI complete.

I'm making great progress on my GUI so far. Right now it doesn't run my program, but I think I have the structure set up to start gathering user info. At first, the user will have to set everything every time (if the options deviate from the defaults, that is), but eventually I want to work in state-saving, wherein a user can save the status of all of the settings and reload them later for a quick restart of the program.

There's a screenshot of my GUI on my images page. I realize that it's bland and not especially well-organized in terms of layout (although I think the overall grouping makes some sense), but it should get the job done.

I did a fair amount to get organized today. First of all, I updated my to-do list for the first time in months. I've deleted some items that will be automatically taken care of by my new additions. Also, I posted my new programs to the code page for the first time. Finally, I created for myself a rough outline of what I think the GUI should look like, or at least what it should consist of. I'm going to need to take a long look at IDL widgets in order to get this working, but I think in the end it will be more than worth it; running my programs will be easier not just for me, but it should even be intuitive for David or anyone else to run after I leave Swarthmore.

I've completed a basic implementation of my first-order interpolation routine. This is just a nearest-neighbor interpolation onto my new 3D logarithmic cartesian grid. A side-by-side of the interpolated image and the actual image can be found on my images page.

Today I made my grid span all 8 quadrants. Surprisingly, this did not result in a major slowdown of grid creation. An image of the central slice is posted on the images page.

On the down side, I can't seem to find an interpolation routine that will go from an irregular grid to any kind of other grid. Everything wants the input grid to be monotonically increasing. This means that I'm probably going to have to dig something out of Numerical Recipes and create my own interpolation program... ugh.

After considering the issues apparent with not only creating contour plots but also with calculating absorption in my current spherical grid, David and I have decided that we need some sort of cartesian/cylindrical grid. So the plan right now is to create a cartesian grid (which I think will be easier to create than a spherical one), and interpolate the data onto it after I perform any tilting/rotating of the original grid.

This will afford many advantages: first of all, I can always simply plot where x=0. Secondly, calculating absorption should be relatively trivial (if not necessarily easy). Also, I can plot any slice as long as it is parallel to one of the axes (x, y, or z).

Currently, I have most of the grid working. The grid has data points that decrease in spatial proximity logarithmically (see the images page for more on this). The grid right now is only in the first quadrant, but extends in all three dimensions. In addition, I've added the volume calculations to the grid and appear to be working perfectly. I toyed around with deleting elements in the grid arrays that lie inside the star, but doing so was such a slowdown that it just doesn't seem worth it.

I've begun restructuring my program from one do-all to a more modular setup. The main program is postproc.pro, while subprograms will be called pp_*.pro, where the * represents a plotting parameter. This has already effected a 40% speedup in plotting the temperature contours, which are the only ones that I've implemented so far.

I found a really cheap hack to solve my problem of infinite loops in the drawing of equatorial magnetic field lines. I figured that I could just test to see if the vectors were pointing to themselves (zero vectors), but that didn't seem to work. So instead, I'm just going to put a limitation on the number of times that the while-loop that draws the contours can repeat itself. While this works, I still have to determine a value that will allow all contours to be drawn, yet isn't so huge that it's effectively infinite. So far I've just put this into d3t1oc.pro; hopefully I'll come up with a better solution soon.

Today I started getting all of the presentation stuff I have to do out of the way. I created a first draft of the paper that I have to submit to the provost and sent it to David for approval. I then began work on my poster for next week's poster session.

First thing I did was update my to-do list. There were a couple of things from our trip to Delaware that never got added. I then tried to knock one or two things off the list. First, I tried to create line profiles with linear axes, although it doesn't appear that IDL can handle axes that span such great ranges. Next, I created a startat keyword in d3bcep.pro and d3t1oc.pro which will allow the user to skip straight to a timestep in which they are interested. Coupled with nsteps, the entire range of timesteps processed can now be constrained.

It's been a while, but I'm back. Came in today to do some editing of my howto manual and to talk to David about the poster session and that 2-page thing I have to write for somebody, and maybe to meet Asif, although they're not around at the moment.