[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fwd: Re: Tale of a Tile]
One idea. Divide every frame into five areas, top, bottom, left,
right and center. Then when you querry the data out of the database
you ask the database to group the data by frame area. That should
make it pretty clear to any user and the method generalizes to
older non-tiled data.
You don't have to store "area" in the database, it can be computed
on the fly from the star's location and the frame's limits
You may even want to do this now: Find observations of a star that
just happen to be made on the same area of the CCD.
My opinion is the the cal and list files should be temporary files
that get deleted as soon as data hits a database. These files should
live for, maybe 8 seconds
--- Tom Droege <droege@snapmail.us> wrote:
> ---------------------------- 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
> >
> >
> >
> >
>
>
>
>
>
Chris Albertson
Home: 310-376-1029 chrisalbertson90278@yahoo.com
Cell: 310-990-7550
Office: 310-336-5189 Christopher.J.Albertson@aero.org
KG6OMK
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com