[daip] reading wmap in aips

[Farhad Zadeh]

Hi Eric,
I finally got a hold of WMAP images with  format that aips can read.
There are found images in a cube in Molleweide geometry. When I read a 
cube 
file, the fits header in aips looks like this.
>imh
AIPS 1: Image=NONE      (MA)         Filename=WMAP_W_7YR  .TEMPER.   1
AIPS 1: Telescope=WMAP               Receiver=
AIPS 1: Observer=                    User #=  134
AIPS 1: Observ. date=BAD DATE        Map date=02-JUN-2010
AIPS 1: Minimum=-5.25645196E-01      Maximum= 6.03604813E+01
AIPS 1: ----------------------------------------------------------------
AIPS 1: Type    Pixels   Coord value     at Pixel     Coord incr   Rotat
AIPS 1:           4096   0.0000000E+00       0.00  1.0000000E+00    0.00
AIPS 1:           2048   0.0000000E+00       0.00  1.0000000E+00    0.00
AIPS 1: ----------------------------------------------------------------
AIPS 1: Maximum version number of extension files of type HI is   1
>
Suspended

I tried using ctype1 and do puth but wouldn't take it.
Any advice?
Thanks.
Farhad



On Tue, 25 May 2010, Eric Greisen wrote:

> Farhad Zadeh wrote:
>> Hi Eric,
>> I am now trying to load the 7-yr WMAP maps and I am having the
>> block size difficulty.
>> 
>> ownes> IMLOD1: Reading from disk file: 
>> PWD:wmap_band_iqumap_r9_7yr_W_v4.fits
>> townes> IMLOD1: Create IMLOD       .TEMP  .   1 (MA)  on disk  5  cno    1
>> townes> IMLOD1: TAPIO: RECORD LENGTH   1475 INCONSISTENT WITH BLOCK SIZE 
>> 2880
>> townes> IMLOD1: Destroyed  1 extension files of type UK
>> townes> IMLOD1: Destroyed  1 extension files of type HI
>> townes> IMLOD1: Destroyed MA image file: catno=      1 disk= 5
>> townes> IMLOD1: Purports to die of UNNATURAL causes
>> townes> IMLOD1: townes 31DEC09 TST: Cpu=      0.1  Real=      1  IO= 
>> 2
>> 
>> Any advice would be greatly appreciated.
>
> Look at your file on disk with ls -l and try dividing its length by 2880.  It 
> should be an integer and the above message suggests that it is not.  How it 
> got tnhat way is of course unclear - one way would be an ftp where the word 
> "binary" was not issued.  Some ftps will insert line-feed characters whenever 
> they see and carriage-return character assuming that the whole file is 
> characters which it is not.  This makes the file grow in size. 
> Alternatively, some copy failed or the FITS writer is defective.
>
> Eric
>