[WP3] swarp problem

[Jan Snigula]

>
> Hmmm, exactly how close is "closest"? .)
> My opinion is that bugzilla requires too much maintenance, but if you volunteer
> to host it, that argument disappears. I'd even say that if someone other than
> me installs and maintains it, I wouldn't care too much about usability. [)
> I think that Mike had a look at bugzilla in the past and he might give some
> comments on bugzilla.
> In any case, if you can have a seriously look at installing and using bugzilla
> and give your opinion we can consider using it here as the central bugtracking
> system.
>

I'll look into that ;)

>
> > > > I ran into a major problem with RegriddedFrame, make() fails at
> > > >
> > > > self.astrom = translator.translate_astrometric_keys(self)
> > > >
> > > > and in translate_astrometric_keys(self)
> > > >
> > > > chip_id = self.retrieve_id_from_header(frame, self.chip_id_keys)
> > > >
> > > > returns None, a quick look into the header of the offending file, it seems
> > > > that swarp (2.10) nicely cleaned up the header and removed all ESO
> > > > HIERARCH and CHIP_ID.
> > > >
> > > > Is there a workaround for that problem?
> > >
> > > Are you running things without the database?
> > > In any case the RegriddedFrame should have all keywords properly set after
> > > regridding. If this is not the case it should be fixed.
> > >
> >
> > I found a solution, swarp config needs CHIP_ID with the COPY_KEYWORDS
> > config option, I'm just not sure if it should go into Swarp.py or
> > RegriddedFrame.py, otherwise I would commit it directly
>
> Just for completeness, are you referring to the AWBASE version or the most
> up-to-date version?
> When you look at RegriddededFrame you'll see that the persistent `chip'
> attribute is missing!
> The proper fix is to add the `chip' attribute to RegriddedFrame and the
> following line to RegriddedFrame.make():
>
>            self.chip = self.science_frame.chip
>
> You can probably test this already without adding the `chip' attribute.
> Let me know if that is correct. It looks like that the next step will
> be to do some type evolution in a synchronized way within AWBASE soon.
> In that case we'll have to coordinate together when we do that.
>

I'm using the up-to-date version, and the missing chip attribute is
definitly a problem of its own, yet the problem I described came from the
missing COPY_KEYWORDS option to swarp, as the HeaderTranslator doesn't
know about the chip keyword, but tries to get the information from the
header itself.

Jan