Re: Elixir Reprocessing

From: Jean-Charles Cuillandre <jcc_at_cfht.hawaii.edu>
Date: Tue, 11 Mar 2008 10:11:27 -1000

 Hi,

I understand then that CADC is ready today to accept the reprocessed
files and they'll replace automatically the old ones, and Terapix will
be able to see/get them right away?

The PI 07B DADS CFHT distribution is complete, and the machines are available
now for the LS reprocessing - I have not heard about data transfer speed
improvement from Kanoa, that will be the key factor for getting all the data
in time for a spring T0005 release.

                                                Jean-Charles.

> Hi,
>
> I support the least effort option, after considering the scientific
> issues. Let's just replace.
>
> David
>
>
> Séverin Gaudet wrote:
> > I support the least effort option, i.e., replacement. I do recognise
> > that my answer is based on technical reasons and not on scientific
> > reasons.
> >
> > Séverin
> >
> > On Mar 4, 2008, at 5:40 PM, Jean-Charles Cuillandre wrote:
> >
> >>
> >> Hi JJ,
> >>
> >> I am afraid the long path is going to take some time to realize,
> >> weeks at least, while the pressure to move on and start the
> >> reprocessing is rising quickly (specially with possible bandwidth
> >> limitations).
> >>
> >> The initial word I have of Terapix on the first test set is that
> >> it is not worse (nor better) than T0004/3/2 data (that's before
> >> applying a secondary color correction, something I attempted to
> >> explain to you last week). So, there you have it: at worst it
> >> will be the same, actually better since:
> >>
> >> - All data since first light follow the same photom flat recipe (B4)
> >> - The major ZPs issues has been smoothed out
> >> - (and I can't imagine all this improvement work on the B4 flat
> >> by a bunch of us does not show up in the general data set!)
> >>
> >> I want to say, let's just replace the files and I will document this on
> >> the MegaPrime pages asap - the user who pick them up ought to find their
> >> way. We will make it clear that CFHT+CADC will do their best to support
> >> the old B1/B2/B3 versions if they turn out to be needed for some reason.
> >>
> >> The advantage of replacing the files straight is that it saves us from
> >> worrying about the replacement later on, no file confusion is possible.
> >>
> >> Shall we vote on this?
> >> Jean-Charles.
> >>
> >>> Hi All,
> >>>
> >>> I think the following is the flow of what will/must happen for the
> >>> switch for the current CFHT Elixir data to the CFHT Elixir-B4 data.
> >>> Looking at what this will actually involve is starting to make me
> >>> wonder if its worth the effort.
> >>>
> >>> The options available are listed below. Please comment.
> >>>
> >>> JJ
> >>>
> >>>
> >>> a) Overwrite the old files with the new ones as the arrive... not get
> >>> worked up about this. 0 effort required.
> >>>
> >>> or
> >>>
> >>> b) the following list of tasks must be completed.
> >>>
> >>> - new archive will be created at CADC called CFHTB4 (JO)
> >>>
> >>> - new top level e-transfer directory will be created on a CFHT
> >>> machine,
> >>> this will be the CFHTB4 archive e-transfer area. (CFHT who? HW?)
> >>>
> >>> - new detrended table at CADC will be created to accept the headers
> >>> of the new CFHTB4 archive. This is a duplicate of the current table
> >>> cfht..detrended and will be called cfht..detrended_b4 (IG)
> >>>
> >>> - The header ingestion script in the CFHT archive (CFHTHIngest.py)
> >>> will be modified to insert into the new 'detrended_b4' tables and
> >>> called (CFHTHIngestB4.py) [JJK]
> >>>
> >>> - a cfhtFileIngest script called cfhtFileIngestB4 will be created
> >>> which knows to call the CFHTIngestB4.py script instead [GM]
> >>>
> >>> - new instance of cfht etransfer will be configured at CADC to add a
> >>> new archive called CFHTB4. This script will call cfhtFileIngestB4
> >>> instead of cfhtFileIngest (GM?)
> >>>
> >>> - etransfer will be turned on and accept files for CFHTB4
> >>>
> >>>
> >>> -- Once the entire transfer is finished:
> >>>
> >>> - date to switch to B4 will be agreed on.
> >>> - announcement of date on the CFHT www pages and via CFHTLS list
> >>> will
> >>> occur. [JJK]
> >>> - some 'db magic' will be execute so that the CFHTB4 files replace
> >>> the CFHT files and the detrended_b4 entries replace the detrended
> >>> entries. [who ???]
> >>>
> >
>
>
> --
> Dr. David Schade
> Scientist and Group Leader
> Canadian Astronomy Data Centre
> Herzberg Institute of Astrophysics
> National Research Council Canada
Received on Tue Mar 11 2008 - 10:11:27 HST