[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[TASS] IAU designation, problems with database, CVS
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
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
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
- but the JD encoded in the file name isn't the same!
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
P.S. I will send a report on the RTML meeting at Berkeley last week
in the next couple of days.