Re: September Data

[tom <tdroege2@earthlink.net>]

Doug,

It is the image back up files that take all the time.  I only make one copy of 
those.  The multiple copies are done once a month.  I have tried running on 
several machines at once and sometimes I can do it but mostly I make 
mistakes.  It only takes about 5 minutes to write a CD, but today I wrote 19 
of them.  I have written scripts for most of the process.  It could be 
improved.  There are 4 machines involved and they all have CD writers.  So in 
theory I could start 4 at once.  It could probably be improved if I were to 
spend a few days organizing it better.  Sigh!

Tom Droege

On Tuesday 21 September 2004 03:47 pm, Doug Welch wrote:
> Hi Tom,
>
> Perhaps the question should be: "Is there a way to burn CD's that
> doesn't involve your continuous presence at the machine?" If you are
> always writing three copies, you could potentially run these on three
> CD-burners simultaneously (possibly on the same computer, but not
> necessarily). Would buying a CD production unit free up your time?
>
> Cheers,
> Doug
>
> tom wrote:
> >I know some of you sneer, but September is turning into a record month.  I
> >have burned 300 CDs so far this month.  I keep wondering if there is a
> > better way to archive data, but my research says that CDs are probably
> > the best media for long term storage.
> >
> >It is a royal pain since it takes several hours just sitting in front of
> > CD burners each day.  It is a real pain since it the interval between
> > changing CDs is not long enough to do much else and if I try I make
> > mistakes.
> >
> >So far I have taken data 19 out of the first 20 days in September.  This
> >should make a nice sequence for testing things about the data.   All the
> > data is not perfect.  Some stars, for example, grow halos at some periods
> > in the night.  I think it is a question of ground fog and the like. 
> > Still, when I exclude such frames from the data set, the scatter does not
> > improve.  So there is something else going on that is there on clear
> > nights.
> >
> >I am not saying fuzzy frames don't have larger errors, I am saying that
> > the frames that look bad contribute less error from their badness than
> > other hidden errors.  If we fix the other error, then possible excluding
> > "bad" frames might make the data better, but not at present.
> >
> >Tom Droege