wxie | 31 Oct 16:23 2014
Picon

launch problem of v5.34/21

v5.34/21 can not be launched. I'm using Window VC++10 Release tar 
files.  I have no problem with the v5.34/20.

Thanks
--Wei

Lynn Garren | 31 Oct 16:17 2014

5.34.23

Is there an eta for ROOT 5.34.23 yet?

Lynn

Stilianos Kesisoglou | 31 Oct 15:13 2014
Picon
Picon

Default color of the mesh lines when a TF2 is ploted in ROOT 5.34.21

Hi all,

When I plot a TF2 function under ROOT 5.34.21 with the "surf" option
the mesh lines are drawn in red color. For example here:

   TCanvas *c2  = new TCanvas("c2","c2",0,0,600,400);
   TF2 *f2 = new TF2("f2","0.1+(1-(x-2)*(x-2))*(1-(y-2)*(y-2))",1,3,1,3);
   f2->Draw("surf");

I have no ROOT configuration file, and I was under the impression that
the default color for the mesh lines was black.

Has been changed by default? Any setting for the ROOT file to set it back
to normal black.

Thanks!
Stelios.

Elena Graverini | 30 Oct 17:50 2014
Picon
Picon

Re: Error R__unzip_header in HADDed rootfiles

Dear Paul,

thanks for your answer.

I actually used the hadd application to join the files.

I made a lot of tests, changing the version of root (and therefore of the hadd program) and so, but the only thing that worked for me was to split in two parts the list of files to hadd together.
I had about 900 files originally, so I ended up "hadding" about 450 first and then the other 450, and then the problem vanished.

I guess "hadd" has some weird behaviour when it handles too many files.
Is there a way to understand when a set of files are "too many" to be hadded directly?

Cheers,

Elena

2014-10-30 17:18 GMT+01:00 Dr P J Davies <paul.davies <at> york.ac.uk>:
Hi Elena, this sounds like there many be a problem when closing the file. Perhaps you could send the script you use to hadd everything together. 

Alternatively, the hadd application is now provided as a compiled program with root. You could try using this:

hadd outputfile.root inputfiles.root

the input files can be a list or it also takes wildcards so you can easily list all files you’d like to add. 

This process has worked quite well for me in the past.

Cheers, Paul


-- 
Dr P J Davies, Nuclear Physics Group, Department of Physics, 
University of York, Heslington, York, Tel: +44 (0)1904 432245.


On 29 October 2014 at 11:25:18, Elena Graverini (elena.graverini <at> cern.ch) wrote:

Dear experts,

often I need to hadd together bunches of few hundreds ROOT files containing histograms. All those files were generated from LCG jobs. The jobs were executed at different locations on the LCG grid, but with the same version of the LHCb software (that should provide a defined version of ROOT).

I use the following protection when I loop over all the input rootfiles:

f = r.TFile(filePath, 'read')
if f:
    if not f.IsZombie():
        #hadd file...

This saves me from a lot of possible errors. In addition, I always try to make sure that the same version of ROOT is used during the production and the HADDing of those rootfiles, by setting up the same LHCb software version before each operation.

However, sometimes the whole process results in:

root [3] TBrowser t
root [4] Error R__unzip_header: error in header
Error R__unzip_header: error in header

when I open the merged rootfile and try to browse its histograms. This happens even when the hadding process doesn't produce any error/warning.
I tried to recover the merged file with

root [17] _file0->Recover()
Info in <TFile::Recover>: STTrackMonitor-2012-MagDown.root, recovered key TDirectoryFile:DaVinciInitAlg.DaVinciMemory at address 460
Info in <TFile::Recover>: STTrackMonitor-2012-MagDown.root, recovered key TDirectoryFile:ChargedParticlesToTracks at address 11225
Info in <TFile::Recover>: STTrackMonitor-2012-MagDown.root, recovered key TDirectoryFile:Track at address 12306
(Int_t)3

But this only turns the preceding error into

root [6] R__unzip: error -3 in inflate (zlib)
R__unzip: error -3 in inflate (zlib)

when I try to open the desired histograms.

Is it possible that a rootfile that passes the IsZombie() check is still corrupted in some way? How can I overcome this problem? How can I skip further "bad" input files?
I can't see any other option, at the moment, other that regenerating all the 900 input files on the grid and hoping for better luck, but this can't be the only way to get a working merged rootfile...
Can you suggest me something?
Thanks in advance for your help.

Cheers,

    Elena

Sonal Ambwani | 29 Oct 16:30 2014

Re: unsubscribe

Unsubscribe.

On Mon, Oct 27, 2014 at 5:34 AM, Алдияр Юрьевич Оралбаев <oralbaev <at> physics.msu.ru> wrote:
unsubscribe

Alberto Lusiani | 29 Oct 13:01 2014
Picon
Picon

Root 5.34 spec file does not work on Centos 6 for me

I tried to compile Rott 5.34.21 on Centos 6 (should be equivalent to Redhat 6 and Scientific Linux 6, up to date as of today, actual release 6.5)​ using the provided .spec file, and I have got this error:

====

> tar xvzf ../../SOURCES/root_v5.34.21.source.tar.gz

> cd root/

./configure linux

> make redhat

> cp root.spec ../../../SPECS/

> cd ../../../SPECS/

> rpmbuild -ba root.spec 

[...]
+ ./configure --enable-cintex --disable-clarens --enable-explicitlink --enable-gdml --enable-gsl-shared --disable-fftw3 --enable-ldap --disable-qt --disable-qtgsi --enable-mathcore --enable-mathmore --enable-minuit2 --enable-mysql --disable-peac --enable-pgsql --enable-odbc --enable-reflex --enable-roofit --enable-ruby --enable-shadowpw --enable-shared --enable-soversion --enable-table --disable-rpath --disable-afs --disable-srp --enable-builtin-ftgl --disable-builtin-freetype --disable-builtin-pcre --disable-builtin-zlib --disable-alien --disable-chirp --disable-dcache --disable-g4root --disable-gfal --disable-globus --disable-monalisa --disable-oracle --disable-pythia6 --disable-rfio --fail-on-missing --enable-unuran --enable-xrootd --disable-sapdb --enable-cern --prefix=/usr --libdir=/usr/lib/root/5.34 --mandir=/usr/share/man/man1 --docdir=/usr/share/doc/root-5.34.21 --cintincdir=/usr/lib/root/5.34 --etcdir=/etc/root --with-sys-iconpath=/usr/share/pixmaps

Checking for source directory ... /home/lusiani/local/src/RPM/BUILD/root

Configuring for linux

INFO: --enable-cintex: already enabled by default.

Invalid option '--disable-clarens'. Try ./configure --help

error: Bad exit status from /var/tmp/rpm-tmp.WRDi8z (%build)

====

This is just to let you know that this documented way of building Root fails.

I have worked out a working .spec file, for installing Root versions in a dedicated directory in /opt, the related .nosrc file is here:

https://sites.google.com/site/alusiani/software/root/rootpkg-5.34.21-alu.co6.1.nosrc.rpm?attredirects=0​


Elena Graverini | 29 Oct 12:24 2014
Picon
Picon

Error R__unzip_header in HADDed rootfiles

Dear experts,

often I need to hadd together bunches of few hundreds ROOT files containing histograms. All those files were generated from LCG jobs. The jobs were executed at different locations on the LCG grid, but with the same version of the LHCb software (that should provide a defined version of ROOT).

I use the following protection when I loop over all the input rootfiles:

f = r.TFile(filePath, 'read')
if f:
    if not f.IsZombie():
        #hadd file...

This saves me from a lot of possible errors. In addition, I always try to make sure that the same version of ROOT is used during the production and the HADDing of those rootfiles, by setting up the same LHCb software version before each operation.

However, sometimes the whole process results in:

root [3] TBrowser t
root [4] Error R__unzip_header: error in header
Error R__unzip_header: error in header

when I open the merged rootfile and try to browse its histograms. This happens even when the hadding process doesn't produce any error/warning.
I tried to recover the merged file with

root [17] _file0->Recover()
Info in <TFile::Recover>: STTrackMonitor-2012-MagDown.root, recovered key TDirectoryFile:DaVinciInitAlg.DaVinciMemory at address 460
Info in <TFile::Recover>: STTrackMonitor-2012-MagDown.root, recovered key TDirectoryFile:ChargedParticlesToTracks at address 11225
Info in <TFile::Recover>: STTrackMonitor-2012-MagDown.root, recovered key TDirectoryFile:Track at address 12306
(Int_t)3

But this only turns the preceding error into

root [6] R__unzip: error -3 in inflate (zlib)
R__unzip: error -3 in inflate (zlib)

when I try to open the desired histograms.

Is it possible that a rootfile that passes the IsZombie() check is still corrupted in some way? How can I overcome this problem? How can I skip further "bad" input files?
I can't see any other option, at the moment, other that regenerating all the 900 input files on the grid and hoping for better luck, but this can't be the only way to get a working merged rootfile...
Can you suggest me something?
Thanks in advance for your help.

Cheers,

    Elena
Picon
Picon

Random number following Landau distribution

Good afternoon,
I want to produce a random number following the Landau distribution with the the prerequisite that the nr
does not exceed a predifined cut value.

my idea so far is to produce the landau distribution and apply a cut at the value of interest.
Is this way correct or I could do it also another way round?
Thanks,
E.Chaniotakis
Attachment (land.c): application/octet-stream, 337 bytes
Erkcan Ozcan | 24 Oct 18:52 2014
Picon
Picon

Question about win64gcc

Hi,

I am aware of the statement on the download page about the root team not responding to any messages relating to cygwin+root. However, the supported architectures page still list win32gcc and win64gcc. (http://root.cern.ch/drupal/content/supported-architectures) Taking some courage from that I wanted to ask a question, with the hope that perhaps other roottalk members can help.

We are trying to install ROOT from source on a windows 7 machine. We have cygwin64, gcc-4.8.3. ./configure win64gcc works fine but compilation fails at some point with an error about reflex. (See the beginning of the error message at the end of this post.) To overcome this problem, we decided to --disable-reflex, as was suggested in the following post: http://root.cern.ch/phpBB3/viewtopic.php?f=3&t=18482

And we got the very same error in that post, the one that relates to libRIO.dll. :-( Is there a configure option to disable that part as well?

So here is my more concrete question: Given that win64gcc is a ./configure architecture, at some point in time a certain version of ROOT must have worked on it. Could we at least learn which version of ROOT was the last working version on this architecture? We can at least consider installing that version as a worst case scenario.

Thanks a lot,
e.


-----
PS: Why do we want to use cygwin? We have a large project with many makefiles+softlinks+bash scripts and everything runs smoothly on both linux and mac osx. We recently got some students who are forced to use windows and cygwin works perfectly in cases like this. If there is a makefile example that runs on msys, or cygwin, etc. but makes use of the visual studio compilers and VS version of ROOT, we would welcome this as an excellent solution as well. We are really trying to avoid reinventing everything to run through the VS gui and/or cmake, as this will mean further work in not only setting things up, but also in maintaining them.

-----
Addendum 1: Error message related to reflex:
/home/virtualme/work/root/build/unix/wingcc_ld.sh -shared -Wl,--export-all-symbols -Wl,--enable-auto-image-base -Wl,-soname=libReflexDict.dll -O2 -Wl,--enable-auto-import -Wl,--enable-runtime-pseudo-reloc -L/usr/lib/X11 -o lib/libReflexDict.dll cint/reflex/src/G__Reflex.o -Llib -lCore -lCint
/home/virtualme/work/root/cint/reflex/Module.mk:139: recipe for target 'lib/libReflexDict.dll' failed
/home/virtualme/work/root/build/unix/wingcc_ld.sh -shared -Wl,--export-all-symbols -Wl,--enable-auto-image-base -Wl,-soname=libReflexDict.dll -O2 -Wl,--enable-auto-import -Wl,--enable-runtime-pseudo-reloc -L/usr/lib/X11 -o lib/libReflexDict.dll cint/reflex/src/G__Reflex.o -Llib -lCore -lCint
cint/reflex/src/G__Reflex.o:G__Reflex.cxx:(.text+0x60ee): undefined reference to `Reflex::Instance::Instance()'
cint/reflex/src/G__Reflex.o:G__Reflex.cxx:(.text+0x60ee): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `Reflex::Instance::Instance()'



-- 

In case they are not written explicitly, please be aware that my greetings and farewell are inherently implied in this email. If you have emailed me and did not get a quick response, please accept by apologies and resend, as I parse through more than 200 non-spam emails per day.

V. Erkcan Özcan, PhD
Associate Professor
Bogazici University
Department of Physics

Marcos Fernandez Garcia | 24 Oct 15:15 2014
Picon
Picon

TH2 zoom differences (ROOT 5.32 vs 5.34) in command draw

Hi

I have a strange 2D histo drawing behavior in

ROOT 5.34/09 (v5-34-09 <at> v5-34-09, Jun 26 2013, 17:10:36 on linux)

compared to

ROOT 5.32/00 (tags/v5-32-00 <at> 42375, Dec 02 2011, 12:42:25 on linux)

The code:

TH2F *h2 = new TH2F("h2","h2",10,-1,1,10,-1,1);
h2->FillRandom("gaus",100000)
h2->Draw("colz")

When I zoom-in near the first bin in 5.32 the X axis stops at -1 (top drawing in the attachment)
When I zoom-in in version 5.34 it shows a white bin (bottom drawing) and it looks as if the histogram has been
booked and filled  differently, which is misleading

Is this behavior (5.34) something I can avoid?
Manoj Kumar Jha | 24 Oct 01:26 2014
Picon
Picon

Reading different branches using MakeSelector

Hello,
    I have  a root file which consists of a single tree ("T") and four 
different branches.  I am using the utility 
'T->MakeSelector("MyClass")'  to read the input file.  I am able to read 
one branch correctly which can be judged from the amount of data read by 
PROOFlite (~ 37 MB).  Size of each branch  is around 37 MB.   The amount 
of data read from proofserve daemon  for two branches is  same as when I 
read one branch.   It means the analysis code is not reading two 
branches separately.   My analysis code can be found in the folder

/afs/cern.ch/user/j/jha/public/CMS/Proof/SameBranches

Number of read branches can be controlled using the variable 'icase'  
(line number 41: MyClass.C)

How to run the code:
"""
cp -r  /afs/cern.ch/user/j/jha/public/CMS/Proof/SameBranches /tmp

cd /tmp/SameBranches

#Setup root
source 
/afs/cern.ch/sw/lcg/app/releases/ROOT/5.34.18/x86_64-slc6-gcc48-dbg/root/bin/thisroot.sh
source /afs/cern.ch/sw/lcg/external/gcc/4.8/x86_64-slc6-gcc48-opt/setup.sh

root -b
.x Analysic.C

"""

Thanks,
Manoj

--

-- 
------------------------------------------------------------------
Manoj Kumar Jha                    Department of Physics
jha2 <at> purdue.edu                    Purdue University
(765) 494-5987                     W. Lafayette, IN 47907-2036, USA
-------------------------------------------------------------------


Gmane