Does this mean that the old preprocessing data is lost forever,
or is it backed up somewhere?
> 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
>
-----------------------------------------------------------------
Chris Pritchet pritchet at uvic.ca
Dept of Physics & Astronomy
http://www.astro.uvic.ca/~pritchet
University of Victoria
P.O. Box 3055 250-721-7744 (office)
Victoria, BC V8W 3P6 250-721-7715 (FAX)
CANADA
-----------------------------------------------------------------
Received on Tue Mar 11 2008 - 11:30:59 HST