Hi,
>From your result I am guessing that your array 'trk_stpz' has a variable
size.
If this is the case you __have to__ check this size before trying to access
the data. ROOT does not overwrite the out-of-bounds value because it would
not what to put instead and it would be a waster of time since the user know
(should know) that the values are out oof bounds.
Cheers,
Philippe.
PS. For a better diagnosis, I would need at the least the result of
TTree::Print on your tree or even better a real example of your root files.
-----Original Message-----
From: owner-roottalk@pcroot.cern.ch
[mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Philip Symes
Sent: Friday, February 20, 2004 11:01 AM
To: roottalk@pcroot.cern.ch
Subject: [ROOT] Bogus values using MakeClass
Hi ROOTers,
I'm using ROOT 3.10/01 on Red Hat 9. This doesn't seem to have been
mentioned
in the development notes of either of the more recent versions.
I used MakeClass and wrote a simple function to print out a sample of raw
data
to a file:
void NtpSR::Scan()
{
if (fChain == 0) return;
Int_t nb=0;
ofstream fileout("scan.txt");
if(!fileout) return;
fileout.flush();
fileout << "snarl plane x-strip y-strip z-track x-track y-track" << endl;
// i.e. event, plane hit in calorimeter, strip giving x-position hit, strip
giving y hit, track fitted z position hit, tracked x-position hit, tracked y
hit
for (Int_t jentry=2050; jentry<2350;++jentry)
{
Int_t ientry = LoadTree(jentry);
if (ientry < 0) break;
nb = fChain->GetEntry(jentry);
fileout << fHeader_fSnarl << endl; // prints out the event number
for(int jj=0;jj<evthdr_nstrip;++jj)
{
if(stp_plane[jj]%2==0) fileout <<"\t" << stp_plane[jj] << "\t\t" <<
stp_strip[jj];
else fileout <<"\t" << stp_plane[jj] << "\t" << stp_strip[jj] << "\t";
if(jj<trk_plane_n[0]) fileout << "\t" << trk_stpz[0][jj]/0.06 << "\t" <<
(trk_stpu[0][jj]/0.041)+12 << "\t" << (trk_stpv[0][jj]/0.041)+12;
fileout << endl;
}
fileout << endl;
}
fileout.close();
return;
}
I came across a problem: some of the track positions were being duplicated
and
written out in subsequent events (upto 10 times). Here is an excerpt of
scan.txt, showing a problem pair of events. The strip hits (first two
columns) are different but the track positions are the same.
6261
3 11 3.86833 11.3486 23.962
4 22 5.84833 8.94258 20.9785
5 6 6.83833 7.62524 19.4927
5 8 7.82833 6.51672 17.9635
5 9 8.81833 5.37912 16.4895
6 6 9.80833 4.45333 14.9408
6 9 10.7983 3.32311 13.5022
6 19 11.7883 2.44142 12.0108
7 6 12.7783 1.32568 11.1971
7 9
7 19
8 16
9 4
9 14
9 17
10 13
10 14
11 2
11 14
12 11
13 0
6263
50 1 3.86833 11.3486 23.962
50 2 5.84833 8.94258 20.9785
52 23 6.83833 7.62524 19.4927
53 21 7.82833 6.51672 17.9635
53 23 8.81833 5.37912 16.4895
54 7 9.80833 4.45333 14.9408
54 8 10.7983 3.32311 13.5022
54 16 11.7883 2.44142 12.0108
54 18 12.7783 1.32568 11.1971
54 19
54 23
55 7
55 21
56 16
57 4
57 18
57 21
I looked at these events using an interactive ROOT terminal, and here it
looks
as though the track positions are not the same (using the first 3 hits of
the
event):
root [20] NtpSR->Scan("trk.stpz[0][1]","fHeader.fSnarl==6261")
************************
* Row * trk.stpz[ *
************************
* 2080 * 0.3508999 *
************************
==> 1 selected entry
(Int_t)1
root [21] NtpSR->Scan("trk.stpz[0][2]","fHeader.fSnarl==6261")
************************
* Row * trk.stpz[ *
************************
* 2080 * 0.4102999 *
************************
==> 1 selected entry
(Int_t)1
root [22] NtpSR->Scan("trk.stpz[0][3]","fHeader.fSnarl==6261")
************************
* Row * trk.stpz[ *
************************
* 2080 * 0.4697000 *
************************
==> 1 selected entry
(Int_t)1
root [23] NtpSR->Scan("trk.stpz[0][1]","fHeader.fSnarl==6263")
************************
* Row * trk.stpz[ *
************************
* 2081 * *
************************
==> 1 selected entry
(Int_t)1
root [24] NtpSR->Scan("trk.stpz[0][2]","fHeader.fSnarl==6263")
************************
* Row * trk.stpz[ *
************************
* 2081 * *
************************
==> 1 selected entry
(Int_t)1
root [25] NtpSR->Scan("trk.stpz[0][3]","fHeader.fSnarl==6263")
************************
* Row * trk.stpz[ *
************************
* 2081 * *
************************
==> 1 selected entry
(Int_t)1
It seems as though the track positions weren't filled-in properly for event
6263, so the values from event 6261 haven't been overwritten. Is that a fair
guess?
Are the pointers used in MakeClass reset to null (0x0) before the tree is
reloaded with a new entry? Or is there another way to prevent the data from
one event being polluted by the values of a previous one?
Cheers,
Phil
--
Philip Symes,
MINOS Group, SciTech,
Univ. of Sussex, Brighton, BN1-9QH, UK.
http://minoserv.maps.susx.ac.uk/~symes/
This archive was generated by hypermail 2b29 : Sun Jan 02 2005 - 05:50:06 MET