On Thu, 23 Oct 2008, David Berry wrote:
> 2008/10/23 Peter W. Draper <[log in to unmask]>:
>> On Wed, 22 Oct 2008, David Berry wrote:
>>
>>> 2008/10/22 Mark Taylor <[log in to unmask]>:
>>>> David and/or Peter,
>>>>
>>>> if I attempt to load the attached spectrum into SPLAT, I get the
>>>> following pop-up error:
>>>>
>>>> uk.ac.starlink.splat.util.SplatException: uk.ac.starlink.ast.AstException:
>>>> AST: Error at line 406 in file AstObject.c.
>>>> astMatch(SpecFrame): Inappropriate units (Hz) specified for a wavelength
>>>> axis.
>>>> Unable to accommodate the attribute setting "Digits(1)=17". (AST__BADUN)
>>>>
>>>> Naively eyeballing the headers it looks to me like this has frequency
>>>> in Hz in column 1 which I'd have thought would be OK. However, I
>>>> know practically nothing about spectrum FITS headers etc, so I expect
>>>> there's an error of some sort in the data. Can you comment on what's
>>>> wrong and how it might get fixed?
>>>
>>> Not sure what splat does with this sort of data. It's possible that it
>>> does not set a specific value for the SpecFrame's "System" attribute,
>>> in which case it would default to wavelength. Peter??
>>
>> That seems to be what's going on, the SpecFrame has a System of WAVE,
>> but has unit's of Hz, which is clearly wrong. I'll investigate further.
>>
>> I presume this is failing because the remapping within the frameset
>> isn't possible? But why is that needed when I'm just changing the
>> digits attribute?
>
> You could view it as AST taking the opportunity to check that the
> SpecFrame is self consistent. Whenever you change any current Frame
> attribute in a FrameSet, AST takes a copy of the current Frame,
> modifies the attribute, and then tries to determine a Mapping from the
> modified current Frame to the original current Frame.
>
> If you *really* want to circumvent this checking in the case of
> attributes like Digits, which you know has no effect on the Mapping,
> then you should use astGetFrame to get a pointer to the Frame, and
> then use this Frame pointer rather than the FrameSet pointer when
> setting the new attribute value. But assigning an appropriate value
> for the SpecFrame's System attribute would seem a much better
> solution.
Agreed, but the problem seems to come down to the old issue of verifying
that the system and units of a SpecFrame are consistent. Nothing seems to
work anymore, like trying to find a SpecFrame (what I seem to do), or
reconstructing a SpecFrame with the full attributes (like in DIPSO:rdndf.f):
% atools
% astspecframe options='"system=wave,unit=Hz"' result=specframe.ast
Got a good way to check that a SpecFrame is valid?
Peter.
|