Neural networks

I've been trying to understand the differences that Mark found between the results using SGV-Tesla and Mokka-LDCPrime_02Sc neural networks. I am pretty confident that the new neural networks is better than the old ones. Not only because other plots, such as the purity-efficiency, say they present better performance, but becasue the old ones are not correct as some overtraining can be spotted.
I wrote my conclusions on neural networks down in the web page here.

Purity x Efficiency (Z-Higgs)

Here is the flavour tag purity-efficiency plot with Z-Higgs events comparing Mokka-LDCPrime_02Sc neural networks (open symbol) and SGV-Tesla neural networks (solid symbol).
The c-tag performance is similar, but slightly better for Mokka-LDCPrime_02Sc, for mid to high efficiencies. Mokka-LDCPrime_02Sc is much better for low efficiencies.

c-likeness

Get plots here .

Flavour Tagging results (so far)

I've created a new sample for LDCPrime_02Sc_p02 from the generator files at the ILC database (50,000 ZH->eeXX and about 62,000 ZZ->eeqq). I was looking at the flavour tag results using the LDCPrime_02Sc nets (note not "_p02") Roberval sent me, as well as his tuned JProb parameters and RPCutProcessor parameters. I didn't get very good results for that:

New parameters and new nets

To see if it was something to do with the new samples I then tried the old tagging:

Old parameters and old (SGV trained) nets

That was much improved, so to see if it was the new nets or parameters that were causing the problem, I tried redoing the new tag with the old nets (because it was the easiest thing to do):

New parameters and old nets

That was much better than both (although slightly smaller peak for the b sample). It looked like the b tag was okay using the new nets, so I wondered if it was any good using the new b-tag nets and the old c-tag nets, to see if it was actually just the c-tag that's a bit off:

New parameters and new b nets, old c nets

Although much better than everything done with the new nets, the b tag is still not as good as with the old nets.

Branching Ratios

We are aimed to investigate the BR of Higgs decaying into bb, cc and gg for SM Higgs. (120GeV)
In our case all other decays are the background.
We separated all flavors (separation of Muons is done at first place) and make plots of BTag, CTag and BCTag, three plots at the bottom (Red for bb events, Blue for cc events and Black for light quark events).

Using the method in Kuhl-Desch paper, we split our 20,oo0 events into Data and Sample events in 1:1.
As an exercise, we tried to find the parameters for bb/gg and cc events by setting value of parameter for gg/bb and background equals to one. The likelihood function is then plotted as shown below.(Two plots on top, first one is for cc vs gg and second one is gg vs cc)

In order to get the fitted value of the parameters, we will minimize the likelihood function. And then using the fitted value of the parameters we will find the branching ratios.

Software issues

I've come across two software issues recently, both of which are fairly old but here's a bit more information:

1. Mokka crashing when reading stdhep files - I've managed to fix this by changing a few things, but I'm now having trouble breaking it again to see exactly which one of those things fixed it. Mokka uses the stdhep reader from LCIO, but I'm not entirely sure if that uses CLHEP or not (I don't think it does). I used the HEAD version of CLHEP, Mokka and LCIO; and the most recent tag of Geant4. I also compiled LCIO with CLHEP, just in case the reader does use CLHEP. After all of that, Mokka can read stdhep.
2. LCIO can't read files with Pandora clusters and CalorimeterHits in them - I came across this ages ago, but thought it was because the file size was too large. If you do try and read one of these files, you get the error
   "*** glibc detected *** free(): invalid pointer: 0x0000000000b629e0 ***"
   After reading in the first event I think LCIO is trying to delete the CalorimeterHits twice, once for the normal collection and once for the hits associated to the Pandora Clusters. I don't know if this is a problem with LCIO or with Pandora, I'll put a post on the forums.
   

Update 12:15
When going to post about the second point, I saw there was a post in the LCIO forum "stdehepjob fails on 64 bit". Basically, Roman Poeschl tracked down exactly where the error occurs and Jan Engels fixed it in the LCIO cvs on the 29th of Septemtber.

So to fix Mokka crashing when reading stdhep on a 64bit machine, you need the HEAD version of LCIO or a tag made after the 29th of September.