[TASS] IAU designation, problems with database, CVS

[Stupendous Man <richmond@A188-L009.RIT.EDU>]

  First, the IAU "Clearing House" of Commission 5 Task Group on
Designations has officially granted us an acronym.  I quote from
their E-mail to me:

> We are pleased to announce acceptance of your recently submitted acronym
> TASS  by the IAU Registry.  It has been entered into the on-line
> Reference Dictionary of Nomenclature of Celestial Objects.
>
> The details of the registered acronym can be found at the URL
> http://cdsweb.u-strasbg.fr/cgi-bin/Dic?TASS

  So, hooray for us.

  Second, Andrew Bennett has played detective recently, and found
two puzzles.  He notes that

         a) one particular star, TASS ID 12526823, has one data point
            4 mag below all others, and is too close to another star,
            TASS ID 1694136, to be real

         b) the dates associated with each observation of this star
            do not match up with the dates recorded for camera
            activity -- the stellar observation dates are 1.0 days
            earlier than the camera activity dates

  I have looked into these two puzzles.  Here's what I can say.

         a) there is only a single real star at the position of TASS stars
            12526823 and 1694136.  What happened is that this star fell
            very close to the northern edge of one of Glenn's cameras.
            It was once reported to be split into two components:
            a bright one (with nearly all the flux) and a faint one
            (which isn't real).  These two components went into the
            database as "seeds."  On some occasions, one of Glenn's
            cameras noted a single bright star, but reported its position
            close to the faint, false, seed.  So, that false seed
            was built up into a "real" star.  Other cameras saw the
            star at its actual position, and so that true position
            was also built into a "real" star.

            The end result: two stars in the database, which are really
            the same physical star.  On a single occasion, two components
            were reported (one with actual magnitude, one much fainter).
            On all other occasions, only one star was reported, but sometimes
            closer to the false position.

            Conclusion: the single, faint measurement is spurious, not
            a real dimming.  We were unlucky in this case --- a single
            false detection was built up into a realistic (but false)
            second star.  This means we must somehow build better
            algorithms to combine data in the future.

         b) Okay, but why does the "camera activity" log show a different
            date than the "stellar catalog"?  The Mark III cameras
            reported measurements of each star in the image, in a file
            with one line per star, like this:

               x   y    JD    RA   Dec    mag    etc. etc. etc.

            The "stellar catalog" parts of the TASS database
            (i.e. the "tass_cat" and "tenxcat" and "observ_3i01" tables)
            use the "JD" value from the contents of each line of this
            file when reporting on the time of a measurement.
            So far, so good.

            On the other hand, these files, each of which contained
            measurements of thousands of stars, were given names like
            this:

                          30T0985.820

            where the first 4 digits "30T0" encode some information about the
            camera, the next 7, "985.820" encode the Julian Date of the
            middle of the exposure.  The database contains a table
            called "source_file", which holds information about the
            camera activity -- where it was, when it was active.
            The script which filled this part of the database took
            the Julian Date for camera activity from the FILE NAME
            of each file (rather than from the measurements of stars
            inside the file).

            Now, the problem is that, evidently, the software which
            read out Mark III cameras had an internal inconsistency.

                - the JD associated with each stellar measurement might be
                             984.82

                - but the JD encoded in the file name isn't the same!
                             985.82

            I don't know which date is actually correct, but I suspect
            that the times inside the file, associated with
            each stellar detection, are the right ones.  My guess is that
            the program which generated the file's name might have
            calculated the date incorrectly.

  So, there's a one-day difference between the recorded times of
camera activity (for some cameras, at least), and the times recorded
for each stellar measurement they made.  I don't know which date is
the right one.  :-(

  Finally, on the question of software source control: I agree that
CVS is a good tool to use for this job.  I've used CVS to coordinate
the development of astronomical software by people at different
institutions in the past, and it worked.

  We can use linuxbox.com, or I'd be happy to set up a CVS repository
on one of the computers here at RIT.  I have plenty of disk space and
a fast connection.  I just installed CVS version 1.10.2, which supports
client/server operations.


                                              Michael Richmond

P.S. I will send a report on the RTML meeting at Berkeley last week
     in the next couple of days.