Sébastien Gadrat | 19 Sep 16:53 2014
Picon
Picon

Building or not building ROOT dictionaries?

Dear ROOTers,

I am compiling a simple ROOT plug-in, which depends on an external
library. To compile it, I am using a simple Makefile which links to
ROOT_DIR/etc/Makefile.arch. The dictionaries compilation failed because
the include files of the external library are required, but not found.

How can I tell ROOT where to find the external headers for dictionaries
compilation?

Thank you!
Regards,

Sébastien

--

-- 
Sébastien Gadrat
CMS Collaboration  <at> LHC/CERN - CMS Tier-1 Contact Person 
CNRS/IN2P3 Computing Center
Lyon/France
Phone: +33 (0)4 78 93 08 80

Tomas Davidek | 15 Sep 23:30 2014
Picon
Picon

Re: differences in EvaluateMVA

Dear Helge,
  thanks a lot for the feedback. As I said in my previous mail, the difference is not big, but of course it implies some troubles when we were checking the results between several people. The BDT output should be between -1 and 1 by definition (or we are using the most common BDTs ?).

I attached a figure with two plots - the scatter plot between BDT scores calculated in the old (5.34.18) and new (5.34.20) version of ROOT and the relative difference between the two. You can see that in most of the cases the difference is very small, but in few cases the difference can be as large as 50%... Overall, the RMS of the relative difference amounts to ~5%...

It seems the plot is perfectly in line with what you wrote. Also, since the BDT was originally trained in ROOT 5.34.14, I believe it is better to stick to the older version (5.34.18) before the change to be fully compatible... I did not evaluate the impact on the final physics results (hopefully negligible) due to lack of time, we are in the final stage of the paper approval...

Cheers,
                 Tomas

On 09/15/2014 04:56 PM, Helge Voss wrote:
Dear Tomas,

oh .. that is indeed, as you said, not to be expected. Looking through the code changes I noticed that I had made a change that became necessary in the decision of whether an event goes to the 'left' or ot the 'right' when going down the tree, from > to >= , otherwise the handling of integer values (introduced in root 34.20) doesn't work correctly. Now I expected this to be of negligible effect on 'real' valued data. Now I see however, that also accidentally a 'trial' version of the >= compariison, which doesn't belong there creeped into the current code.
In both cases however, I would expect the differences to be small, and not substantial as suggested in your email.

As this makes me worried, could you give me more detail about whot the output distributions compare? You said that for 5.34.18, it is between -1,1 with RMS=5%, and for 5.34.20 ?? Do you have some plots for me ?

Cheers,

Helge


On 15 September 2014 14:32, moneta <lorenzo.moneta <at> cern.ch> wrote:
Hi Helge, 

 Can you, or Eckhard answer this message in the roottalk mailing list

 Thank you 

 Lorenzo

Begin forwarded message:

From: Tomas Davidek <Tomas.Davidek <at> cern.ch>
Subject: differences in EvaluateMVA
Date: 10 Sep 2014 22:00:52 GMT+2

Hello,
  when working with BDT scores, I noticed that these scores are (slightly) different when evaluating via TMVA::Reader::EvaluateMVA between different ROOT versions. I double-checked that the inputs to the BDT scores are perfectly the same, but the BDT output is different. I exercised that on lxplus with three different ROOT versions, 5.34.18, 5.34.20 and 5.34.21. While the latter two versions result in the exactly same BDT score, 5.34.18 is different (the BDT score ranges from -1 to +1, the difference is centered at zero and shows RMS of ~5%).

The xml BDT files were obtained by training with MVA ROOT version 5.34.14....

I understand that there might be a difference between ROOT versions when training the BDT, but I thought that the xml must give the same output regardless the ROOT version.

Is such behaviour expected and/or is there a known bug/problem in 5.34.18 regarding TMVA?

Cheers,
             Tomas




Marcelo Zimbres | 15 Sep 14:53 2014
Picon

Using ROOT from another application with cmake

Hi,

I see one can find the macro root.m4 in the ROOT distribution, to find
ROOT with autotools. Do you also provide a similar file to find ROOT
with cmake?

Regrads,
Marcelo

Picon

error

hi to all.

i am running root dependence software and as a result i get the screen
error:
===========================================================
There was a crash (kSigSegmentationViolation).
This is the entire stack trace of all threads:
===========================================================
#0  0x00007fadb88ca4ee in waitpid () from /lib/libc.so.6
#1  0x00007fadb885f819 in ?? () from /lib/libc.so.6
#2  0x00007fadbe4fc72a in TUnixSystem::Exec (this=0x1dee350, 
    shellcmd=0x20c5a00
"/home/israel/Documentos/root/etc/gdb-backtrace.sh 13360 1>&2")
at /home/israel/Documentos/root/core/unix/src/TUnixSystem.cxx:2084
#3  0x00007fadbe4fcfe1 in TUnixSystem::StackTrace (this=0x1dee350)
    at /home/israel/Documentos/root/core/unix/src/TUnixSystem.cxx:2332
#4  0x00007fadbe4fa829 in TUnixSystem::DispatchSignals (this=0x1dee350, 
    sig=kSigSegmentationViolation)
    at /home/israel/Documentos/root/core/unix/src/TUnixSystem.cxx:1210
#5  0x00007fadbe4f8515 in SigHandler (sig=kSigSegmentationViolation)
    at /home/israel/Documentos/root/core/unix/src/TUnixSystem.cxx:367
#6  0x00007fadbe5009ca in sighandler (sig=11)
    at /home/israel/Documentos/root/core/unix/src/TUnixSystem.cxx:3622
#7  <signal handler called>
#8  0x00007fadbe4d8bab in ~TGenericClassInfo (this=0x8e7480, 
    __in_chrg=<value optimised out>)

at /home/israel/Documentos/root/core/meta/src/TGenericClassInfo.cxx:196
#9  0x00007fadb8856032 in exit () from /lib/libc.so.6
#10 0x00007fadb883bc94 in __libc_start_main () from /lib/libc.so.6
#11 0x000000000046e9b9 in _start ()
===========================================================

The lines below might hint at the cause of the crash.
If they do not help you then please submit a bug report at
http://root.cern.ch/bugs. Please post the ENTIRE stack trace
from above as an attachment in addition to anything else
that might help us fixing this issue.
===========================================================
#8  0x00007fadbe4d8bab in ~TGenericClassInfo (this=0x8e7480, 
    __in_chrg=<value optimised out>)

at /home/israel/Documentos/root/core/meta/src/TGenericClassInfo.cxx:196
#9  0x00007fadb8856032 in exit () from /lib/libc.so.6
#10 0x00007fadb883bc94 in __libc_start_main () from /lib/libc.so.6
#11 0x000000000046e9b9 in _start ()
===========================================================

the error come out once the simulation finish.

thanks

Nadeesha Wickramage | 12 Sep 08:08 2014
Picon
Picon

display not set

Hi All,


I'm trying to run my old files in root with my new mac book. 


I did long on with ssh -Y , but after running the .C file i got the following massage and it doesn't display the plot.


*****************************************************

DISPLAY not set, setting it to lxplus0155.cern.ch:0.0

root [0] 

Processing dataMC.C++...

Info in <TUnixSystem::ACLiC>: creating shared library /afs/cern.ch/user/n/nwickram/Analysis/LowPU/DataMC/./dataMC_C.so

Error in <TGClient::TGClient>: can't open display "lxplus0155.cern.ch:0.0", switching to batch mode...

 In case you run from a remote ssh session, reconnect with ssh -Y

***********************************************************


Should I set something in root for that. 


Thanks a lot for your help



with regards

Nadeesha




Tomas Davidek | 10 Sep 22:00 2014
Picon
Picon

differences in EvaluateMVA

Hello,
    when working with BDT scores, I noticed that these scores are 
(slightly) different when evaluating via TMVA::Reader::EvaluateMVA 
between different ROOT versions. I double-checked that the inputs to the 
BDT scores are perfectly the same, but the BDT output is different. I 
exercised that on lxplus with three different ROOT versions, 5.34.18, 
5.34.20 and 5.34.21. While the latter two versions result in the exactly 
same BDT score, 5.34.18 is different (the BDT score ranges from -1 to 
+1, the difference is centered at zero and shows RMS of ~5%).

The xml BDT files were obtained by training with MVA ROOT version 
5.34.14....

I understand that there might be a difference between ROOT versions when 
training the BDT, but I thought that the xml must give the same output 
regardless the ROOT version.

Is such behaviour expected and/or is there a known bug/problem in 
5.34.18 regarding TMVA?

Cheers,
               Tomas

Pere Mato Vila | 10 Sep 19:00 2014
Picon
Picon

ROOT Patch Release v5.34/21

Dear All,

  We are pleased to announce the patch release ROOT version 5.34/21. For more information see the
announcement at http://root.cern.ch/drupal/content/patch-release-53421

Pere Mato on behalf of the ROOT team.

-------------------------------------------------------------
Pere Mato  CERN, PH Department, CH 1211 Geneva 23, Switzerland
	e-mail: pere.mato <at> cern.ch	tel:   +41 22 76 78696
	fax:  +41 22 76 68792		gsm: +41 76 48 70855

Karl Bicker | 10 Sep 16:18 2014
Picon

SetBranchAddress with pointer juggling

Dear rootonauts,

I am having a peculiar problem when working with TTree::SetBranchAddress(). I attached a breaking
example script, which is intended to be compiled.

The problem is the following: When I am setting a branch address with a pointer on a pointer and the latter is
deleted after the branch address has been set, the reading of the TTree does not work anymore (and somehow
screws up the root command line). Is there a reason for this? Why does the pointer I am handing over to
SetBranchAddress (via a pointer to it) have to survive while the TTree is being read? Would it not be a
simple matter just to copy it in SetBranchAddress?

Thanks in advance for your help!

Best regards,
Karl Bicker

PS: For people who have enough time on their hands to read a lengthy forum post, the background of this
question is here: http://root.cern.ch/phpBB3/viewtopic.php?f=14&t=17632
Clement Helsens | 10 Sep 10:38 2014
Picon
Picon

TTree Draw vector size for a subset of vector elements

Dear ROOT support,

that might be an easy question to answer, but I can not find the solution to my problem.
I have a TTree containing a vector of integer: "jetsid    : vector<int>"

To draw the size of it I’m simply doing:

truth->Draw(" <at> jetsid.size()")

now, I can not find a way to draw the number of elements of my vector that have a given value, for instance 5 to select b-quarks.

Thanks for the help!
Clement
Jens Wienkenhover | 9 Sep 15:28 2014
Picon
Picon

Stacktrace behaviour on OS X Mavericks

Dear all,

I have a question about the stacktrace behaviour of ROOT on OS X Mavericks.

I have two computers with 10.9 installed:

- one which was upgraded from 10.8 (the upgraded machine) and
- one on which a clean install was performed (the "fresh install" machine)

and they show a different behaviour when it comes to stack traces.

For example, I compile the following lib.C file

1: #include <TCanvas.h>
2: #include "lib.h"      // only contains "void libtest();"
3: 
4: void libtest() {
5:   TCanvas* c = 0;
6:   c->Draw();
7: }

as a dynamic library with debug symbols via 

$ g++ -g `root-config --cflags` `root-config --libs` --shared -o libtest.dylib lib.C

and then use the libtest() function in a compiled test.C root script like so:

root[0] gSystem->Load("libtest.dylib");
root[1] .x test.C+

On the upgraded machine I get the "normal" stack trace:

*** Break *** segmentation violation
(..)
#4  <signal handler called>
#5  0x0000000107e7bb5b in libtest () at lib.C:6
#6  0x0000000105ea0bde in G__test_C_ACLiC_dict__0_1298 ()
#7  0x0000000105070481 in Cint::G__ExceptionWrapper ()
#8  0x000000010511945b in G__execute_call ()
#9  0x00000001051198bc in G__call_cppfunc ()
#10 0x00000001050ed23e in G__interpret_func ()
#11 0x00000001050db6b4 in G__getfunction ()
#12 0x00000001050cff2f in G__getitem ()
#13 0x00000001050cba92 in G__getexpr ()
#14 0x00000001050c3f23 in G__calc_internal ()
#15 0x0000000105157e90 in G__process_cmd ()
#16 0x0000000104918094 in TCint::ProcessLine ()
(..)

which correctly identifies the cause of the segmentation violation in the shared library.

On the "fresh install" machine I only get:

*** Break *** segmentation violation
 Generating stack trace...
 0x000000010694b481 in Cint::G__ExceptionWrapper(int (*)(G__value*, char const*, G__param*, int),
G__value*, char*, G__param*, int) (in libCint.so) + 49
 0x00000001069f445b in G__execute_call (in libCint.so) + 75
 0x00000001069f48bc in G__call_cppfunc (in libCint.so) + 860
 0x00000001069c823e in G__interpret_func (in libCint.so) + 5198
 0x00000001069b66b4 in G__getfunction (in libCint.so) + 5732
 0x00000001069aaf2f in G__getitem (in libCint.so) + 511
 0x00000001069a6a92 in G__getexpr (in libCint.so) + 31458
 0x000000010699ef23 in G__calc_internal (in libCint.so) + 979
 0x0000000106a32e90 in G__process_cmd (in libCint.so) + 16992
 0x00000001061ef094 in TCint::ProcessLine(char const*, TInterpreter::EErrorCode*) (in libCore.so)
+ 884
(..)

which omits all stack information outside of ROOT itself and is the equivalent to "your script crashed somewhere".

I’ve noticed that the upgraded machine still has /usr/bin/gdb while the "fresh install" machine does
not. Renaming the /usr/bin/gdb executable causes the same output on both machines. However, installing
gdb manually (via homebrew) on the "fresh install" machine does not reenable the first output, rather the
output is very useless and causes ROOT to hang.

Does anyone know how to reenable the old behaviour?

Best regards,

Jens

--

-- 
Jens Wienkenhoever

RWTH Aachen University
1. Physikalisches Institut B
Sommerfeldstr. 14
52074 Aachen
GERMANY

Office: 28-B-207
Tel.: +49-241-80-27071

Corey Reed | 9 Sep 09:15 2014
Picon
Picon

TTreePlayer special variable to access x/y/z axis formula

Hi,

I've been searching for this feature, but .. does it exist? If not, I 
could I request it?

The feature in question would be a group of special variables (à la 
Entry$), e.g. 1$, 2$, 3$, that would evaluate to the formulae being 
plotted on the x-, y- or z-axis, respectively. Effectively acting like 
"GetV1" but inside the Draw loop rather than after it.

Such a feature would be especially useful in restricting the drawing 
range of a complicated variable -- to do something like the following:

tree->Draw("TMath::ACos(alpha+(beta/2)):TMath::Log10(energy)","1$>0 && 
2$<8");

or

tree->Scan("TMath::ACos(coszenith)*180/3.14:spaceAngle*180/3.14","1$>0 
&& abs(1$ - 2$)<10")

Is there any way to do this currently, without setting aliases 
beforehand? (The feature is most desirable when exploring data, calling 
SetAlias before every Draw is more work than copy/paste, so...)

Thanks!

- Corey


Gmane