Random data concerning Guide
Modifying Guide's constellation lines: Dario Anderle asked if it would be possible to modify the constellation "stick figures" shown in Guide, controlled under the Overlays menu. You can now click here to get tools for modifying constellation lines (about 47 KBytes). UnZIP it in your Guide folder.
If you edit the file constlin.txt in any text editor, you'll see a brief description of how the file works. Essentially, it says "connect this star to this star, then this star, then this star... Now move to this star and start a new series of lines." Each star is identified by a Greek-letter (Bayer) name or Flamsteed number. (Except for a few faint ones, identified by Yale number.)
Once you have the file the way you want it, you'll need to copy the file compbsc4.dat from the bsc folder of the first Guide disk. Then run constlin.exe. It will read through constlin.txt and produce an updated set of constellation lines in a form that Guide will use. The next time you run Guide, you'll see your changes.
Source code, constlin.cpp, is also supplied (though I find it unlikely that anyone will really want to play with it). Be aware that it's not very clean at this point! When I wrote it, I didn't expect to have any reason to revise it, or even run it more than once.
Some command-line arguments that can be used with Guide: It's possible to set up Guide so that it always loads a particular mark file at startup time, or sets a particular date/time, or centers on a particular point. Here's how to do it:
If you right-click on the shortcut (icon) to Guide, then on "Properties", you will see assorted data about the folders used by Guide and so on. One of these will say "Target:" and will specify a path such as "c:\guide8\guide8.exe".
If you changed that to read (for example)
c:\guide8\guide8.exe -t25/2/1965 12:00
and clicked OK, then whenever you started Guide in the future, it would begin with a date/time of 25 February 1965, noon (UT). (You could use any of the formats known to the 'enter time' command.) Some similar command-line options:
c:\guide8\guide8.exe -mmydefaul.mar
would cause Guide to load up the mark file 'mydefaul' at startup time.
c:\guide8\guide8.exe -om81 c:\guide8\guide8.exe -oJupiter c:\guide8\guide8.exe -oAntares c:\guide8\guide8.exe -o031415.9,-265358
would cause Guide to start up centered on M-81, or Jupiter, or Antares, or at RA=03h14m15.9s, dec -26° 53' 58". (Any object that works with the "Go To... Object Name" option should also work with this -o switch.)
These options can be combined; for example,
c:\guide8\guide8.exe -mmydefaul.mar -t19:00 -oMars
would cause Guide to load up the mark file 'mydefaul', reset Guide's time to 19:00 UT, and then center on Mars.
(The order is significant here: if, for example, you centered on Mars first, then set the time to 19:00, then you would find Guide centered on wherever Mars is right now, rather than where it would be at 19:00.)Also, if you look at the toolbar.dat file in your Guide folder, you'll see a long list of "action codes". For example, action code 2148 tells Guide to show an inverted chart (flipped both north/south and east/west). You can access most of these codes via the '-a' switch; for example, guide8 -a2148 would cause Guide to start up with an inverted chart.
Note that the order of command line arguments is significant: they are processed left to right. For example,
c:\guide8\guide8.exe -a2148 -oMars -t19:00 -mmydefaul.mar
would cause Guide to invert the chart; center on the position of Mars "right now"; reset the time to 19:00; then load up 'mydefaul.mar', which might very well have a completely different time, reset the chart inversion, and center you someplace other than Mars.
If you're one of the remaining DOS command-line holdouts: you can also do commands from the DOS prompt such as
c: cd \guide8 guide8 -oAntares
A new way to do last-minute astrometry in Guide: I've worked out a way to get much more accurate asteroid occultation predictions in Guide. For those unfamiliar with how Guide has done such predictions in the past, a summary is in order. Those familiar with Guide's LMA can click here to skip what you probably already know.
Since early 1998, Guide has had a simple last-minute astrometric capability. Sufficiently bold people could measure the position of an asteroid against the ACT catalog (necessary to get the level of accuracy required) and feed that into Guide. Guide would analyze the positions and apply an offset to the asteroid position, so that you could generate asteroid occultation charts.
This hasn't led to swarms of people generating LMA-based charts. In fact, I think I've been the only one using this feature, and I can't say I've used it very often recently. Few people have access to ACT based positions, or CCD cameras with a field of view wide enough to collect such data. (As far as I know, only Gordon Garradd has been able to do so, and he has to go through some hoops to get four or five ACT stars in his field of view.) The method of persuading Guide to use the data was somewhat awkward. But a key problem had to do with Guide's primitive way of computing the offset.
Ideally, Guide ought to take the data and compute a new orbit from the observations. This would let it use new and old observations, and probably make accurate predictions well in advance of the actual event. Instead, it used a simplified method of computing 'observed minus computed' positions, or O-C positions. It then would do the equivalent of reasoning: "The asteroid is averaging about .43 arcseconds ahead of prediction, and .28 arcseconds under the predicted path. Base the occultation path on the assumption that this offset will continue."
The problem is that the offset does not tend to be constant. For the above method to work, you have to have data close in to the actual event (ideally, astrometry taken a week or two beforehand.) You may have lots of data taken months ago, but none of it could be used.
The new method does LMA "the right way". It takes the astrometry and runs it through Find_Orb to get an exact orbital determination. Find_Orb produces osculating elements, so you have to reset its epoch to coincide (roughly) with the time of the occultation.
You can then click "Save Elements" to store them to a file on disk. Then switch to Guide, click on "Extras... Add MPC Elements", and select the file you just saved. Set the date and time to somewhere near that of the occultation. Go to the star (or asteroid), and right-click on both objects (so Guide will know which object is occulting which object.)
Click on "Show Eclipse/Occultation", and you should get a properly corrected prediction.
There are a few points that need to be kept in mind in all of this:
(Actually, it can be interesting to see what happens if you shut off a perturbing object. Sometimes, the change is not very great; as you might expect, Mercury, for example, doesn't affect an orbit very strongly. But I usually just turn 'em all on and let Find_Orb sort 'em out.)
An example: I received some FASST data for an occultation involving (645) Agrippina from Sam Herchak, who received the data from Ron Stone. Using that data, Find_Orb got the following orbit...
Orbital elements: (645) Agrippina Perihelion 1999 Nov 25.663868 TT Epoch 1999 Dec 19.5 TT = JDT 2451532.0 M 4.10121 (2000.0) P Q n 0.17205843 Peri. 81.53811 0.13377533 -0.99101029 a 3.2014895 Node 0.77993 0.85428301 0.11446643 e 0.1578355 Incl. 7.02882 0.50229941 0.06925351 P 5.73 H 9.9 G 0.15 q 2.6961807 From 34 observations 1998 Aug. 2-1999 Dec. 12; RMS error 0.124 arcseconds
(Note the unusually low RMS error!) I loaded the above orbit into Guide, right-clicked on (645), right-clicked on HIP 27791, and clicked on 'Extras... Show Eclipse'. That resulted in this path. Times are:
Monterrey 11:53:04 UT Chihuahua 11:53:32 Tucson 11:54:03 Gila Bend 11:54:14 Fresno 11:54:59 San Francisco 11:55:17
Steve Preston has done considerable work with this, comparing the results to those from OCCULT (the program used to compute most asteroid occultation predictions). The results agree quite well, to within a few kilometers. We've invested some effort into puzzling out the discrepancy, with no success thus far. (The difference is much less than the errors in our predictions, so we can't just compare our results to reality to puzzle out which prediction is correct.)
Extending Guide's city name database: At present, Guide uses a worldwide city database listing about 4000 places. But recently, Maik Gottschalk, a Guide user in Germany, sent me a dataset of about two million cities. This data currently is consuming about 50 MBytes on my hard drive, split up by country. I wrote a little piece of code to convert it into the format used by Guide. You can click here to download the new data for Australia (about 88 KBytes), or here for the new data for Canada (about 57 KBytes). (Be warned that you can do one or the other, but not both.) UnZIP one of these in your Guide directory and enter eclipse/occultation mode, and when you zoom in on the country in quesion, you will see many more cities.
Special note to persons running Guide in French: you should rename egeo_err.dat to fgeo_err.dat.
By hitting '+' and '-', you can change the level of detail shown, all the way from "major world cities only" to "show small towns". Be warned that in both cases, the last leap is a big one, from perhaps a hundred intermediate-sized cities to thousands of tiny ones.
Be aware that Guide 8 users can show an extremely detailed dataset of cities/towns. Click here for details.
Format of the city databases: City names are stored in two files: GEONAMES.DAT, the 'main' worldwide list of cities, and in the 'errata file' EGEO_ERR.DAT. In theory, the latter just contains lists of corrections (spelling errors, etc.) In practice, I've also used it for things such as the Australian city name extension provided above.
Both files have identical formats. Here's a few example lines:
+47s03'4-122*53' 413 Olympia +42*19'3-122*52' 413 Medford +53*55'3-122*49' 406 Prince George +58*48'2-122*44' 406 Fort Nelson +45*32'2-122*40' 413 Portland
Each line gives a latitude (degrees and minutes); a 'level of importance' (LOI) code; a longitude (again degrees and minutes, with West longitudes being negative); a 'country code'; and finally, the city name.
PLEASE NOTE that the cities are in order of increasing longitude. It's important to maintain that order. If you don't, some cities may not be displayed when you zoom in on charts.
The 'level of importance' codes are relative values. In the above text, Portland and Fort Nelson are given LOI codes of 2, indicating they are 'more important' than Prince George and Medford, which in turn are more important than Olympia. If text gets crowded, therefore, Guide will show the 'more important' places and omit the 'less important' places.
If the LOI code is not assigned (which happens rather frequently), that city is assumed to be of minimal importance (LOI code = 9.)
In the above five cases, all except Olympia have an asterisk (*) in column 4. Olympia has an 's', indicating that it is a state/local capital. Some places have an 'n', indicating a national capital. No use is made of this yet, but eventually, Guide will probably show a special symbol for such places.
The country codes are listed in the file COUNTRY.NAM. In the above examples, 406 = Canada, 413 = the United States.
Translating (parts of) Guide's city name database: As is described above, Guide's basic place name data comes from GEONAMES.DAT. And when you run Guide in English, corrections come from the 'errata file' EGEO_ERR.DAT.
Should you run in German, however, Guide would instead look for DGEO_ERR.DAT. Only if it failed to find this would it resort to use of EGEO_ERR.DAT. Similarly, when run in French, Guide looks for FGEO_ERR.DAT; in Japanese, AGEO_ERR.DAT; and so forth. (For ease of translation, Guide often allows for a file for each language, with only the initial letter changing. The initial letters come from this table.)
Usually, only a few city names need to be translated in this manner. There are exceptions; the CGEO_ERR.DAT (Russian) file is a truly enormous file that essentially replaces GEONAMES.DAT, so that all city names appear in Cyrillic and a lot of cities are added within the former Soviet Union.
How Ax.0 V magnitude data is computed: The USNO A1.0 and its successor catalog, USNO A2.0, were built from red and blue plates. Their magnitudes are therefore R and B (well, close to it; some of the plates are not as 'R' or 'B' as one would ideally wish.) However, when you right-click on an Ax.0 star in Guide, you get an R, B, and a V magnitude. People have asked how this is derived.
The short answer is: not very accurately. The long answer is, well, longer:
About a year or two ago, I was discussing A1.0 and A2.0 use with Bob Leitner, who was using Ax.0 in conjunction with AAVSO charts. He told me that T. Kato uses the following formula to get a V magnitude from Ax.0 B and R data:
V = .375 * B + .625 * R
or, equivalently,
B-V = .625(B-R)
This is not exactly the best way imaginable to get a V magnitude, of course. It sounded as if Kato only uses it in situations where there is absolutely no other choice.
There is some confirmation for this in the header for Brian Skiff's LONEOS.PHOT file, where he states:
To get "pretty good" R from V and B-V alone (for the range 0.3 < B-V < 0.9): R = V - 0.508(B-V) - 0.040.
Rearrangement of this gives:
V = .663R + .337B + .027
Dave Monet, who assembled both A1.0 and A2.0, stated somewhere in the documentation that 'the photometric calibration is about as bad as it can be while still claiming the magnitudes mean something'. I believe he may be doing some work on correcting this, but as far as I know, that statement is still all too true. I suspect that any errors introduced by the B-V = .625 (B-R) rule of thumb (calling it a 'formula' may be overly generous) will be far less than the errors introduced by the poor quality of Ax.0 photometry.
Recalibrating Ax.0 magnitudes: As discussed above, Ax.0 magnitudes tend to be unreliable. But a few months ago, Brian Skiff made a suggestion on the Minor Planet Mailing List that can let you get decent Ax.0 magnitudes for a given area. It relies on the fact that, while Ax.0 photometry is garbage in the absolute sense, relative Ax.0 magnitudes are usually only mildly atrocious. Add or subtract a constant amount in a small region, and the data would be fairly good.
For many purposes, absolute photometric accuracy isn't key. Most variable star observers, for example, just want to compare assorted measurements of a given variable to one another; the fact that they may be consistently 0.8 magnitudes off is not a big problem. But for someone getting a light curve on an asteroid, it would be a problem. The asteroid will move from one field to another, so you can't guarantee consistency by just using the same comparison stars each night. In such cases, the following might be very useful.
Brian Skiff has compiled a large file of "good photometry" covering (as of 18 December 1999) 29500 stars, from a long list of sources. You can click here for an uncompressed version (about 2 MBytes), or you can click here for a GZip-compressed version (about 500 KBytes).
For a given part of the sky, you'll usually find that some of these LONEOS stars are nearby. Skiff's suggestion is that you check some of those stars, compare them to their Ax.0 counterparts, and decide that, on average, A2.0 'pseudo-V' magnitudes are (for example) 1.2 mags too bright (in comparison to LONEOS standards.) You can then use this as a zero-point offset within that region.
It so happens that, if you download the above file and decompress it into your Guide directory, you can then display the data in Guide. Click here for details.
Using this can simplify the zero-point determination. The Ax.0 stars and LONEOS data can be displayed simultaneously in Guide. You can go to the region in question, find nearby LONEOS stars, and right-click on them. When you do that, you'll get either the LONEOS data about the star or the Ax.0 data; click 'Next', and Guide will give the data from the remaining catalog.
I'd add only one warning to this. When Guide shows you the data for an Ax.0 star, it also gives the plate number from which the data was taken. Don't use a zero-point calibration based on data from one plate to adjust Ax.0 magnitudes from a different plate. That is, if you're trying to adjust Ax.0 magnitudes that came from plate #411, base your calibration on stars that appear in LONEOS that have Ax.0 counterparts also on plate #411.
Ideally, none of this would be necessary, because Ax.0 would already be calibrated using LONEOS data. And if USNO gets the time and funding, I suspect a re-calibrated Ax.0 will be made available, and the above will be of historical interest only.
Also ideally, the GSC could undergo a similar recalibration. I've started some work on that process; click here to read about progress on my GSC photometric recalibration project.
22 December 1999 full moon: I got an inquiry, via e-mail, about a rumor than this full moon would be unusually bright, since it would be happening at perigee, "the closest full moon in 100 years". Since the subject came up on the Guide users mailing list , I thought I'd put my reply here:
Hi Gary,
Well... as usually happens with the 'far-out' rumors, somebody took
some grains of truth and then started to stretch the truth.
I just did a quick run of perigee distances from 1990 to 2004, and
got the following five nearest perigees during that time:
2 Dec 1990 10:53 (356527.2 km)
8 Mar 1993 8:31 (356529.7 km)
19 Jan 1992 22:12 (356549.1 km)
4 Nov 1998 0:41 (356615.9 km)
22 Dec 1999 10:57 (356656.7 km)
(All times are UT, Universal Time. Subtract five hours to get EST,
six for CST, seven for MST, eight for PST.) You'll notice that similarly
close perigees have happened before, without having to go anywhere near
a hundred years back.
So you can see we've had some closer passes before this. The moon's
distance varies by about 14%; because tidal forces follow an inverse
cube law, that means the tidal effects vary by about 42%. That's enough
so that you can see variations in ocean tides, and it's something you
have to take into account.
The moon comes to perigee about once every 27.3 days. The difference
between one perigee and the next is very small beer. There would be no
real reason to say that this 22 December 1999 perigee was much more
'extreme' than the one we had 27.3 days ago, or the one we'll have 27.3
days from now.
This particular perigee does indeed occur near full moon. We'll get
a brighter full moon than average, by about 14%. I doubt most people
would even notice. The fact that it's at a full moon will also mean
increased tides; at full and new moon, the sun and moon are acting
together to 'stretch the earth out', so to speak, and you do get
higher than normal tides.
And adding a bit more to this, it's occurring close to a solstice.
That will mean that the full moon will be unusually high in the sky,
resulting again in somewhat higher tides. It also ought to make for
a brighter night than we usually would get.
The end result will be that people like me, who like wandering around
at night, will have slightly more light to work with. (With any luck,
we'll get some decent snowfall and I'll go snowshoeing then.) The
difference in tides will be noticeable. I live about ten miles from the
ocean; a few years back, we had the bad luck to get a big storm at
the same time that a similar set of 'lunar coincidences' was pulling
up higher tides. The result was that some coastal areas got some
flooding. We had best hope for reasonably calm weather for a few days
around 22 December... the lunar effects themselves would just be mildly
interesting, but could make a bad storm worse.
The effect on automated lights would be just about zero. The difference
between sunlight and moonlight is about a factor of a million. That
fact tends to surprise people; our eyes are really quite good at
covering that entire range of brightness. What it means in this case is
that even if the moon were twice as bright as usual (which it won't be),
the sensors would never know about it.
Thanks for pointing this one out. We're down to about nine hours a
day of sunlight up here; the idea of getting a fairly bright night is
appealing.
By the way, the next full moon (January 2000) ought to be much more
interesting, since it will be the first lunar eclipse seen from North
America in the last few years. Some people regard lunar eclipses as the
celestial equivalent of watching paint dry, but I rather like them.
-- Bill Gray
Adjusting "colored stars" to be less extreme: Something I'd not gotten around to documenting: if you turn on "colored stars" in Guide's Star Display dialog, and find the colors to be harsh (type M stars are fire-engine red, type G stars are canary yellow, etc.), add a line such as
FADED_STARS=192
to GUIDE.DAT. FADED_STARS=0 is the default; FADED_STARS=256 would "fade" the stars completely to white. Intermediate values have the logical effect of causing stars to have some color, but not the rather extreme default colors.
Changing Guide's toolbar buttons:
To do this, you should look in the file TOOLBAR.DAT to get the name of a bitmap button for a given function. For example, the first line indicates that the icon for the "load a mark" function is LOAD.BMP. If you create a bitmap with that name (in the Windows .BMP format) and put it in the Guide directory, then Guide will use it on the toolbar, instead of its "usual" bitmap. Create a few hundred bitmaps, and you can replace all the toolbar bitmaps.
However, it would help if you could start out with the bitmaps provided with Guide, and modify them. To do that, download this program (about 10 KBytes) into your Guide directory.
Guide stores all of the toolbar buttons in two files, BITMAPS.LMP and BITMAP2.LMP . The former contains the "normal", default-size buttons. The latter contains the larger buttons used when you go into Settings... Toolbar and select the "use large buttons" checkbox.
If you wanted to extract the bitmaps for the large buttons, you would run the following command:
unlump bitmap2.lmp
Guide would create a slew of .BMP files. You could then edit whichever of them you wished and ignore the rest (or delete them; Guide will still be able to get them out of BITMAP2.LMP.) And, of course, you can extract the bitmaps from BITMAPS.LMP in a similar manner.
If you make a slew of interesting .BMPs for use on the toolbar, please let me know. I still haven't figured out a good way to distribute them, but I'm pondering some scheme in which people will be able to select "alternative" toolbar buttons.