[quote=“Pepe Le Pew”]Well, maybe one could try to use a negative value (it will completely “reset” ZEBRA?), but I’m not really sure that even in this case you are allowed to call it multiple times (and I’m not sure that the very first call can use a negative value):
call hlimit(-NWPAWC)
Who was responsible for HBOOK? Rene? Fons?[/quote]
Thanks for the reply!
I have tried using call hlimit(-NWPAWC) in “subroutine dswntuplebook”, it shows “segmentation fault”.
In dswhbook.f , the “call hlimit(-NWPAWC)” is used once for “subroutine dswhbook”, another once for “subroutine dswntuplebook”. These two subroutines won’t be called at same time, so I guess " hlimit(NWPAWC)" wasn’t called multiple times.
I have tried to add “call hcdir(’//HISTOS’,’ ')” before “hbookn(300…” , “hfn(300…”,“hrout(300…”; however,
there is no use.
It seems to me that “dswntuplebook” (and so also “hlimit”) will be called multiple times from inside of “dswntuplefill” (every “batchlimit” events).
Looking at the “dswntuplefill”, it seems to fill the ntuple with one event, and I see no “loop” over all events. Are you sure that after the very last event (i.e. after the very last call to “dswntuplefill”) you also call “NTfinalize” (which I think is responsible for closing the very last file)?
BTW. I think, in the “dswntuplebook” you should move the “call hlimit(NWPAWC)” up to inside of “if (first) then … endif” (so that it’s executed only once).
[quote=“Pepe Le Pew”]It seems to me that “dswntuplebook” (and so also “hlimit”) will be called multiple times from inside of “dswntuplefill” (every “batchlimit” events).
Looking at the “dswntuplefill”, it seems to fill the ntuple with one event, and I see no “loop” over all events. Are you sure that after the very last event (i.e. after the very last call to “dswntuplefill”) you also call “NTfinalize” (which I think is responsible for closing the very last file)?
BTW. I think, in the “dswntuplebook” you should move the “call hlimit(NWPAWC)” up to inside of “if (first) then … endif” (so that it’s executed only once).[/quote]
Thanks for the reply!
I tried to move the “call hlimit(NWPAWC)” up to inside of “if (first) then … endif” (so that it’s executed only once). but it doesn’t work.
I attached the nplotter_generic.f file(when choose creatent=.true., it calls bookfill) and mcfm_exit.f(it calls NTfinalize )
Actually I used mcfm package 2 years ago and met no problem when booking ntuple and using h2root to transfer it . So I guess there should be no problem with dswhbook.f since it is such an old file. Nevertheless, the *.rz files looks so strange this time. Even though I got some converted root file after I changed batchlimit to 200, when I read the values in root file, I found them abnormal, there is something like 10^30 appears. mcfm_exit.f (6.96 KB) nplotter_generic.f (44.9 KB)
Check if you can open your files with PAW, as Olivier suggests (if you have cernlib, you should also have PAW).
What system (e.g. 32-bit or 64-bit) / compiler / cernlib version were you using 2 years ago versus what you use now?
BTW. Do you use static cernlib libraries now?
[quote=“Pepe Le Pew”]Check if you can open your files with PAW, as Olivier suggests (if you have cernlib, you should also have PAW).
What system (e.g. 32-bit or 64-bit) / compiler / cernlib version were you using 2 years ago versus what you use now?
BTW. Do you use static cernlib libraries now?[/quote]
I use 64-bit system/ gfortran /cernlib/2006 now.
Two years ago I also used 64-bit system/ gfortran two years ago, but the cernlib is a little different, it is cernlib/2006-g77.
I am using static cernlib library now; while I used dynamic cernlib 2 years ago.
If I use dynamic cernlib, I will get the following error information,
LOCB/LOCF: address 0x7f1b45d57dc0 exceeds the 32 bit address space
or is not in the data segments
This may result in program crash or incorrect results
Therefore we will stop here
Could you tell me the command that how to open the *.rz file in the paw?
I reinstalled the cernlib and now have PAW. But I am sorry I forgot the command.
That’s is just a warning. It tells you Exchange mode is used. h2root does the same. Can you then access the ntuple you have in that file ? the data in that ntuple are correct ? can you scan it ? plot it ?
[quote=“Pepe Le Pew”]I don’t really think you can use a “g77-cernlib” with gfortran (especially on a 64 bit system).
Many new Linux distributions offer “native” CERNLIB 2006 binary packages and you should try to use them in the first place.
If it fails, try the attached CERNLIB 2005 (64 bit) procedure.[/quote]
I installed cernlib 2005, and got “Error” information while read the log file under build/log directory. What is wrong with the cernlib installation? Thanks for any help.
My system is Fedora 19. gfortran version is 4.8.3. 64-bit machine
PAW > NT/Print 300
/NTUPLE/PRINT: ID 300: Bad header. Try command RECOVER
PAW > NTU/RECOV 300
HRECOV: 99855 entries correctly recovered
RZOUT . No authorisation to write in that directory
(//LUN1)
***** ERROR in HRZOUT : An error has occured whilst writing data : ID= 3
***** ERROR in HROUT : Problems with file : ID= 300
I think you get these “make_patchy5” and “t_lapack” errors because making of “cernlib” failed earlier.
Typically the problem is that some of required utilities and/or development files are missing.
If you provide me with a copy of all “2005/build/log/*” files (e.g. create a “.tar.gz”) then I can have a look at them.
What’s often missing:
gmake -> gmake … or … sudo ln -s which make /usr/bin/gmake
imake -> imake or xutils-dev
/usr/include/X11/StringDefs.h -> libXt-devel or libxt-dev
/usr/include/Xm/Xm.h -> openmotif-devel or libmotif-dev or lesstif-devel libgmp.so -> gmp-devel or libgmp3-dev
/bin/tcsh -> tcsh
gfortran -> gcc-gfortran
ed -> ed
I still met problem, the installation is always stuck while "installing the old patchy 4 " shown as following,
even after 3 hours without progress.
In its log file patchy.0114, the last sentence is "rm: remove regular file rceta.f?"
It seems it waits for answer
./Install_cernlib_and_lapack
====================
CERNLIB installation
installing cernlib sources
Checking for Fortran Compiler… gfortran
Configuration summary
Architecture is: x86_64
Fortran compiler used: gfortran
CERN_LEVEL is: 2005
installing cernlib libraries
gmake: `scripts/Makefile’ is up to date.
installing lapack and blas libraries
testing cernlib libraries
installing cernlib executables
installing the old patchy 4 executables
Can it be that you have an alias for “rm” (e.g. rm=‘rm -i’)?
If yes, you need to get rid of it (check also another aliases that may create problems like cp=‘cp -i’ and mv=‘mv -i’).
Note: after you installed any missing utilities or development files, the best idea is to delete the whole source code and start the downloading, unpacking and building procedure completely from scratch again.
Finally I got cernlib 2005 installed correctly.
However, the crash in *rz file still exists. I could use PAW to recover it and then transfer to *.root.
So, PAW detects that the rz file generated by your program is mal-formed. PAW offers the RECOVER command to make it correct. Your file is incorrect to start with … no chance h2root can use it … make sure your program generates a correct rz file and h2root will be able to digest it.