[Rivet] question of using Rivet. final state radiation and different transverse momentum threshold in ZFinder

[Andy Buckley]

On 21/05/15 15:40, Deepak Kar wrote:
> Is there a chance that the muons are not sorted by pT?

I think there is not a guarantee that they are. I'm not sure what the
benefit of LeadingParticlesFinalState is -- you could just use a muon
IdentifiedFinalState and retrieve all muons sorted decreasing in pT with
the particlesByPt method.

The better way is to use the constituents, though: that way you know
that the muons you are cutting on are the appropriate ones. I forget the
exact algorithm that's used, but since mass windowing is involved in the
selection it may be that the hardest muon(s) in the event were not
viable Z decay products. If the sorting isn't the issue, this could be
the source of the discrepancy.

In recent Rivet versions you can explicitly sort Particle containers
with a call to sort(some_particles, cmpMomByPt): you can use this to
avoid the "9 && 14 || 14 && 9" construct near the end of your code.

Andy

PS. You should also make sure to use "*GeV" on your unitful cut values.
And the new Cuts system in Rivet 2.2.x should also help to make this
code more readable.


> On Thu, May 21, 2015 at 4:35 PM, David Grellscheid
> <david.grellscheid at durham.ac.uk> wrote:
>> Hi Yu-hsiang,
>>
>> can you please attach the code files rather than copying them. The
>> formatting is all messed up.
>>
>> Thanks,
>>
>>   David
>>
>>
>> On 21/05/2015 14:07, Yu-hsiang Chang 張祐祥 wrote:
>>>
>>> Hi Deepak,
>>> Thanks for your reply and suggestion. It works that requires the event has
>>> leading muon pT>14 to make the 2 muons have different pT cuts (14 and 9
>>> GeV). (the way [1])
>>> But later I find another way to do it. I require the 2 muon constituents
>>> of Z/gamma to have pT>14 and >9 respectively. (the way[2] )
>>> However, once I count the entries in my histogram, I find way [1] gives me
>>> 102 events,and  way [2] gives me 111 events.
>>> And if I print (use "cout") the leading muon size(the # of leading muon)
>>> in way[2](from the more entries we know [2] is the loose
>>> requirement),sometime it shows it has "zero" leading muon but it still pass
>>> [2].
>>> Like
>>> below----------------------------------------------------------------------------
>>> Begin processing the 711th record. Run 1, Event 711, LumiSection 1 at
>>> 21-May-2015 12:12:24.093 CEST# of leading muon:0# of Z boson:1# of muon from
>>> Z:2i:0  i-th muon pT:14.1995i:1  i-th muon
>>> pT:12.1323----------------------------------------------------------------------------
>>>
>>>
>>> Do you know what happens and why [1] and [2] give 2 numbers?
>>> The generator used here is Pythia6 and produce DY to MuMu event.
>>> The essential code of my Rivet plugin( [1] and [2] ) is shown in below.
>>> Thanks.
>>> Yu-hsiang
>>>
>>> [1] The first way: require the leading
>>> muon----------------------------------------------------------------------------
>>>      void init() {
>>>        // Full final state       const FinalState fs(-5.0, 5.0);
>>> addProjection(fs, "FS");             // Z finders for muons       const
>>> ZFinder zfm(fs, -2.4, 2.4, 9*GeV, PID::MUON, 15*GeV, 1500*GeV);
>>> addProjection(zfm, "ZFM");
>>>         // leading muon        LeadingParticlesFinalState
>>> muonfs(FinalState(-2.4, 2.4, 14.0*GeV));
>>> muonfs.addParticleId(PID::MUON);       addProjection(muonfs, "LeadingMuon");
>>>        // Histograms      _hist1MZ_of_MuMu            = bookHisto1D(2, 1,
>>> 3);// preFSR detector acc
>>>      }
>>
>> _______________________________________________
>> Rivet mailing list
>> Rivet at projects.hepforge.org
>> https://www.hepforge.org/lists/listinfo/rivet
> 
> 
> 


-- 
Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow