[daip] (no subject)

[Eric Greisen]

Marcin Hajduk writes:
First - please select some subject that is obviously about aips -
blank subjects get deleted along with almost all other e-mail
(actually spams) we receive.  I got lucky and spotted yours as
legitimate.

 > my name is Marcin Hajduk. I am a PhD student in astronomy. I am attempting
 > to install aips on my computer (red hat linux). I downloaded the lastest
 > version of aips (31DEC04). When I am trying to run aips, a statement appear:
 > 
 > STARTPMON: [ORION] Starting TPMON1 with output SUPPRESSED
 > ZVTPO3: tcp/aipsmt0 is not a service
 > ZVTPO3: check /etc/services or NIS map!
 > 
 > and a longer one in the message window:
 > 
 > ORION > TPMON1: Begins on 2004.10.11 21:00:34
 > ORION > TPMON1: ZVTPRO: CHANNEL ASSIGN ERROR FOR REMOTE TAPE LUN   16
 > ORION > TPMON1: Unable to create socket.  ZVTPRO error     6
 > ORION > TPMON1: Purports to die of UNNATURAL CAUSE number      6
 > ORION > TPMON1: orion        31DEC04 TST: Cpu=       0.0  Real=       0
 > ORION > TPMON1: Begins on 2004.10.11 21:01:22
 > ORION > TPMON1: ZVTPRO: CHANNEL ASSIGN ERROR FOR REMOTE TAPE LUN   16
 > ORION > TPMON1: Unable to create socket.  ZVTPRO error     6
 > ORION > TPMON1: Purports to die of UNNATURAL CAUSE number      6
 > ORION > TPMON1: orion        31DEC04 TST: Cpu=       0.0  Real=       0
 > 
 > What should I change in /etc/services to run aips properly?

This is addressed in

http://www.aoc.nrao.edu/aips/aipsmgr/index.html

the aips manager faq.
 > 
 > Another problem is that when I am trying to read in radio VLA data using
 > FILLM procedure, the procedure 'adds' 1 in the end of the filename. If the
 > filename is (for example) '1711', the procedure looks for a file named
 > '17111'. Even if the procedure looks for a proper filename, it can not read
 > the data. I will be grateful for any advices and help.
 > 
 > 
 > Marcin
 > 
 > 
 > (this is what I see in the message window during attempting to read in the
 > file with radio data data)
 > 
 > ORION > FILLM1: Task FILLM  (release of 31DEC04) begins
 > ORION > FILLM1: UV data will be written in compressed format
 > ORION > FILLM1: Shadow flag limit =  2.500E+01 meters.
 > ORION > FILLM1: Opacity correction in CL table weighted average of weather and
 > ORION > FILLM1:    season.  Weight for weather = 0.50
 > ORION > FILLM1: Gain curve correction in CL table read from file,
 > ORION > FILLM1:    with variation as function of antenna and band.
 > ORION > FILLM1: Opening MYAREA:1711
 > ORION > FILLM1: FLDKIO: LBYTES=    5440 BUT IERR = 0
 > ORION > FILLM1: Opening MYAREA:1712
 > ORION > FILLM1: ZTPOPN: DISK DEVICE = MYAREA:1712 NOT FOUND
 > ORION > FILLM1: FLDKIO: ERROR   2 OPENING FILE
 > ORION > FILLM1: MCRECO: ERROR    8 OPENING DISK FILE    2
 > ORION > FILLM1: No data found meeting selection criteria!
 > ORION > FILLM1: Read         0 visibilities from  1 files
 > ORION > FILLM1: Appears to have ended successfully
 > ORION > FILLM1: orion        31DEC04 TST: Cpu=       0.0  Real=       0

If you read the help file in FILLM for INFILE you will see that it
requires disk file names ending in the pseudo-tape file numbers, e.g.
1, 2, 3, 4, 5, etc. where the starting number is set by the NFILES
adverb (0 -> 1, 1 -> 2, etc).  You have told FILLM to read more than
one file, but the second one (1712) does not exist.

There is also an error at the start of the first file which must be
very small and contain no data.  I assume that the file is only 5440
bytes in length.  When FILLM reads it must find a file that is N*2048
bytes and will attempt to find data in consecutive records of this
length until the end.  I do not know how you acquired the file 1711
but it seems in error.  When using ftp be sure to make sure that
binary transfers are used - in text mode the contents can be changed
in a way that is erroneous for floating-point data.

Perhaps I could help more if I knew more...

Eric Greisen