Changes for 15 Dec 2010: * I wanted to be able to output dates without spaces in 'full_ctime( )', so I added a FULL_CTIME_NO_SPACES macro in date.h and added a few corresponding lines to 'miscell.cpp'. This was done to support some things going on in 'astcheck.cpp', a new program that reads 80-column MPC astrometry data and looks for corresponding objects. 'astcheck' is now included with this code, since it's a decent demonstration of some of the things in this library. Change for 1 Oct 2010: * Realized that 'get_time' handled decimal year input relative to J2000 = JD 2451545, i.e., 1.5 January 2000. Integer years were handled relative to 1 January, which makes more sense. So I redefined J2000 to be JD 2451544.5. Now, entering a value such as 1999.99999 gives a value shortly before 1 January 2000, instead of just before midday on that day. Changes for 19 Sep 2010: * Added observed Delta-T data for January 2010 to the array of Delta-T values in 'delta_t.cpp'. Also added three projected leap seconds for 2013, 2016, and 2019, to keep UTC-UT1 close to zero over the next decade. (Those projected leap seconds will almost certainly prove to be wrong.) Changes for 13 May 2010: * Martin Ettl kindly passed on some results from 'cppcheck' (http://sourceforge.net/projects/cppcheck/), which revealed the following issues: [phases.cpp:295]: (Error) Resource leak: log_file [phases.cpp:295]: (Error) Resource leak: data_file [de_plan.cpp:299]: (Error) Resource leak: ifile [persian.cpp:216]: (Error) Memory leak: jds [mpcorb.cpp:29]: (Error) Uninitialized variable: rval [rckin.cpp:75]: (Error) Resource leak: ifile [elp82dat.cpp:383]: (Error) Deallocating a deallocated pointer: ifile [colors.cpp:275]: (Error) Resource leak: ifile As it happens, none of these are particularly worrisome. In certain processing programs, I've relied on the fact that files are closed and memory freed when the program terminates. All of these issues, except for the one in 'elp82dat', are of that sort. I am reasonably certain that the 'elp82dat' reflects a problem in cppcheck. Still, I'm impressed with the fact that 'cppcheck' was able to find such issues, and would like to be able to use it in the future. So I've fixed all of the above issues (except the elp82dat one), in hopes of getting a clean bill of health from cppcheck in the future. Changes for 28 Mar 2010: * showelem.cpp: All calendar conversions were being done with the Gregorian calendar only. I revised it so that the Julian calendar is used before October 1582. (Basically just meant using CALENDAR_JULIAN_GREGORIAN rather than the default.) Changes for 2 Feb 2010: * 'date.h': added some macros demonstrating how one can set the precision and format for date output. Changes for 15 Feb 2010: * 'chinese.dat': Following a question from Mark Sims, I realized that certain years in the data file for the Chinese calendar were set incorrectly. Specifically, any year in which the preceding year had an '11i' or '12i' intercalary month was stored with garbage data. This occurred in 68 years over the 5990-year range of the original 'chinese.dat'. This was due to a small bug in the processing programs. I've fixed this, and generated a new 'chinese.dat' covering the years -3000 to +7000 Gregorian (the previous one covered -3000 to +2990). Be advised that, since the Chinese calendar is an observational one, the extrapolations into the past and future get to be iffy as uncertainty in Delta-T grows. If the time of New Moon is very close to midnight Chinese time (zone UT+8 hours), a small change in Delta-T may cause a month to begin a day earlier or later. The first such case is the lunar month corresponding to a New Moon at 28 Sep 2057 16:00:17 UT, just after midnight in the UT+8 zone. But some sources (including the Hong Kong observatory) have this occurring just _before_ midnight. The uncertainty in Delta-T for 2057 is such that either of us could be right. As one goes further into the future (or past), uncertainty in Delta-T grows, and so does uncertainty about the calendar. Similar issues plague the Jalali calendar and the French Republican one (sort of; note that it's unclear if the Republican calendar was intended to be algorithmic or observational). Changes for 29 Jan 2010: * 'triton.cpp'/'marsuran.cpp': Realized that 'marsuran' was essentially no longer in use, and in some cases shouldn't be used (the Uranian and Martian satellite solutions were abysmal). Ideally, I'd just drop this file completely. But it also contains an algorithm for Triton's position, which I need to keep because the 'rocks' solution is wrong (see comment below for 'rocks.cpp'.) So I removed most of 'marsuran.cpp' and renamed it to 'triton.cpp'. The renaming seemed wise, given that all Martian and Uranian satellites had been completely removed! * 'rocks.cpp': realized that the data for Triton must be wrong somewhere; the orbit given in this file (from JPL's NEP050 solution) results in prograde motion. I've not puzzled it all out yet, but it's definitely wrong. Added a suitable comment to warn about this. Also, Uranians are all based on URA091 now (instead of, mostly, URA086X.) * 'get_time.cpp': Removed the 'scan_for_time' variable, which was occasionally set, but never actually used anywhere. * 'cospar.cpp': Realized that errors were mis-handled. There's code to extract the planet orientation and spin rate from 'cospar.txt', then save it for the next call... but the error code was _not_ saved for the next call. Some of my code was therefore thinking it was getting a perfectly decent orientation matrix, even though it wasn't. Also, added orientation data for the Plutonian moons Hydra and Nix. No 'official' model exists for these, but as described in 'cospar.txt', I was able to make a reasonable rotation model for them. Changes for 11 Jan 2010: * 'showelem.cpp': now supports more digits of precision, enough to support the full range of 64-bit floats. This isn't apt to be very useful to anyone; I added it to simplify some debugging I was doing in Find_Orb. Changes for 24 Nov 2009: * Fixed some loss-of-precision problems in 'classel.cpp'. Specifically, I noticed that the argument of perihelion was computed using arcsin, so that if sin(arg_per) was near +/-1, you'd lose precision. In fact, one could get a result slightly outside the -1 <= sin(arg_per) <= 1 range. Also did a lot of cleanup. Changes for 21 Oct 2009: * Made a lot of small changes to evade gcc and MinGW compiler warnings. I also investigated an old optimization bug in 'de_plan.cpp', but was unable to replicate it. For the nonce, at least, I'm leaving optimizations fully enabled. Changes for 20 Sep 2009: * Fixed a bug in 'date.cpp' wherein a 'month_data' buffer of 13 bytes was subjected to the line memset( month_data, 0, 14); I think this got by because the extra byte was blank anyway. But the latest gcc caught this bug and considered it to be 'stack smashing'. In the investigation of this bug, I cleaned up some of the date.cpp and jd.cpp code: no changes in functionality, but it's easier to read. Changes for 9 Apr 2009: * Added some comments to 'integrat' explaining how the integration scheme works. Changes for 4 Apr 2009: * Added a 'make' file for MinGW (gcc for Windows). Everything compiled Just Fine, except for an issue with the use of asinh() in astfuncs.cpp. That source file now recognizes that asinh is only needed with Microsoft Visual C/C++. * COM_FILE.CPP: when extracting a periodic comet name, preference now goes to the permanent designation. So if given P/Van Ness (213P) (P/2005 R2), the name extracted would be (213P). This should help to evade some problems with certain comets appearing twice. Changes for 21 Mar 2009: * Various files: This code does a fair bit of direct reading of structures from files on disk. To do that, it relies heavily on sizeof(short) = 2 and sizeof( long) = 4. This is, of course, stupid, and means any 64-bit compiles will break. Where structures are read from disk, they now use int16_t and int32_t, instead of short and long. Changes for 16 Mar 2009: * GET_TIME.CPP: If the input date/time has a field with a decimal point, you can be pretty sure that that is the day of the month. The code now makes use of this fact for puzzling out the formats. (For example, both '9.75/4' and '4/9.75' would be interpreted as 9 April 18:00.) Changes for 13 Feb 2009: * ROCKS.CPP: Got data for Deimos and Phobos from Bob Jacobson at JPL. Rearranged the rock elements slightly, and they're now in numerical order. Also wrote a little 'rckin' program to take the JPL format and convert it into C code, fixed a mistake of long standing in the numbering of Uranus XXV = Perdita, and enabled certain satellites that had been disabled (simply because Guide wasn't using them). * BIG_VSOP.CPP: Added a file 'big_vsop.txt', which describes how this function and the data are set up. * INTEGRAT.CPP: Improvements to handling input dates in various formats, fix to allow Pluto to be in the file. See 'integrat.htm' for details. * GUST86.CPP: Code to compute positions for five main satellites of Uranus (Miranda = Uranus V, Ariel = Uranus I, Umbriel = Uranus II, Titania = Uranus III, Oberon = Uranus IV). Thanks are due to Chris Marriott, the author of _SkyMap Pro_, for the original version of this code. I've had this sitting on my hard drive for an embarrassingly long time. See 'uranus1.cpp' and 'uranus2.cpp' for usage demonstrations. Changes for 23 Oct 2008: * ASTFUNCS.CPP: the kepler( ) function has gone unchanged for about a decade, so I was surprised to find _two_ bugs in it. For certain hyperbolic, very high mean anomaly cases, it failed to exit a loop, because it looked for fabs( err) < thresh . In reality, delta_curr was becoming suitably small, and that was the value that should have been tested. Also, for elliptical cases, the mean anomaly really ought to be kept in the range -pi < mean_anom < pi. For M slightly outside that range, you lose a little precision and waste an iteration or two. For M far outside that range (i.e., "many orbits completed"), you lose _lots_ of accuracy. This also caused me to see some possibilities for loss of precision with nearly-parabolic orbits, resulting in a new 'near_parabolic' function that does essentially the same math, but in a way that avoids subtracting nearly-equal quantities. * DELTA_T.CPP: added newly announced leap second for end of 2008. * ROCKS.CPP: Updated orbital elements for Pan and Daphnis, from SAT276 to SAT291. * GET_TIME.CPP: added better handling of offsets, so one can have '13:14-10m +3h' interpreted as 16:04, for example. Also, days of the week can be entered (which meant I had to add some day-of-week functions to 'date.cpp'). Changes for 6 Apr 2008: * GET_TIME.CPP: function mostly extracted from Guide that parses time strings, sort of an inverse of 'full_ctime'. It attempts to handle odd inputs 'logically' (i.e., "2007-10-17" will be understood even if those three values are in an odd order, because 17 is clearly a day of the month and 2007 a year, leaving 10 as the month). * GET_TEST.CPP runs assorted tests of the above function. * MISCELL.CPP: fixed a rather stupid series of bugs in 'full_ctime' which caused instants a few microseconds shy of midnight to appear as 2:24:00 (i.e., one-tenth of a day). * DIST_PA.CPP now has a "reverse" function: given a point and distance and position angle, it computes the resulting point. * VISLIMIT.CPP was set up so that the instant the moon went below the horizon, its contributed light went to zero. I'm not sure what the actual behavior should be, but that was definitely wrong. I revised it to have a fairly sudden exponential decrease as it goes below the horizon. * JD.CPP shows Delta-T for the selected time. That just provided me with a convenient testing mechanism. It also now uses the 'get_time.cpp' function, so the date on the command line can be more flexible (and so I can test the 'get_time.cpp' functions.) Changes for 2 Feb 2008: * ROCKS.CPP: Updated most of the rocks and added some new ones. * COSPAR.CPP: Revised so it gets data from 'cospar.txt'. This allows it to generate correct rotation data, including the previously neglected smaller terms, for all planets and satellites, including many previously ignored as "insufficiently important". From time to time, changes may be made to the COSPAR data in 'cospar.txt'. (For example, the model for Mercury was recently improved, and one matching the average rotation rate of the clouds of Venus was added.) Those changes will be described at the end of that file, in the comments section. The previous implementation is still provided, as 'cospar2.cpp', just for reference; I don't expect to be making any use of it. * DELTA_T.CPP: Updated the Delta-T lookup table. * EASTER.CPP: 23 Mar 2008 is Easter, and a neighbor of mine asked about when Easter would be so early again. I revised the test routine so you can find out in which years Easter will fall on a given day (in addition to the previous, more common "when will Easter be this year"). * SHOWELEM.CPP: Epochs with precision greater than .01 day were "shifted" to the nearest .01 day and the mean anomaly adjusted accordingly. This is fixed: if you specify the "usual" sort of epoch (i.e., midnight UT for some date), the output will look as it always did (truncated to one decimal place), but otherwise, decimal places will all get shown. Changes for 3 July 2007: * JD.CPP: Added code so that most cases where day/month/year is entered on the command line, instead of year/month/day, will be corrected. Changes for 8 June 2007: * ROCKS.CPP: Converted some variables to type 'const' to help me see what the heck is going on. * INTEGRAT.CPP: Made some small revisions because MPC altered the 'mpcorb' format very slightly, so that when the program looked for the names 'Ceres', 'Pallas', and 'Vesta', it didn't find them. Now it will, whether the input is in the old or new format. Changes for 23 April 2007: * JD.CPP: Added an error message for cases where no date is specified on the command line, removed some unused macros and variables, and changed certain "variables" to be of type const. (This is largely cosmetic: if a particular "variable" is, in fact, constant, I like to make that fact obvious.) * ASTEPHEM.CPP: This program now gets orbital elements from 'mpcorb.dat' (or 'mpcorbcr.dat'), rather than from Guide-format elements. As before, it uses those elements to generate asteroid ephemerides. * COSPAR.CPP, MISCELL.CPP: compiling with gcc -Wall caused a few warning messages to appear, mostly for cases where things defined as 'int' should have been 'long int' or vice versa. Again, cosmetic (unless one were on a system wherein 'int' differs from 'long'.) Mid-2006 changes: * ASTFUNCS.CPP: A couple of lines in the 'kepler' function for handling "hyperbolic, large-mean-anomaly cases". Such cases caused overflow problems (when _really_ hyperbolic and large-MA... but such cases arose with objects in planetary encounters.) */ * DIST_PA.CPP: As comments in the source indicate, there was a roundoff problem with certain position angles where the RAs were identical, or nearly so. I essentially had to do a total rewrite, abandoning the haversine-based approach. * SHOWELEM.CPP: Distances are now shown in kilometers (not AU) whenever they are less than 400000 km (roughly the distance from the earth to the moon). * DELTA_T.CPP: Added leap second for 1 January 2006, plus comments on which leap second is which. Changes for 29 March 2005: * SHOWELEM.CPP: The 'decimal_day_to_dmy' function now takes a 'calendar' argument, instead of assuming Gregorian. That allows use of the function by assorted calendar-dependent routines in Guide. Most other uses will just pass in a 0 (Gregorian) value. * REFRACT4.CPP: Some code for a 'reverse_integrated_refraction' function, which inverts the 'integrated_refraction' function. Changes for 3 Feb 2005: * DATE.CPP: Found and fixed a bug in the 'is_hebrew_leap_year' function. * SOLSEQN.CPP: Added some error handling for cases where the 'big_vsop.bin' file isn't found. * Generally: Switched use of asin( ) to asine( ), i.e., the version that protects against domain errors. I was getting such errors in Find_Orb, and was trying to track them down. It turned out to have nothing to do with asin( ) calls in this library... but they're a good idea anyway, just on general principle. Changes for 16 Dec 2004: * DATE.CPP: Changed a lot of variables to be of type 'const'. This has no bearing on the actual operation of the code, but it does mean that a human reading the code can say: "OK, I know these variables aren't going to change within the function." Changes for 1 Dec 2004: * DELTA_T.CPP: Previously, there was an adjustment to Delta-T within the code now marked by "#ifdef TRY_OMITTING", for years before 1620. The idea was that the formulae for Delta-T were originally derived with an assumed lunar secular acceleration of 26 arcseconds per century^2. If you use a theory such as VSOP or ELP, which assume a secular acceleration of -23.8946 arcsec/cy^2, then you have to assume the earth's spin is, in the long run, decelerating at a different rate... after all, if the moon is receding at a different rate, it's soaking up the earth's angular momentum at a different rate, too. However, I'm now using DE-405 and DE-406 for just about everything. I could have made sure that Delta-T was adjusted for DE-40*, or the other way around. I chose the latter. (Dealing with these assorted time systems is a heck of a mess!) * ALT_AZ.CPP: Some new code to add "supergalactic" transformations as a parallel to the galactic ones. Changes for 7 April 2004: * DATE.CPP: the "modern Persian" calendar is now supported. This corresponds quite closely to the traditional Jalaali calendar, but instead of being a purely observational calendar, 683 leap years are spread evenly over a 2820-year span. Changes for 17 Dec 2003: * MISCELL.CPP: the 'full_ctime' has been mostly rewritten to allow handling of different calendars, and more flexible formats and setting of levels of precision. Most of this was required by my Guide software, to support a new feature wherein people could specify exactly how times and dates are to be formatted (see http://www.projectpluto.com/update8.htm#time_format .) All this also meant some changes to the FULL_CTIME macros in 'date.h'. * DATE.CPP: the code for setting/storing month names used to copy in the month names provided to set_month_name(), which meant you couldn't have excessively long names (more than six bytes plus a trailing NUL). Now, instead, set_month_name() maintains a table of pointers to the user-specified month names, and provision is made for a thirteenth month name (useful for the Hebrew and French calendars). All this was required for the same 'time_format' dialog described in the URL given in the previous paragraph. * DELTA_T.CPP: brought the table of delta_t values up to date. Values for late 2003 were off by about 1.2 seconds! * INTEGRAT.CPP: this code used to assume that the first, second, and fourth asteroids in an 'mpc_orb.dat' file were Ceres, Pallas, and Vesta. It then assumed that it could compute positions for these three asteroids, and compute perturbations caused by them. That was a bad move, since there are 'mpc_orb'-formatted files that don't contain these four objects. The code now looks for the actual asteroid names "Ceres", etc. instead. * NUTATION.CPP: fixed an erroneous coefficient reported by James Miller and Mark Huss; that repair required me to clarify the code a bit. It's not quite as cryptic as previous versions were. Changes for 12 Dec 2002: * Added REFRACT4.CPP, code to compute a truly "accurate" refraction value via numerical integration. Compare to the code in REFRACT.CPP (which is much simpler, but not quite as precise.) * COLORS.CPP was fixed to read 'loneos.pho' properly (it was getting confused by lines where the RA was given to .001-second precision). * The Republican calendar code in DATE.CPP was returning weird values (and sometimes just locking up!) for dates prior to JD 2007729.5 or after JD 2598322.5. The values outside that range are still not necessarily exact, but should at least be close, with more "graceful" degradation of accuracy. * REFRACT.CPP had an error, where I thought the input value was in degrees, but it was really in arcminutes. * INTEGRAT.CPP and SHOWELEM.CPP had slightly "bad" planetary masses (in particular, that for Earth was off by about .5%!) Changes for 6 June 2002: * There's now a LUNARDLL.MAK file, for creating a 32-bit Windoze DLL. * The #defines for AU_PER_DAY and AU_IN_KM were moved into 'afuncs.h'. I hadn't realized this, but there were a few places where both were defined with fewer digits than one might ideally like. This affects a slew of files. * DATE.CPP: the method for handling the French Revolutionary (Republican) calendar was changed a bit. You can still use the "algorithmic" methods, but there's some new code that allows you to use the original ugly scheme in which the year begins on the autumnal equinox, so leap years occur at either four or five-year intervals. (#define's can switch you back to the other methods.) The code looks much like that for the Persian Jalaali calendar, and I used the same program, PERSIAN.CPP (q.v.), slightly modified, to generate the lookup table. * DELTA_T.CPP now contains a table of values of Delta-T to .01 second, not .1 second, precision. I made the size of the table a #define, since I keep increasing it a bit from time to time. There are some new notes at the bottom of the file, because at some point, I want to include some code to give, not just Delta-T = TDT - UT1, but TDT - UTC. For the latter, I'll mostly just need a table of leap seconds. But none of this affects the code yet. * DIST_PA.CPP: in reply to an inquiry as to how this function works, I added some comments and revised a bug in how the PA was done. * EASTER.CPP: mostly cosmetic change of some values to type 'const'. * PERSIAN.CPP: code added to do a similar analysis for the French Revolutionary (Republican) calendar. See DATE.CPP. (I also switched to use of the "full VSOP" as used in BIG_VSOP.CPP, rather than the "small VSOP" used previously. That gave better accuracy, but also meant I had to make some minor changes to the make files.) * PRECESS.CPP: Jordi Mas reported that the function 'setup_ecliptic_precession( )' was broken, and has probably been so since it was first written. (I never actually had a situation where I used it.) It's fixed now. * SSATS.CPP: After I got an inquiry about these formulae, I added some comments near the top, and made some cosmetic changes such as converting some values to be of type 'const'.