Re: downloading data

["Thomas F. Droege" <droege@fastmail.fm>]

Andrew writes:

> Well - that's an omnibus first guess but it throws away the
> information about variable sky brightness and variable
> aperture size.
> 
> Or has this information already been thrown away? I see
> that in another post Tom is talking about reprocessing
> raw CDs; this would be quite unnecessary if the subtracted
> mean sky brightness and aperture size were recorded
> somewhere. If these data have been thrown away, then
> we are out of luck for the quick fix.
> 

This year (2005) I am saving the raw images, the darks and flats used,
the code I am using to take data, and Michael's stuff.  Michael's stuff
allows identification of where all the parameters were set for the
reduction and the programs used.  Thus one can identify everything about
the reduction.  i.e. you can dig the actual apertures used out of the
code.  The only problem is the darks.  You have to hope that the darks
used are up to date.  Since the cameras are temperature controlled, the
darks to not change very much.  I am using sky flats, so these can be
reconstructed any time one wants from the current data or yesterday's
data or ...

The new data keeps a copy of make_list.out.  This has a sky brightness
and a sky sigma term recorded.  Possibly this is what Andrew wants.  The
new data also keeps .param file for each block of data taken.  This
records everything about the pipeline settings.  

The images for the data in the data base (2003, 2004) were less
carefully saved.  The images were saved after dark and flat correction. 
We did not keep track of the exact code used, but it did not really
change much. I have a lot of disks saved where I recorded copies of
everything used, but it would take some effort to match the program data
to the image disks.

I really recommend doing any work with the new data.  

Tom Droege 


On Wed, 28 Sep 2005 21:06:24 -0300, "Andrew Bennett"
<andrew.bennett@ns.sympatico.ca> said:
> On Wed, 28 Sep 2005 10:42:32 -0400, Michael Richmond
> <richmond@stupendous.cis.rit.edu> wrote:
> 
> >  Andrew wrote:
> >
> >> One degree boxes now mean Sec(Declination) degrees in
> >> RA so my boxes now overlap except on the equator. Just
> >> another minor change to my code to ignore the stuff I have
> >> read twice.
> >
> >  I'm the guilty party who asked Michael S. to make this
> >change.  Most of the other tools I use to request data
> >from big databases (SIMBAD, NED, etc.) use the convention
> >that a one-degree box cover a square one-degree region
> >on the sky.  The old TASS interface yielded a square
> >region near the equator, but an increasingly elongated
> >rectangle as one moved towards the poles.  I think
> >that the new convention will make analysis simpler for
> >most users.
> 
> Yes. I now see that my code was horribly lazy and
> needed fixing up to deal with edge effects and working
> away from the equator.
> 
> >
> >> But some things have not changed. One is still given the
> >> incorrect error estimates:
> >
> >  I'm guilty of not moving quickly on this point.  I have
> >been wanting for a long time to provide two tables of
> >information:
> >
> >     1) table of scatter of Mark IV database magnitudes from 
> >             their mean value, as function of magnitude,
> >             something like this (I'm making up values here)
> >
> >                 V mag         7       8      9     10    ....
> >                 V uncert    0.03    0.05    0.07  0.10   ....
> 
> Well - that's an omnibus first guess but it throws away the
> information about variable sky brightness and variable
> aperture size.
> 
> Or has this information already been thrown away? I see
> that in another post Tom is talking about reprocessing
> raw CDs; this would be quite unnecessary if the subtracted
> mean sky brightness and aperture size were recorded
> somewhere. If these data have been thrown away, then
> we are out of luck for the quick fix.
> 
> >...
> 
> >  Andrew, would these two tables, and a single "typical" uncertainty
> >value based on them, satisfy some or all of your needs?
> 
> Without the mean sky brightness and aperture for the
> image, I can do about as well by adding one line to my
> code to compute Magerr(Mag) instead accepting the
> value read in. 
> >
> >                                          Michael
> 
> Andrew Bennett, Avondale Vineyard, NS, Canada
> 
-- 
  Thomas F. Droege
  droege@fastmail.fm