2008/10/23 Peter W. Draper <[log in to unmask]>:
> 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.
>
When you say "Nothing seems to work anymore," do you mean that you've
seen some change in behaviour? If so, what and when?
One way of testing for bad units/system is the following:
AstFrame *f1 = astCopy( specframe );
astClear( f1, "Unit" );
if( astOK ) {
AstFrameSet *fs = astConvert( f1, specframe, "" );
if( astStatus == AST__BADUN ) {
bad units!!!
}
}
David
|