Exploring IDL and our stars - week ii of summer

A short update on my second week of SURF follows, as does a fuller explanation of what we are trying to do! EDIT: just the update, the theory behind is in the next post. Else this would just get long.

I was looking at the vst structure that contained the information for the radial velocity measurements that I was to look at for Professor Knutson. She got a proposal in, with a good list of stars that had certain traits (more on that in the next post), and she wanted to see whether any new measurements of these had exhibited trends since six months ago. Well, I realized that I had no idea how to work with IDL, so I got diverted into a little bit of programming to try see what I could do with it.

For my database of stars that could be interesting to observe (more on that later, e.g. next post) I wanted to know when would be the best time to observe these stars - i.e. when they were near the zenith during the year. Sasha told me that a good way of finding this would be to see which star is crossing the meridian at midnight (approximately the middle of the night) so we could say, give or take a couple days, when the star could be observed by Keck. Now, the Local Standard Time (LST) is matched exactly to the RA of a star directly overhead, which is very useful for us! All I had to do was find the LST at midnight on any particular date and match it to RA of the star to find my "perfect observing night".

Doing this by hand seemed like a little inefficient, especially if I had to find this LST and match it to more stars in the future. This lead to a little fiddling about in IDL! My program, summerlst, calls a function (LSTM()) that first populates a vector of all the LSTM for a year, without correcting for leap years. (I still kind of have to work on that part). Note that the LST @ midnight (LSTM) is 00:00 hrs at vernal equinox (Sept 21 or therabouts) and advances, as a small approximation, at 4 min a day. I introduced a tiny correction for longitude, and after 365 days, the LST cycled through 24 hrs very nicely and returned to 24:00 or 00:00 hrs. The index of this vector is a count of the number of days after Sept 21.

Then we have to match the LST with the RA of a star! There might be a better way of doing this, but I found the closest match by a difference vector (the absolute value of LST[i]-RA), then found the minimum of that, taking the index of the minimum (which will also be a count of the days after Sept 21) and figuring out which day it lands on (which includes a correction for leap year. Interesting). It outputs a nice, readable date. It would be pretty simple to instead return a Julian Date (JD) or Modified JD (MJD, where we define MJD = JD - 2.44e6 instead of what generally is put on the internet, MJD = JD - 2.4e6; that 40,000 confused me for quite a while :D) which would be more useful to the telescope but less so for knowing which star to send to the telescope, I believe.

The called function takes only a single RA, whereas the procedure is cool in that it takes an ascii file and reads it! Using more stuff from the libraries I have (the standard IDL one, the astronomy library, more :D -- cool ones I've used: ydn2md.pro and readcol.pro; cool ones I want to use: webget.pro, a function that accesses http servers and downads text and FITS files!) I define one input as an ascii file with just a list of RA that you are interested in - the RA of stars you are to observe (again, easily modified to account for a different number of columns, i.e. if the RA data is in the second column, with a star name in the first).

Now comes something I really like about IDL - that in the command line you can stop and continue programs! I printed out the no. of valid columns, i.e. the number of RA it was able to read. This should be the same as the number of stars. Then with an easy stop command, the program stops running so you can check! To continue, all you need is a .continue. SO COOL.

I used a for loop to take the RA data read in and sent it off to my LSTM function, storing the retuned string of the date (Day Month Year) in a vector that is printed out to the command line. Using for loops is slightly discouraged in IDL, as it can be slow if working with giant arrays (at least that is what I've heard). However, there are only 111 transiting planets (which is what we care about) as an upper threshhold, and currently only 42 are of any interest, and that number will be cut down given that many may not be observable this summer, it seemed the best way to go about this. If I have time later to figure out a better way of populating vectors, I will work on that.

Another really cool thing about IDL is optional keywords or inputs - which changes the direction of the program. For instance, I can input either the RA in the more common, more useful (decimal) hours, or I can take it in decimal degrees (using the /DEG keyword when running the program) and,

if keyword_set(DEG) then ra = ra / 15.

Amazing. For instance, I used the readcol procedure to read the ascii file of RA. But, since I call it with the /SILENT keyword, it doesn't print out error messages for the lines that cannot be read (i.e., empty rows or the wrong data type). Instead I just printed out the number of elements in the output vector, and ask the user if it's right (as mentioned above, with the stop command.

I ran this for the 42 stars I picked (I actually picked 40, and Prof. Knutson 20, and we only differed in two so I added those in, to make it a happy answer to life, the universe, and everything), inputed it into my database (again, more explaining next post!) and made a final spreadsheet of stars up in July! We - and when I say we, I mean the California Planet Search (CPS) - have 10 observing nights, and that should be very nice for the 8 stars we can look at!