a2-collaboration / acqu Goto Github PK

AcquRoot does an inheritance check for the analysis and detector classes to check if they're valid. If this check fails a fatal error is triggered causing Acqu to exit. This check fails starting with ROOT 6.20, in case of analysis classes AcquRoot.log shows “Error in operation of class TAcquRoot at command line: FATAL ERROR…exiting AcquRoot”.

In the case of analysis classes, this check is done in TAcquRoot and TA2Apparatus. Commenting out those if conditions enables registering the analysis class. There are more of those checks in place in other classes like TA2Detector.cc and TA2DataManager.cc. To avoid these problems use a ROOT version prior to 6.20/00.

Hi guys,
what do you think about adding by default the O_LARGEFILE flag in acqu_core/AcquRoot/src/ARFile_t.cc?
It should go here:

else fName = sys->BuildName( (Char_t*)name );
switch(i){
default:
--> flags = O_LARGEFILE;
fPath = open(fName, flags, mode);
if(fPath == -1)
PrintError("<ERROR ARFile_t: file open by open() failed>", EErrFatal);

I'm not able to analyse big data files on my machine unless this flag is enabled and I think this is harmless for those who don't have problems with big data files.
Do you agree?

Ciao,
Susanna

The following is copied from a discussion at the a2ana mailing list (June 2013).

Peter-Bernd Otte said:

Hi all,

I'm not sure whether this is new or not, but I found two problems with raw data files:

• after the last scaler information in data, there comes more event data which will have no scaler information. One needs to discard these events if one uses scalers in the analysis. If not, this leads to an systematic error of 1-2% for beamtimes with a scaler read every 20k events.
• the first buffer in a file can be wrong (it might belong to the file before or whatever). This is equivalent to the first ~20 events which can also include a scaler read. A good indicator whether the data is wrong or not is to check the raw experiment event id stored in each event.

Last but not least its good to check for error blocks in the data, they should only occur with a rate of 1/1000 or rather 1/20k.

Cheers,
Peter

John R.M. Annand said:

Dear Peter,

part of the problem is that slave daq systems do not know when a run starts/finishes. That would require some extra means to communicate that info from the master daq.

Cheers, John

Philippe Martel said:

Hi Peter and everyone,

Similarly unsure whether this is well known (though I hope it is, and we
were just unaware), but looking into the problem you noted I've found
that the first scaler buffer read of a file does not necessarily occur
after 20k events, but rather the remainder of the 20k events from the
previous file. So the scalers from this lost buffer at the end of a file
are preserved, and then appear at the beginning of the next file.

Obviously it could be from a file that isn't used, and therefore
over-count the scalers. Even worse though, the scalers are not inhibited
between runs, so this first buffer read can be much higher than normal.
I've seen at least one instance of it being a factor of 20 larger, more
than 1/10th of the accumulated scalers, even though it's only from
1/75th of the file. Overall it also leads to a few percent effect, but
it's worth noting. It can be dealt with by summing each scaler read as
it comes in (neglecting this first one), and then either scaling this
sum by #Events/(20000*#ScalerReads) or dropping the extraneous events on
either side.

-Phil