[Fwd: Re: Tale of a Tile]

["Tom Droege" <droege@snapmail.us>]

---------------------------- Original Message ----------------------------
Subject: Re: Tale of a Tile
From:    "Tom Droege" <droege@snapmail.us>
Date:    Mon, April 4, 2005 9:52 pm
To:      "Stupendous Man" <richmond@stupendous.cis.rit.edu>
--------------------------------------------------------------------------

Michael, (and forwarded to all)

The present tiles are 4.2 degrees so with a 4 degree grid one gets the
overlap.  This is a problem.  If we just put all the data in the data
base, then the overlap files will look like junk.

Thus there will have to be a way to get the tile information.

If we just distribute the .cal files, then there is a lot of work to find
the tile in which a star was measured.  I suppose you can do it with just
the .cal and .list files??

Unsophisticated users, (I won't name names but you can guess) will just
extract a position from the data base and then they will see bipolar data
for stars on the borders and they will declare that tass data is junk.  I
would like to figure out how to spoon feed these users so they are not
disappointed.

The easy way to do this is to give them the data in "tiles".  Thus they
look up the tile for their star of interest and get the data from just
that tile.  That way all the measurements will be taken under the same
conditions and it will look about 5x smoother than the engineering data.

While I think it will be possible to do some grand calibration, I don't
see it happening in my lifetime.  ;^)  The data has been out there for two
years and I don't see all that much calibration activity.  I have had a
shot at it and Michael and Andrew have done work.  Results are scarce.

My thinking is to use about 3 telescopes taking tiles while tracking them
for 2-3 hours.  The other two will scan the whole sky moving between each
exposure.  Michael, I could do the all sky scanning on say a 2 degree grid
and that would give you the needed overlap. But it is wasteful, and I
think I will opt for a different grid once a season.  It depends, if
someone commits to using the data for a shot at calibration, then I will
take it.

The idea is that the 2-3 hour tiles get short period variables if we do
enough of them.  The all sky scan gets the whole sky a few times a month
and thus gets the medium periods.  OK, not perfect, but it is what I can
see I can do.

Unless someone steps forward to do a lot of work on the calibration, then
I see what I push through Michael's pipeline as the final data.  I would
like it to be better, but I am practical and plan to do the possible. The
present plan is to save all the raw data and dark and flat calibration
files so that it will be possible to later do some better calibration.

Tom Droege

>
>> If I run with fixed sky tiles, then we will want to keep the tiles
separate forever.  This means that a star measured on one edge of a
tile will have to always be considered a different star from when it is
measured on the other edge of a tile. Well, it's the same star, but
users
>> of the data will be urged to only look at the data from one tile at a
time.
>
>> This means that we don't want to have to look in the .fits header to sort
>> out all the images from a tile.  Well, I don't think we do.
>
>   Most users will get the data from a database; for them, the file
> names are irrelevant.  A few very people -- like Tom -- will
> view and analyze the data while it is still in its original
> files.  If this name change makes their job easier, and doesn't
> affect people downstream, then why not do it?
>
>> This also means that we will want to put ra,dec into the .cal file names.
>> My plan is to have .cal files associated with a tile in the sky.  Else we
>> lose the scatter improvement for the stars that appear in two tiles.
>
>   Regardless of the file name, as long as one has in the database
> a record of the original image from which a measurement was taken, one can
>
>               - pick out images which had the same center
>                     (if desired)
>               - analyze stellar measurements from these images
>                     only
>
>   I've written scripts to do exactly this.
>
>>  ... For the purpose of studying variable
>> stars, the fixed position in a tile is better, and no worse in
accuracy. So why not measure that way?
>
>   I agree, with one caveat.  I'd like to see the tiles overlap
> by, oh, a half-degree or so, so that several hundred stars
> appear at both left and right, or at top and bottom, of adjacent tiles. 
This gives you some idea of the size of the systematic
> error in photometry which is hiding in the data.
>
>   Perhaps one could make almost all runs in the non-overlapping
> tile mode Tom has suggested -- which gives the maximum sky coverage for
a single night -- and just once or twice a month (or season?), one might
choose a more tightly packed centering scheme so that
> there would be overlap.  One might then derive the systematic
> error from the few nights, which would be a very good check
> on the instrumental response, if nothing else.  "Hey -- the
> upper-left corner is a lot less sensitive than it was last
> month .... oh, there's a bird's nest in the lens."
>
>                             Michael
>
>
>
>