On Tue, 24 Jun 2008, David Berry wrote:
> 2008/6/23 Tim Jenness <[log in to unmask]>:
>> Thanks. We probably shouldn't propagate EXTENSIONS from the first
>> (especially a SMURF extension that will have an incorrectly sized EXP_TIME
>> etc).
>
> Are you saying we should propagate them from the reference NDF, or
> that we shouldn't propagate them at all? I'm a bit twitchy that we
> seem to be modifying standard kappa behaviour (which is to propagate
> extensions form the primary input NDF). Could the pipe-line not simply
> use kappa:erase to erase the extension from the output after wcsmosaic
> has run?
In the particular case of wcsmosaic, I'm saying that it's doubtful that
the extensions from the first input file are at all relevant in the mosaic
output (if there is more than one input file). SMURF extensions are just
an example.
Noting that until yesterday, extensions would have been propagated from
the REF image (also highly dubious).
Extension propagation makes most sense for a single input going to a
single output.
> We seem to be moving away from kappa being a completely general
> purpose package which makes as few assumptions as possible about what
> it is being used to do. Just because an application maps the
> DATA_ARRAY of an existing NDF does not necessarily mean that the NDF
> contains photon data - it may contain an instrumental response, or
> some other transfer function, or almost anything really. Are then any
> alternative approaches which would maintain the generality of the
> current provenance system (i.e. a system which simply records which
> NDFs were used as inputs)? I can think of at least two alternative
> approaches: 1) use PROVREM after wcsmosaic to remove the unwanted
> reference provenance (this would need a slight change to provrem), or
> 2) before running wcsmosaic, set a flag in the provenance extension of
> the reference NDF that tells NDG not to include the NDF in the output
> provenance (this would need a new task to control the setting of the
> flag, or it could be done within provmod).
>
> The old model was that kappa was as general purpose as possible, and
> all the tuning to handle details of
> instrument/telescope/observatory/wavelength/science/etc went in the
> pipe-line. Now that the SSC is being maintained specifically to
> support JAC operations, I can see there could be an argument to change
> this.
In the pipeline case we can always check the output provenance to see
whether it makes sense and handle it on a case by case basis. Don't worry
about it at the moment.
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|