MuPC data tester volunteer

[joegrange]

Hi all, As I mention in elog 210, the muPC data is ready to be tried out in alcapana. Might anyone have the time soon to try integrating this in your analysis stream with a few files at a low level just to see if things look sensible? We should do this before doing another production run - I've checked the output and it looks like expected, but it'd be good to have someone else check, especially since git told me ominously that I deleted 3k files in my push...

Also @AndrewEdmonds11, might you be able to check the output of the DQ scripts? I got so far as producing the muPC mean x, mean y, rms x and rms y trend plots (via GenerateTrendPlots.C and GenerateAllPlots.C) that will go into the dataset picture book, but I didn't make it to putting these into the tex file as merlin can't do pdflatex. I think that's an easy task, anyway, I'll find a workaround if you don't have the time.

Thanks folks! Joe

[AndrewEdmonds11]

Sure, I can have a play with the muPC data and have a look at adding the plots to the picture book. Do you want me to test both alcapana and using the TMuPCCluster class in rootana?

BTW Your commits on develop (d75532e3192681855cc337831653afdfc2d97a38 and b5844576dd6604d4f1f428564513f63efa4c9725) don't look like they've deleted any files, so I'm not sure what you're seeing.

[joegrange]

Thanks so much Andy. I was assuming getting the class into rootana would be another step by myself after the alcapana validation, but maybe rootana digests whatever is present in alcapana and so rootana integration comes along "for free"? If so and you're already well set up to test this that'd be great.

[AndrewEdmonds11]

Hi Joe

I've started having a play with this but I'm not sure I'm using it correctly. The final tree I get is huge at 24GB (compared to 1.6GB when I don't use MMuPC_Repackage, which means I have a hard time drawing anything in TBrowser. Do you have any scripts already written that I could use?

Here is my MODULES file:

FADC/MOctalFADCProcessRaw
v1724/MV1724ProcessRaw
dt5720/MDT5720ProcessRaw

muSC_muPC/MCaenCompProcessRaw
muSC_muPC/MMuPC1AnalysisC
muSC_muPC/MMuPC1AnalysisMQL
muSC_muPC/MMuPC_Repackage

vacuum/MVacuumHisto

common/MTreeOutput

and I am testing with run 3000.

[joegrange]

Thanks so much for looking Andy. I didn't develop a macro, I just used the command-line interface with root to look at some distributions and make sure they look sensible. I very cleverly forgot my password for psi where my working directories are, so I can't post it right now. When I get it straightened out I'll do so. Times 20 in file size sounds crazy.... When I get back in I'll see if I get the same size change. Very strange...

[AndrewEdmonds11]

Cool. Could you tell me some of the commands you use? I'm struggling to get a hold of and use the vector. So far I do this:

root -l tree03000.root 
root [0] 
Attaching file tree03000.root as _file0...
root [1] TGlobalData* data = (TGlobalData*) EventTree->GetBranch("Event")
root [2] vector<TMuPCCluster*> clusters = data->fMuPCClusterVector

but then any time I try to use clusters ROOT complains that there's no dictionary. I'm guessing there's something obvious I'm forgetting....

[joegrange]

Hmm, I used different syntax, something like [0] TFile *_file0 = TFile::Open("tree02808.root") [1] tv__tree->Draw("fClusterVector","","", 85, 0);

But I'm not confident since I can't confirm....

[joegrange]

(I think 85 was the number of events in the truncated file or something)

[benkrikler]

Since std::vector<> is a template I think rootcint doesn't like it unless you compile a dictionary for it in advance. You could try adding it to the linkdef in alcapana (src/common):

#pragma link C++ class vector<TMuPCCluster*>+;

recompile, and then try again in interactive root (possibly loading the alcapana library in first as well)...

[joegrange]

Right, thanks Ben, I forgot the step of loading the lib:

.L libDataClasses.so

[joegrange]

Okay I'm back in, here's my interactive session: [grange_j@merlinl01 grange_j]$ root -b tree02808.root root [1] TCanvas *c1 = new TCanvas(); root [2] EventTree->Draw("fMuPCClusterVector.GetWireNumberX():fMuPCClusterVector.GetWireNumberY()","","colz", 85, 0); root [3] c1->Print("xvy.eps"); Info in TCanvas::Print: eps file xvy.eps has been created And I get the below plot.

[AndrewEdmonds11]

Thanks, Joe. Your commands work but I get a slightly weird distribution:

Also, Ben's suggestions means I can use the vector of TMuPCClusters. Looking at the size of the vector I get:

root [2] TGlobalData* data = (TGlobalData*) EventTree->GetBranch("Event")
root [3] (data->fMuPCClusterVector).size()
(const unsigned long)18446738178387825937

Did you have a large file size as well, Joe? Maybe that's just how many hits we have....

[benkrikler]

Could the odd distribution be a binning effect? Try forcing the binning in the draw command and see if it clears it up maybe?

[joegrange]

Yep it's gotta be a binning thing. You can see I get it as well above. The wire numbers generally come as integers, half integers or 1/3 integers depending on how many hits and which wires were part of the cluster. I'll look at the size in a bit, but even if there are lots and lots of clusters, for every one of these shouldn't there be tons of TPI's in various detectors? Seems crazy that muPC is so much more expensive than 10x all other detectors.

[benkrikler]

But for every muon that enters the chamber only some fraction of the detectors see anything, whereas the muPC sees it all.

The muSc should be a good comparison though, the acceptance of the muPC is about the same as the muSc right? And since the muSc records a waveform with some 200 samples, whereas the muPC clusters are just an x-y coordinate (am I right on that?) you would expect the muPC data to be about 100 times smaller that the muSc data, right?

[joegrange]

Ack, right thanks Ben. I suppose the relative sizes will depend on the number of doubles (muPC delivered with 3 doubles) and however musc is stored. Maybe doubles -> floats would be a good start for muPC.

[AndrewEdmonds11]

You're right. Having a histogram with 25 bins on each axis gives this:

Much nicer :smile:

Now we see that there are ~3M entries, which is wildly different to the size of the vector I saw. I will look into this further

[joegrange]

Run 2808 is 31GB using doubles and 23GB using floats. A step in the right direction, but that's still a large jump in total file size...

[AndrewEdmonds11]

Is there a more efficient way to store this? It seems we have the bare minimum in a time stamp, an x wire and a y wire but maybe we can use a different container?

Or do we need to do some analysis in alcapana to cut down the amount we keep? This is all hits, right? Do we only need the muon hits - could we do a coincidence with the muSc hit being a muon?

[Sorry for all the questions. Just thinking aloud...]

[joegrange]

These are clusters, not hits, so it actually would've been worse had we kept each hit+timestamp pair. Good idea - we sure could cut things down using musc time correlation but don't we have to get this into alcapana before we can do that?

[AndrewEdmonds11]

Ideally, I think we wanted the data coming into rootana to be as raw as possible so that we don't have to re-run alcapana each time we find a problem with one of our algorithms. Maybe we'll have to make an exception in this case...

[jrquirk]

To augment this conversation I think this is a prime topic for the analysis meeting.

[jrquirk]

The fMuPCClusterVector is never getting erased. I put in MTreeOutput a line to print the vector size, and it's always getting bigger. There are about ~700 TMuPCClusters per MIDAS event, and with 3 doubles (8 bytes each), we should have an uncompressed increase in file size of ~70 MB. This means, once this problem is fixed, the change in file size from before will be negligible.

[joegrange]

Thanks John! I thought I'd ported over all the clean-up tasks from the TPI class but I guess I missed the most important one...

[AndrewEdmonds11]

Just tested and the tree is now 1.6 GB :). Thanks, John!

[AndrewEdmonds11]

So, I've written a quick rootana module to test that we can use the fMuPCClusterVector and it works!

int TestMuPCCluster::ProcessEntry(TGlobalData* gData,const TSetupData *setup){
  std::vector<TMuPCCluster*> clusters = gData->fMuPCClusterVector;

  for (std::vector<TMuPCCluster*>::iterator i_cluster = clusters.begin(); i_cluster != clusters.end(); ++i_cluster) {
    std::cout << (*i_cluster)->GetTimeStamp() << std::endl;
  }
  return 0;
} 

Just a couple of quick questions:

• Is the time stamp already translated to nanoseconds (it doesn't look like it but thought I'd check)? If not, do we know the frequency of the digitiser the muPC was plugged into?
• Where is this coming into the analysis? Shall I leave it for people to sort out themselves or do we want to package this up somehow (e.g. into the TMuonEvents where we can add this to check for a muon hit)?

[joegrange]

Great! For the units, they do look like ns to me, see the usual midas-block time distributions for raw x, y wire hits in this elog. This was plotted upstream of the clustering algorithm, but the units shouldn't have changed. For the second part I'd defer to the more prolific analyzers.