: unknown branch -> ModuleDescriptionMap
cmsRun: /afs/cern.ch/cms/Releases/CMSSW/CMSSW_0_8_0/src/IOPool/Input/src/RootFile.cc:87: edm::RootFile::RootFile(const std::string&, const std::string&): Assertion `eventMetaTree_ != 0' failed.
Aborted
0_6_0 sure didn't do that.
Can't figure out how to run tp producers to give input to RCT either. Can't even run ecal tp producer (writeTP.cfg) as is. Maybe it's 0_6_0 vs. 0_8_0. Ursula doesn't know what's up.
July 25, 2006
Answered Arun's e-mail -> can't compile RCT either, but different errors. Seems like Greg Heath has compiled it and can start to run it by .cfg, but then it gives some error. I've asked him to point me to said .cfg, and also asked Alex if he got everything worked out with the compilation problems he was having (because it might be the same things I'm running into).
Trying to do ecal tp producer in 0_8_0. EcalTrigPrimProducers needs EcalTrigPrimAlgos checked out. EcalTrigPrimAlgos builds. Now EcalTrigPrimProducers builds now, too.
Hey, I think writeTP.cfg ran correctly. (You need to be IN test/ directory for it to work.)
July 26, 2006
Got e-mail from Greg, he used a .cfg and modified L1RCT.cc to check array indices. He says he's getting weird stuff for the hcal digis. Hmm. His e-mail:
Hi,
Here's my .cfg file. I am running it in the directory
CMSSW_BASE/src/L1Trigger/GlobalCaloTrigger/test under CMSSW_0_8_0. It
references SimCalorimetry/EcalTrigPrimProducers/data/ecaltp.cfi which I have
checked out of the repository by hand into my private area.
Also I am attaching an edited version of L1RCT.cc. This checks the array
indices before packing the digis into the rct input vector and so I have
just run a job that generates and processes 5 events without crashing. I've
edited the code that converts from eta and phi to card and tower etc. For
the ecal digis I get numbers that look sensible (probably still wrong, but
in the correct range!).
For the hcal digis there is something funny going on. In the eta range
between 1 and 20 (positive and negative) the value of id.phi() goes from 1
to 72, as for the ecal (then gets converted to rctPhi between 0 and 71).
Beyond eta=20, the phi() value increases 1,2,5,6,9,10, etc up to 125,126.
Still stranger things happen in the HF.
Greg.
Here is his .cfg file.
What the heck, RCT just built! I have no clue what I did to make it suddenly work. Voodoo. Magic. Sorcery.
I still don't know what "project CMSSW" does, but it makes me have sufficient karma all of a sudden. Now THAT's magic.
E-mailed Mike with questions on HCAL phi numbering. Hopefully he'll help or will point us to someone who can.
Greg figured it out. I'm still working on it. (Relevant info in Geometry/HcalTowerAlgo/HcalTrigTowerGeometry and Geometry/HcalTowerAlgo/HcalGeometry.) He also found other errors in my code, it sounds like.
// Note ((absIeta % 8) -1)*4 is 65532 when absIeta is a multiple of 8
Oops, I guess that is true if absIeta and tower are UNSIGNED (they are). Duh. So much for my trying to be efficient and stuff.
Eta index 1->20: phi divisions 5 degrees (72 bins, 1-72)
Eta index 21->28: phi divisions 10 degrees (36 bins, 1,3,5,7, . . . 71)
Eta index 29->32 (HF): phi divisions 20 degrees (18 bins, 1,5,9, . . . 69)
So do iphi/2 for 21->28 to get 0,1,2,3 . . . 35 and iphi/4 for 29->32 to get 0,1,2, . . . 17?
But the TDR and Pam's recent (not yet official) note say that 21->28 are "split" to "mimic" 5-degree divisions. So then are there 36 or 72 actual digis for each eta division?
Think Greg's algorithm for numbering towers in card 6 both regions is off.
E-mailed Greg with lots of questions.
July 27, 2006
Well, there was a whole e-mail exchange in response to my e-mail yesterday, but it didn't really answer all my questions. It now seems HCAL's numbering is different from ECAL's??? Man.
July 31, 2006
I discovered one of Greg's e-mails DID include the answers to my questions, but they were hidden in my original message at the bottom, after he'd already signed his name.
It appears that the ECAL phi numbering goes from 1-72, while the HCAL phi numbering goes from 0-71(?) (maybe it's just my own code that does that. I'll have to take a look at that). Not to mention that the numbering starts at different angles for each. Blah.
I thought L1RCT::digiInput() counted iphi from 1-72. That's what I was thinking when I wrote it.
HCAL does count iphi from 1-72. I'll have to ask Greg why he thinks digiInput does from 0-71.
Since when does ECAL's iphi START from just above -10 degrees??? I was just getting used to the fact that it started at the new definition of 0 degrees!
Just sent an e-mail to the ECAL people asking about that.
So my code is SUPPOSED to do 1-72, but it doesn't look like it actually does all the time. Stuff to fix:
tower -> tower-1 in ecal and hcal barrel (but NOT HF, which goes 0-7)
8 mod 8 = 0, not 8
so after: regionPhi = (iphi mod 8)/4;
put: if (regionPhi==0){regionPhi=8;}
Aug. 1, 2006
Confused, but straightening things out.
RCT iphi DOES go 0-71, but CAL iphi goes 1-72. Changed transformation from (72 + 19 - iphi) mod 72 to (72 + 20 - iphi) mod 72.
Diagram:
cal_iphi 92 - cal_iphi % 72
20 72 0
19 73 1
18 74 2
17 75 3
16 76 4
...
4 88 16
3 89 17
2 90 18
1 91 19
72 20 20
71 21 21
70 22 22
...
Added a +1 to tower numbering, to make towers go from 1-64, then put a -1 in the barrel assignment, since vector numbered from 0-63.
Still don't like what Greg did for region 1 of card 6. Came up with a new algorithm for that, not as clunky as the old one. E-mailed him these changes, we'll see what he says.
Aug. 2, 2006
Seems good! Greg just said something about correcting the regionPhi calculation for HF. That makes sense (oops).
Aug. 7, 2006
Wrote up recipe for running RCT fully in CMSSW, put on twiki page. Recipe doesn't work since they changed stuff in SimCalorimetry/EcalTrigPrimProducers. Checked out old versions of ecaltp.cfi, ecaltp.cff to use, via
cvs update -r1.3 ecaltp.cfi
cvs update -r1.2 ecaltp.cff
in the SimCalorimetry/EcalTrigPrimProducers/test directory. Don't know if I needed ecaltp.cff, did the same thing as before I checked it out. Now the whole thing runs, but the RCT test analyzer prints out all zeros. Probably not good. Don't know where the problem is.
Yeah, looking at ecaltp.cff, I probably didn't need it. I don't think it's included in the .cfg file.
Removed the analyzer from the process so the print-out didn't take up all the screen. Now see a lot of "out of range!"s, which I think Greg put into the digiInput() method. Dang. Why isn't this working?
Aug. 8, 2006
If HF is supposed to have 18 phi bins, why does it have phi up through 36? Is this just a feature of my cobbled-together ECAL stuff? It shouldn't be, if it's HF!
E-mailed Jeremy Mans, he says 36 is a bug left over from an ORCA copy-and-paste, but that it won't be fixed until 1_0_0_pre1. Oh well. He also says he'll number them 1,5,9, . . . 69 instead of 1-18. That should be fine, I can just integer divide each by 4 to get 0,1,2, . . . 17. (NOTE TO SELF: REMEMBER TO DO THAT!)
Also need to fix crate number formula used by HF, since HF iphi numbering different than rest of HCAL.
Still unsure of phi numbering of eta rows 21-28: 1,5,6,9,10,13,14,17,18 . . . 125,126 for a total of 64 digis per row instead of 72??? Another e-mail to Jeremy.
The loop doesn't go all the way out to eta = 32, which it should. Maybe those 18 extra HF digis are taking up space? The loop runs 4176 times = [(28 eta * 2) * 72 phi] + (4 eta * 2) * 18 phi. That should be correct.
Aug. 9, 2006
Jeremy said that's another bug he'll look into.
Greg said his new HcalTrigTowerGeometry.cc file should fix those HCAL bugs. That's what I have, though. He uses his file and it works fine. What could be different?
And there seem to be 64 digis for eta -29, when there should only be 18 (it's HF). I KNOW Greg wrote that fix into his file.
There doesn't appear to be any energy in the HF digis; nor ECAL, barely -- a single ECAL deposit for each of 2 events, 4 for a third, and none for the two others in that run. No energy in HF perhaps doesn't specifically have to do with the HF code; there's barely any energy with |ieta| above 4.
Committed latest version of the code (couts all commented out), along with the test file, EvtGen+DetSim+Digi_rct.cfg, and tagged it all with jleonard_8-9-06 . Jeremy seems to have made some changes to the HCAL code, so I'll have to see how RCT works with that.
Aug. 10, 2006
Got the new version of Geometry/HcalTowerAlgo. Now it gives me a segmentation violation in the middle of running. The output file shows it going through all of ECAL and pretty much all of HCAL before all of sudden it can't access the energy -- hmm, it actually seems like there aren't any more digis left. That would be a good reason that it can't access the energy of a digi. However, there are supposed to be more digis -- it looks like |ieta| between 21 and 28 still have 64 digis per row instead of 72. But ieta -29 still has too many. E-mailed Jeremy.
Changed method for determining rct-based iphi for HF, to account for new numbering. Stuck new L1RCT.cc in CVS.
Greg thinks something must be wrong with HF -- nothing shows up there, even when he uses a particle gun up to eta = 4.8 and even when there's tracks pointing at it. He also says 0_9_0 has lots of changes, particularly in the ECAL, so maybe I'll get more deposits there if I switch(?) (How can you have HCAL deposits but none in ECAL?)
Aug. 11, 2006
Pam and Wesley forwarded a long e-mail discussion on how iphi WOULD be starting at 0 degrees now, instead of -10. E-mailed Jeremy, just to check. The HcalTrigTowerGeometry.cc file has not yet had everything fixed. Don't know how much I can do right now.
Jeremy says yes, 0 degrees. So that would look like:
HCAL_phi 90-HCAL_phi %72 (=rct_phi)
--------------------------------------------------- +90
18 72 0
17 73 1
16 74 2
15 75 3
--------------------------------------------------- +70
14 76 4
.
.
.
3 87 15
--------------------------------------------------- +10
2 88 16
1 89 17
72 18 18
71 19 19
--------------------------------------------------- -10
70 20 20
HF stays the same.
Will ECAL make these same changes, too? (If so, remember to change!) I think all the ECAL people are on vacation. I haven't gotten any e-mails answered in a while.
Aug. 14, 2006
Made some changes to L1RCT.cc that Greg suggested to simplify things. Jeremy made changes to HcalTrigTowerGeometry.cc. I guess the ECAL will stay where it is at -10 degrees.
WOO! Everything runs with no errors, all digis accounted for, no "out of bounds"! Still don't know about the dearth of info in ECAL or HF. Jeremy's checking on the HF. For the ECAL, yes, there's deposits, sometimes, but not many! (Again, how can there be energy in HCAL with none in ECAL?)
Also got an e-mail from Mike Weinberger about LUT's. Good, now I can find out what I have to do for that.
No word on whether I can stop using ecaltp.cfi. Nothing in EcalTrigPrimProducers seems to have changed.
Aug. 15, 2006
Tried running the GCT analyzer package under 0_9_0. Once I got stuff to work, it ran fine. I don't really know what I'm looking for, though. Greg has a list of issues to fix on the GCT analyzer twiki page; one says the jet energies are 2-4 times what they should be. I wondered if that was the RCT's fault -- and sure enough, I went back and looked, and I hadn't changed the formulas that unpacked the energy and bit for each tower. So I sent Greg a corrected version of L1RCTReceiverCard.cc.
Aug. 16, 2006
Greg says new version of L1RCTReceiverCard.cc changes things; now there seem to be the right number of jets, and they only have up to 2x too much energy.
Realized my L1RCTReceiverCard.cc modifications now make the fileInput() method incompatible with the way the rest of the program works. Hmm, maybe I can change it to store stuff in the same format as digiInput().
Think I got it fixed. File names: L1RCTReceiverCard_mine_aug15_a.cc and L1RCT_mine_aug16.cc in home dir.
Aug. 17, 2006
My .cfg file for running the RCT doesn't work in 0_9_0. It gives me this:
cms::Exception caught in cmsRun
---- Configuration BEGIN
The unknown module label "SimG4Object" appears in path "p1"
please check spelling or remove that label from the path.
---- Configuration END
cms::Exception caught in cmsRun
---- Configuration BEGIN
The unknown module label "SimG4Object" appears in path "p1"
please check spelling or remove that label from the path.
---- Configuration END
What am I supposed to use instead of SimG4Object? I don't know enough about OSCAR or whatever the people are changing between CMSSW versions. Maybe I can look in Greg's file.
Ahh, the module has been renamed: g4SimHits. So that's what needs to go in the path p1. And it works!
Aug. 18, 2006
Still working on getting .cfg file to run in 0_9_0. Lots of stuff has changed, it looks like.
Got an e-mail from somebody looking for a Region-to-Tower map. Hmm, don't really know of one.
Aug. 21, 2006
*** Break *** segmentation violation
Generating stack trace...
/usr/bin/addr2line: cmsRun: No such file or directory
/usr/bin/addr2line: cmsRun: No such file or directory
???? I've gotten this before, but it seemed to take care of itself beforehand. Not this time. The L1RCTProducer runs and then it quits with this and the requisite spew of junk. Workaround: comment out the GENE-SIM-DIGI module, which is the only thing that runs after the RCT and just puts out the root file. So I don't have a root file now -- oh well.
To test the L1RCT.digiInput() input and new RC.cc access methods, I checked the cout statements of input and output (after access) for an event I ran. Everything checked out! (I only checked HCAL, because ECAL had exactly 1 hit in the input.)
Aug. 22, 2006
PoolOutputModule is what gives that segmentation violation, but only for 0_9_0. It does it every time with my file, and it also did it with Greg's L1GctAnalyzer .cfg test file. But with his, there was no stack trace. Hmm.
Aug. 30, 2006
Found out that the PoolOutputModule thing is a result of a ROOT bug; they'll use the patched version of ROOT in CMSSW_1_0_0_pre2 (HyperNews Forum, https://hypernews.cern.ch/HyperNews/CMS/get/swDevelopment/459/2.html ). Until then, if necessary I can probably create a file in my analyzer to store any histograms. I don't know if that would store event data necessarily, though. (Or, going to a one-character process name bypasses the problem??)
Now adding to the analyzer to make sure all generated electrons are caught and counted as L1CaloEmCands, with ~the correct energy, eta, and phi. Just tried to compile the first draft; apparently SimDataFormats/HepMCProduct/interface/HepMCProduct.h, which I need, includes CLHEP/HepMC/ReadHepMC.h, which doesn't exist. In fact, the entire CLHEP directory doesn't exist in the CMSSW repository. I'm sure it existed in the recent past, because Kira includes SimDataFormats/HepMCProduct/interface/HepMCProduct.h in her analyzer file, which I would think she used at most a couple weeks ago. And HepMCProduct.h hasn't changed in over two months. Where did CLHEP go??
Aug. 31, 2006
Well, it looks like CLHEP has its own CVS repository. Hmm, do I have to add a line to the BuildFile to get it to look there?And CLHEP/HepMC/ReadHepMC.h still doesn't exist, but CLHEP/HepMC/HepMC/ReadHepMC.h does. I guess I can check out SimDataFormats/HepMCProduct and change that line.
Line changed, still can't find the file. Think maybe the line shouldn't be changed -- in the NEW CLHEP CVS repository the old way was correct.
Hah. Sasha Nikitenko's BuildFile includes the line <use name=SimDataFormats/HepMCProduct>
as well as <use name=clhep>
Maybe that'll work. He also has <use name=root>
I don't think I'll need that (?)
That stuff worked, now it's down to the more basic compilation-troubleshooting.
It compiles!
Sept. 1, 2006
Runtime error:
%MSG-w ScheduleExecutionFailure: PostModule 01-Sep-2006 18:07:26 XYZ
Run: 1 Event: 5
an exception occurred and event is being skipped:
---- ScheduleExecutionFailure BEGIN
ProcessingStopped
---- ProductNotFound BEGIN
TooManyMatches getByType: too many products found, expected one, got 2, for
edm::HepMCProductcms::Exception going through module L1RCTTestAnalyzer/rct_analyzer run: 1 event: 5
---- ProductNotFound END
Exception going through path p1
---- ScheduleExecutionFailure END
The lines in the analyzer are:
// get MC info
Handle<HepMCProduct> evt;
iEvent.getByType(evt);
In his research journal, Mike (Anderson) says how he got around this error (in 0_8_0):
Christos pointed out a few things I needed to change to get my Analysis code working:
// get MC info
Handle<HepMCProduct> eventCollection;
iEvent.getByLabel(m_HepMCProduct, eventCollection);
where you should define before
m_HepMCProduct = iConfig.getParameter<string>("hepmcprod");
and in your cfg file: string hepmcprod = "source"
And in addition, in the cfg file:
string jets = "CaloJetIcone5"
string jetsgen = "GenJetIcone5"
Then everything worked great again.
The first bit seems roundabout, in a way -- isn't "m_HepMCProduct" just the name of the module that generated the MC data? wouldn't that just be "source" anyhow? Why do you need three lines? The second part looks unrelated to what I'm doing.
Let's try: iEvent.getByLabel(source, evt);
Nope, that doesn't work. I guess I need to go the long way around.
Side note: now the ECAL stuff runs out of the box, without using ecaltp.cfi. No clue why, because nothing seems to have changed. Maybe just had to do with the CMSSW version? I bet that's it.
Update: needed to add string m_HepMCProduct
to the private members of the L1RCTTestAnalyzer class (in the .h file), remembering also using std::string;
and then m_HepMCProduct = iConfig.getParameter<string>("hepmcprod"); goes in the constructor. THEN
// get MC info
Handle<HepMCProduct> evt;
iEvent.getByLabel(m_HepMCProduct, evt);
does what it's supposed to. And everything seems to be working so far.
Sept. 5, 2006
MC stuff runs fine in the analyzer. But only one of the MC objects is caught in the emulator, in the event I looked at. More formatting stuff to make it easier to look at, and to find out why.
Debugging cout statements commented out in RCT::digiInput(), RC::fillInput().
To get to event info in output files, do Ctrl-s which brings up I-Search, then search for "EmCand".
Sept. 8, 2006
Ctrl-x Ctrl-w is "Save As" command in Emacs.