March 19, 1998

PAW version 2.09/18

The PAW version 2.09/18 is part of the 98 release of CERNLIB. The source files, binaries and libraries are available, via anonymous ftp, on the asis system:

                       ftp asisftp.cern.ch

The PAW support is done by:

Olivier Couet.

Contributions from:

Vladimir Berezhnoi : COMIS
Nicole Cremel : KUIP

The PAW related packages versions are:

Package	Version	Date
PAW	2.09/18	19/03/98
KUIP	2.07/16	25/09/97
HBOOK	4.24/11	20/03/98
COMIS	1.20/05	11/03/98
HPLOT	5.20/06	01/11/95
HIGZ	1.24/03	27/01/98
SIGMA	1.10/03	10/02/94

The following subjects can be found in this page:

PAW

New routines callable from COMIS
Help improvements
Improvements
Bugs fixed
Alpha OSF specific bugs fixes
LINUX OSF specific bugs fixes

HBOOK

Improvements
Bugs fixed

COMIS

Improvements
Bugs fixed

HIGZ

Bugs fixed

KUIP

Improvements
Bugs fixed

ZEBRA

Bugs fixed

PAW

New routines callable from COMIS

FUNCTION IGIWTY(IWKID)
This function returns the workstation type of the workstation identified by IWKID .
FUNCTION HXE(ID,X)
Returns the error of channel corresponding to abscissa X of the 1D histogram ID.
SUBROUTINE IFA3(N,X,Y,Z)
Draw a 3D filled area.
Routines from mathlib/kernlib (see the cerresponfing manual(s)): DCAUCH, VMOD, VDIST, VDOTN2, VSUB, VUNIT, CHISIN, VDOT, VADD, VSCALE, CROSS, RANMAR, RANLUX, RNORML, RNORMX.

Help Improvements

Improvements

KUIP/UNITS has been replaced by FORTRAN/UNITS and is now able to list the HBOOK files again. Example:

PAW > unit
 +----+---------------------------------------+------------+-----------+------+
 | Lu | File name                             | Format     | Access    | Recl |
 +----+---------------------------------------+------------+-----------+------+
 | 10 | paw.metafile                          | FORMATTED  | SEQUENTIAL|      |
 +----+---------------------------------------+------------+-----------+------+
 |  1 | /disk3/couet/paw/bla.hbook            |            | DIRECT    |      |
 |  3 | /disk3/couet/paw/moenig.hbook         |            | DIRECT    |      |
 | 44 | /disk2/couet/cernlib/pawdemo.hbook    |            | DIRECT    |      |
 +----+---------------------------------------+------------+-----------+------+

When the command HISTO/FIT was used with option U , the following error message was printed:

 ***** ERROR in HPLOT : Option "Update" not available : ID=   12345

This didn't cause any problem but it looked bad.

There was a small inconvenience using include ? in a comis function. When a user ran two PAW sessions at the same time, both using include ?, then the comis.inc files generated in the /tmp directory could be mixed up.
In FUN/PLOT if the function to be plotted was a constant, the following error message was printed.

PAW >   FUNCTION/PLOT 2.0 0 1
 FILE WAS NOT OPEN
 2.0

but the function was plotted correctly.

In the HMERGE command, it was not possible to have file name containing "~" or system variables like:

PAW > hmerge ~/paw/out.hbook in1.hbook $HOME/paw/in2.hbook

Since PAW version 2.07, commands like:

PAW > fun/pl ~/paw/testfun.f(x) 0 10

didn't work. Until version 2.07, the functions parsing was done with the ntuple query processor. Since the new query processor has been released, the functions parsing is done by COMIS. In some cases (like this one), COMIS produced the following error:

PAW >  fun/pl ~/paw/testfun.f(x) 0 10
 CS-TR-ERR: routine _001, line    0
 FUNCTION _001(X,Y,Z) _001= ^ ~/PAW/TESTFUN(X)  #
#
  syntax error

In this particular example it is possible to do: fun/pl ~/paw/testfun.f 0 10.

Since this release, expressions containing special characters possibly ambiguous with operators (like '/') should be enclosed with '"'. The expression mentioned above becomes:

PAW > fun/pl "~/paw/testfun.f"(x) 0 10

Bugs fixed

fun/draw x**2+y**2-z didn't work. It gaves:

 CS-TR-ERR: routine _001, line    0
 FUNCTION _001(X,Y,Z) _001= ^ x**2+y**2-z  #                          
                                                                      
                    #
  syntax error

This was due to the fact that the functions parsing is now done by COMIS.

FUN/PLOT with log scale on X axis (OPTION LOGX) gaves the error:

call to missing routine _001
interpreter error -7 routine *MAIN*

This was due to the fact that the functions parsing is now done by COMIS.

During a Ntuple chain analysis with a COMIS function, in the common block

        COMMON /PAWCHN/ CHAIN, NCHEVT, ICHEVT

the variable ICHEVT did NOT contain the event-number within the current ntuple as it was the case in the 2.06 version. The value of ICHEVT carried the value 0 instead.

When the system functions $CUT and $CUTEXPAND were invoked with an undefined cut, PAW stoped with the following error:

PAW > MESS $CUT($10)
/KUIP/LAST: Assertion failed: cut_list[ cid ] != 0, file /afs/.cern.ch/asis/share/cern/97a/src/pawlib/paw/ntuple/qp_cuts.c,
line 104
Abort

~ in PI/PRINT"gif" file names produced:

PAW > pict/print ~/www/f2/jun20/mass.gif

*** Break *** Segmentation violation

TRACEQ. In-line trace-back still not available.

Alpha OSF specific bugs fixes

PAW crashed when a graphical cut on one variable only was used in the NT/PLOT command. Example:

PAW > GCUT $1 30.x
PAW > NT/PLOT 30.x $1
 *** Break *** Segmentation violation
 Traceq lun = 0, level = 99 

 TRACEQ.  In-line trace-back still not available.

The command nt/print gaves:

PAW > nt/print 1

 *** Break *** Segmentation violation

 TRACEQ.  In-line trace-back still not available.

[... these two lines are repeated several 100 times ...]

if ntuple 1 didn't exist.

LINUX specific bugs fixes

NT/SCAN was hanging on the prompt requested to stop or to continue.

HBOOK

Improvements

HREND: C I/O is now the default in HBOOK. HREND is now equivalent to the HRENDC routine introduced in the previous release. If FORTRAN I/O is required, HROPEN can be called with option "F" and the new routine HRENDF should be called to close the session. The HRENDC entry point has been kept for backward compatibility.

Note: on VMS machines C I/O doesn't work, so FORTRAN I/O is still the default.

Because long CWNtuples variables names were not handle correctly by HNTDUP, the following program produced:

                      ***** ERROR in HBNAME : Error in token : ID=       2


      Program CWN_LONGV
*
      Common /Pawc/ H(100000)
      Common /CWN/  RLONGNAME(1000)
*.___________________________________________
*
      Call Hlimit(100000)
*
      Call Hropen(1,'CWN','cwn.hbook','N',1024,Istat)
      If (Istat.Ne.0) Then
         Print*, 'Error in opening file ...'
         Stop
      Endif
*
      Call Hbnt(1,'CWN',' ')
      Call Hbname(1,'Block1',RLONGNAME,
     +'RLONGNAME(1000)[-100,-100]:R*4:18')
      Call Hntdup(1,2,-1,' ','A')
*
      Call Hrout(0,Icycle,' ')
      Call Hrend('CWN')
*
      end

HFNT: Clearer error message in case of NaN filling.

Bugs fixed

HDIFF problem:
In the comparison of two scatter plots, if OPT=F1 or OPT=F2 the Kolmogoroff probability could became very large. This problem has been fixed by Garry Levman (levman@physics.utoronto.ca).
The command HI/HIO/GRESET ID didn't work.
There was a mistake in the HBOOK floating points classify routine. Bug found by Julio Gonzalez (gonzalez@lal.in2p3.fr)
Bug fixed by Pierre Astier (astier@lpnax1.in2p3.fr):
"I experienced a crash (floating invalid) in HQPOIS called by HQUAD when running on a large ntuple. This was due to a division by zero which should not happen given the preprocessing done by HQBIN. HQBIN takes copies of links belonging to a link area (L1V,L1H,...) into local variables (LV,LH). Then in case of an ntuple, it scans the tuple. Finally it does some postprocessing using LV and LH to index the data. My crash was due to the fact that the tuple scan is causing some bank displacements, which are reflected in L1V,L1H ... but not in their local copies. As far as I know this is a very common trap when using ZEBRA. I fixed the problem and my crash disappeared."
If you fitted a histogram by a fortran function and then ADD this histogram with itself (ADD 1 1 2) you got an error. PAW was hanging. The following macro produced the problem:

v/cr p3(3) r 0 1 0 
v/cr a(10) r 1 3 2 5 4 8 6 10 7 9
1d 1 '' 10 0 10
put/con 1 a
h/fit 1 p2.f q 3 p3
add 1 1 2
h/pl 2

where p2.f is

      REAL FUNCTION P2(X)
      REAL X, PAR(3)
      COMMON /PAWPAR/PAR
*
      P2 = PAR(1) + PAR(2)*X + PAR(3)*X*X
*
      RETURN
      END

When filling a CWNtuple and using a 24 to 30 bit packing of a real, for each entry equal to the maximum value the value actually stored into the CWN was the minimum value. This only seems to happen with 24 to 30 bit packing. The following example demonstrate the problem:

      
       program test
*
       parameter (nlimit=10000)
       common /pawc/   hlim(nlimit)
       common /nspace/ xvar
*
       call hlimit(nlimit)
       call hropen(20,'out', 'out.hbook','N',1024,ier)
       call hbnt(1,'test', 'D')
       call hbname(1, 'blcka', xvar, 'xvar:r*4:24:[0.,10.]')
*
       do i = 0, 10
          xvar = float(i)
          call hfnt(1)
       enddo
*
       call hrout(1,icycle,' ')
       call hrend('out')
       close(20)
*
       end

COMIS

Improvements

Shared library access in now working on LINUX platforms.
Logical operators .EQV. and .NEQV. are now available.

Bugs fixed

The following routine didn't produced an error message (it should because the "THEN" statement is missing):

      subroutine bb(i)
      if (i.eq.1)
        print*, 'Hello 1'
      end if
      print*, ' After end if'
      end

This was due to the blank character between end and if at the 4th line of this small program.

When the COMIS memory was full, PAW crashed with the following error message:

*** Break *** Segmentation violation
( 0) 0x00252300 signal_handler + 0x1a0 [/cern/new/bin/pawX11]
( 1) 0xc01264d8 sigreturn [/lib/libc.sl]
( 2) 0x00134fe4 mdexp_ + 0x11c [/cern/new/bin/pawX11]
( 3) 0x00163cf8 mdlh_ + 0x228 [/cern/new/bin/pawX11]
( 4) 0x00135400 mhloc_ + 0x38 [/cern/new/bin/pawX11]
( 5) 0x0015bff4 csitli_ + 0x24 [/cern/new/bin/pawX11]
( 6) 0x0012c444 cstran_ + 0x1da4 [/cern/new/bin/pawX11]

The following COMIS program didn't worked:

        subroutine ess
        write(6,*) 'give x'
        read(5,*) x
        write(6,*) 'x is : ',x
        end

When it is called inside PAW it gaves:

PAW > call ess.f
 give x
1.e-2
 x is :   1.000000

HIGZ

Bugs fixed

The following macro ...

SET * ; SET *FON -40
FUN2 2 SIN(X)/X*COS(Y)*Y 40 -6 6 40 -6 6 ' '
H/PL 2 COLZ
SET LWID 8 ; SET PLCI 2
LINE -10 -10 10 10

... gaves the following output ...

... which was wrong because the red line should be clipped. The correct output is:

In the PostScipt markers drawing:

When the markers drawn were too for from the world coordinates, unvalid PS coordinates were generated.
In case all the points were outside the world coordinates the initialisation of the number of points to draw was missing.

In IGRAPH: Protection added against possible division by zero in the smooth curve drawing.
In IGGIF: protection added in case the output file (gif) cannot be open.
The delete option in the Window Manager top left button of the graphics window is disabled because it could stop an application using HIGZ.

KUIP

Improvements

The default value for the V/WRITE format was until now 5(1X,G13.7). This was not very convenient because the simple following set of commands crashes PAW. Moreover, the number of elements red back was wrong (10 instead of 6 in the following example). Entries 7 to 10 are not properly initialized and contain undefined values which make v/print crashes.

PAW > v/create x(6)
r 1 2 3 4 5 6
PAW > v/write x x.dat
PAW > v/read y x.dat
*** Unknown vector Y is created with length 10
PAW > v/print y
Y( 1) = 1
Y( 2) = 2
Y( 3) = 3
Y( 4) = 4
Y( 5) = 5
Y( 6) = 6
Y( 7) = 
*** Break *** Segmentation violation
( 0) 0x00252300 signal_handler + 0x1a0 [/cern/pro/bin/pawX11]
( 1) 0xc01264d8 sigreturn [/lib/libc.sl]
( 2) 0x00253688 strfromd + 0x4d0 [/cern/pro/bin/pawX11]
( 3) 0x00269c94 kxvprint + 0x534 [/cern/pro/bin/pawX11]
( 4) 0x00250924 kutim0_ + 0x9c [/cern/pro/bin/pawX11]
( 5) 0x00250a10 kutim0_ + 0x188 [/cern/pro/bin/pawX11]
( 6) 0x00250430 exec_decoded_cmd + 0x290 [/cern/pro/bin/pawX11]
( 7) 0x00250178 clean_word + 0x12f0 [/cern/pro/bin/pawX11]
( 8) 0x0024e170 exec_cmd_string + 0x858 [/cern/pro/bin/pawX11]
( 9) 0x0024dbe4 exec_cmd_string + 0x2cc [/cern/pro/bin/pawX11]
(10) 0x0024da4c exec_cmd_string + 0x134 [/cern/pro/bin/pawX11]
(11) 0x00266370 ku_shut + 0x258 [/cern/pro/bin/pawX11]
(12) 0x002660c0 ku_what + 0x38 [/cern/pro/bin/pawX11]
(13) 0x00262cb0 ku_whag + 0x30 [/cern/pro/bin/pawX11]
(14) 0x00262c58 kuwhag_ + 0x10 [/cern/pro/bin/pawX11]
(15) 0x0004b3e0 pamain_ + 0x50 [/cern/pro/bin/pawX11]

It was not possible to create more than 10 "kuipPalettes" (or "multi_panel"), even after closing some of them.
The possibility to "close" a palette with a command (instead of doing it interactively with the "Close" button in the "File" menu) has been implemented:

MULTI_PANEL <title> close

to close the palette which has been created with that <title> (N.B. Defaults title is "kuipPalette". If several palettes have been created with the same title all these palettes will be closed).

MULTI_PANEL last close

to close the "last palette" existing in the list.

The limitation for the number of vectors in the list VLIST in VECTOR/WRITE and VECTOR/READ has been increased to 30 (it was 10 before) and an error message is given when this limitation is reached.

Bugs fixed

The output in the command VECTOR/LIST was wrong. A side effect for Paw++ was that it stoped, keeping the cursor "busy" and preventing the user to continue the session.

The following macro shows the problem :

      
PAW >  ve/cre dumm1(5) i 0
PAW >  ve/cre dumm2(2,3) i 6*0
PAW >  ve/cre dumm3(2,3,4) i 24*0
PAW >  ve/list
 Vector Name        Type    Length    Dim-1    Dim-2   
  Dim-3

 DUMMI   
 DUMMI   
 DUMMI   

 Total of  3 Vector(s)

instead of:

      
PAW > ve/list
 Vector Name        Type Length    Dim-1    Dim-2    Dim-3

 DUMM1                 I      5        5   
 DUMM2                 I      6        2        3   
 DUMM3                 I     24        2        3        4

 Total of  3 Vector(s)

After answering "Q" to the WAIT command, the ability to issue several HISTOGRAM/PLOT statements on a single line, separated by semicolons, disappeared. Only the first HISTOGRAM/PLOT was executed from now on.

The following macro shows the problem:

Histogram/File 1 .../cernlib/paw/demo/pawhists.hbook
0 -X
zone 1 2; hi/pl 100; hi/pl 110
message type Q
wait
zone 1 2; hi/pl 100; hi/pl 110

In VECTOR/READ (free FORMAT) reading in a long vector with a free FORMAT failed if there was more than a certain number of characters per line.

The following macro shows the problem :

ve/cr x(12000)
ve/re x vec2bad.dat
* N.B. long lines with more than 50 tokens in vec2bad.dat
ve/print x(2000:2012)
ve/print x(7000:7012)
ve/print x(11000:12000)
*
return

with vec2bad.dat being the following line repeated 250 times:

01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 
02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 
03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 
04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 ...

ZEBRA

Bugs fixed

In RZCLOS:

The comparison between the name of the top directory to close (CHPATH) and the name(s) of the currently opened top directory (CHNAME) was wrong. Now CHPATH is converted is uppercase before being compared to CHNAME.
Improvements in the error message(s) output.

Temporary fix of RZDATE for years 2000-2016. This routine will fail again in 2017 (Jamie Shiers Jamie.Shiers@cern.ch).
ATLAS problems with cernlib 97a, with rfio/cio the record was not correct in RZIODO. Now RZFDIR.F rest the correct one. (Steve O'Neale Steve.O'Neale@cern.ch)