search

ytatus94 / Higgsino

The NUHM2 Higgsino study
0 stars 0 forks source link

Brian's mail 20170619 to 20170814 #26

Open ytatus94 opened 7 years ago

ytatus94 commented 7 years ago

Hi Yu-Ting,

this error comes from code trying to calculate the final state number as encoded by SUSYTools. In this case it is found the parent particles stop and chargino and we don't have a number for this process, I think. So either you have MC sample which is not fully stop-pair production, or the MC truth traversal is getting confused. If you are not asking for the true final state, then this won't matter for you.

Could you point me to your data sample, so I can take a look?

Cheers, Brian

ytatus94 commented 7 years ago

Thanks Yu-Ting, looking at these files, it seems it is mostly chargino-neutralino production, but there are a few events with a stop as an initial BSM particle. Can you tell me how these samples were generated?

ytatus94 commented 7 years ago

That was very helpful. It looks to me like madgraph is generating chargino pair production through an intermediate stop in single stop production. The cross section for this is very low, but non-zero, which is why you get these occasional errors. Unless you are doing reweighting of the events based on the SUSY final state, you can pretty safely ignore the error.

I have another about the simple analysis. Because I got some distributions which looks interesting, I want to investigate it. Is there a way to get the parent information? I look into other simple analysis example but I don't see it yet. If you know there is an example doing this, then could you please point me which one it is? Thank you very much.

That is not yet implemented, but you are not the first one to request it, so I will have to implement something. Do you already know what exact information you want? For TRUTH3 samples, I think all you can get is the type of parent particle that generated a given lepton, not the full kinematics.

ytatus94 commented 7 years ago

Hi Yu-Ting,

Hi Brain, I have questions about the simple analysis package again. I was asked to normalized the truth distributions to the luminosity. But I don’t know how to get the weight information in simple analysis package, such as event weight, lepton weight, jet weight, pileup weight. (I don’t think truth contains pileup weight information, is it correct?) Could you please teach me how to do this or point an example to me? Thank you very much.

The only scaling which is currently supported is the event weights which is automatically taken into account unless you specify the command line option: "-w -1" to disable event weights. The other corrections doesn't really make sense at truth-level, I think. For normalizing event counts in the signal regions, it should be very simple as the text files writes out the acceptance in the text files (3rd column) for each signal region and event weights is accounted for. So these just needs to be scaled by the product of the cross section and luminosity. However, I assume you want to scale some histograms produced by the code? In that case they are also already applying event weights, so you just need to normalize them to the total number of weighted events and then scale it up again. The total events you can again get from the text file which should have a line like this: OneLeptonMultiJets2015__All,100000,100457,100993 where the first number is the actual number of events and the second is the sum of the event weights which is what you want. The last number can be ignored.

For uploading the code you can either make a merge request if you made your own clone in gitlab or just send me the analysis code by email.

I hope this helps, Brian

ytatus94 commented 7 years ago

Hi, Yu-Ting,

Hi Brain, Thank you for your quick reply. I want to ask a stupid question. As I know acceptance = number of events pass truth / number of all events. From your reply, do you mean the acceptance is the same as event weight because you said I can multiply the acceptance to cross section and luminosity to get the weight?

Not quite. When the code calculates the acceptance, it does it as sum of event weights for passing a signal region divided by the sum of all event weights. So the acceptance numbers are corrected for event weights (the ones from the generator). So multiplying with cross section and luminosity just gives you the expected number of events.

What I want to do is to scale the kinematic variable distributions in ntuple to the corrected luminosity. The ntuples save the signal objects but the objects are not necessary in the signal region. They only pass some pre-selections. If I use the second number in the "XXXXX_All, num1, num2, num3", then I still need to know event weight of that event, Is it correct? I used weight = (Xsec filter efficiency luminosity / sum of event weight) event weight lepton weight jet weight pileup weight for the reconstruct level. For the truth level, we don’t have lepton weight, jet weight, and pileup weight. Then I can set them to one. But the event weight information is missing. The output text file only contains the sum of the event weight. Is there a way which I can get the event weight for each event?

Ah, for ntuples it is also not so difficult, since the event weights are stored in the branch: "eventWeight" So you can just use that when you are making plots. Note also that the ntuples by construction contains all events (even the ones not accepted at any stage). Therefore you can also recalculate the sum of event weights by doing:

int num=ntuple->Draw("eventWeight","")
float sum=0;
for(int ii=0;ii<num;ii++)
 sum+=ntuple->GetV1()[ii];
cout<<"Sum of event weights: "<<sum<<endl;

Cheers, Brian

ytatus94 commented 7 years ago

Hi Yu-Ting,

actually my code and the text files should provide the same answer, so if you prefer to use the text file for the overall normalization that should be perfectly fine. In any case it is a good check to make.

Cheers, Brian

ytatus94 commented 7 years ago

Thanks Yu-Ting,

thanks very much for the code. The main git repository is protected against direct upload, so one has to go through a clone or, as you did, send me an email. Very good point about putting this in the README. I'll update it later today when I include your file.

Just briefly looking at the code, can I ask why you did:

  TLorentzVector dilepton(baselineLeptons[0].Px() + baselineLeptons[1].Px(),
                                 baselineLeptons[0].Py() + baselineLeptons[1].Py(),
                                 baselineLeptons[0].Pz() + baselineLeptons[1].Pz(),
                                 baselineLeptons[0].E()  + baselineLeptons[1].E());
         mll  = dilepton.M();
         pTll = dilepton.Pt();

instead of using:

         // mll = (baselineLeptons[0] + baselineLeptons[1]).M();
         // pTll = (baselineLeptons[0] + baselineLeptons[1]).Pt();

as the latter should have the same effect unless there is a bug in the framework?

Cheers, Brian

ytatus94 commented 7 years ago 
auto dilepton = ...

should also work - I'll test it out before putting in the new version. I normally try to avoid having explicit use of the individual components as it is easy to have typos and is less easy to read.

ytatus94 commented 7 years ago

Hi Yu-Ting,

I was just testing out your code and trying to see if a few things could be written a bit more compact, when I found an inconsistency in how you determine the lepton channel type. If you have for instance two muons and one electron and the electron is softer than the two muons, i.e. "mme" then channel gets set to 3 and not 0 as indicated in the comment because only Pt of the leading muon is compared. If you want to have the channel assigned as per the comment, you can do:

     int channel = -1;
     if (nSignalLeptons >=2 ) {
       if (signalLeptons[0].type()==ELECTRON)
        channel = (signalLeptons[1].type()==ELECTRON) ? 1 : 2;
       else
        channel = (signalLeptons[1].type()==ELECTRON) ? 3 : 0;
     }

Let me know what is the correct thing to do, before I check it into git.

Cheers, Brian

ytatus94 commented 7 years ago

Hi Yu-Ting,

thanks for the confirmation. I put a fixed version into gitlab here:

https://gitlab.cern.ch/atlas-phys-susy-wg/SimpleAnalysis/blob/master/Root/EwkNUHM22016.cxx I didn't actually see any difference in my test sample, but you might want to retry on yours.

Cheers, Brian

ytatus94 commented 7 years ago

Hi Yu-Ting,

indeed this variable will be default mcEventWeight (remember that some samples will have multiple due to PDF variations), so if you store that in the ntuple and use that when filling histograms you should be ok. If you fill histograms directly in the simpleAnalysis code itself, it will automatically be used. Note that technically you don't need to fill it in the ntuple as it will be the same as the "eventWeight" variable.

Cheers, Brian