aah@nofs.navy.mil wrote:
> One class of object that I don't think has been searched
> for in Tom's data are cataclysmic variable candidates.
> There have been a bunch of surveys for blue objects, such
> as the Palomar-Green survey, along with Xray surveys where
> you can pick out stars with high Xray flux and variability.
> If someone wanted to cross-check these potential candidates
> and see if any fall within Tom's declination zone, that
> would be a useful exercise. Note that many of these stars
> will be faint at quiescence, but in outburst they may be
> easy targets for TOM1. They will not be in master-star-lists
> since an outburst might only occur on one night and the
> star might not appear on the majority of the remaining frames.
I have been thinking about this, but haven't figured out how to get a
master list yet.
The ways I'd normally do it won't work because they either don't like
the fact that collected.big is not fixed length records, can't cope with
space delimited data properly, don't like unix line endings, or
combinations of all three.
Doug Welch's wsv3.pl on the CD takes stars that have more than 30 pairs
of observations and lumps them in to a file with average RA and V and I
for each. I thought of adapting this by taking out all the ws index
bits, or at least the conditional test for < 30 pairs and just
processing collected.big down to the 95000 stars.
Unfortunately my perl skills are such that I still can't even get
selectun to work for some reason, despite getting wsv3.pl to work easily
(yes, I've put in my directory paths to replace Tom's).
Anyway, if one of the perl geniuses out there could kindly adapt wsv3.pl
to process data _without_ doing the ws index calculation bit I can
easily get a master list that I can process in the ways I normally do,
and I've attacked the various rosat, palomar-green and what have you
datasets before, matching them against other lists.
But this time I can't get that first master list together.
Sorry, can't program for toffee.
(NB VizieR will accept listed inputs, but I seriously doubt it could
cope with 95000 stars at once!!!! Certainly my bandwidth couldn't cope
with download the results file this century if it could!!!!)
As collected.big is half way there for this, all that is needed is
something to go through that file and spit out the ones where there's
only one nights worth of observations for a position, with no other
nights having been recorded. The asteroids should stand out in this way
too, on the whole.
> Likewise, there should be several asteroids in Tom's data.
> These again won't appear on multiple nights and so are
> similar to transient objects. Someone should do a search
> of the asteroid planning databases, see which asteroids appear,
> and obtain their V/Ic magnitudes.
> Arne
Not sure if stationary point asteroids move enough between two
consecutive nights though. Then it'd be a bit more fiddly, but it'd do.
I could do a by eye check here with stuff I've got, using the assumption
that for the limiting magnitude involved here most of the asteroids
likely to be seen have reasonably known orbits. Any fortuitous near
pass NEOs would be something else.
This is a bit inverse to the route Arne suggests for asteroids. I work
with what I've got, and within my online access time. I'd actually find
it easier to match tass objects to asteroids rather than vice versa.
Normally I'd have done something similar already, but I use dbase V
under winblows for such pre-processing, and belying it's vulcan history,
it won't touch unix line end files for import. Dunno if it could even
handle a file that size.
I've still got dbase iii+ in dos somewhere, I'll have a look at that.
Cheers
John G.