[Rivet] Rivet: populating high pT leading jet UE plots

[Janssen Xavier]

Hi Andy,

Thanks, ok indeed “~flat” ptHat is another solution and it is probably better in fact.
I’ll probably still need to add several run together as I’ll run in the cern farm but that 
can go trough auxiliary 2D histo to be added and taking profile afterwards outside of 
rivet. 

Cheers, Xavier.

PS: Rivet 2.0.1 is mostly there in fact and being validated in CMS software although 
not yet in a real production mode. as far as I understand. Maybe I can play the guinea 
pig as it would help me in the job parallelisation and profile adding, right ? 
Let see … I’ll ask where we really stand with that update process.


On 17 Apr 2014, at 11:05, Andy Buckley <andy.buckley at cern.ch> wrote:

> On 16/04/14 23:53, Janssen Xavier wrote:
>> 
>> Dear Andy,
>> 
>> I am trying to find an economic way to produce leading jet UE plots
>> and populate them with reasonable statistics at high jet pT (let say
>> up to 50 GeV). I was thinking of doing many runs and keep 2D histo
>> instead of profiles (yes I am still working with AIDA version within
>> the CMS framework, so profile adding does not work … )
> 
> D'oh! The latest version, 2.1.1, is now working fine in ATLAS
> (integrated into our ROOT histogram service and everything) so you can
> let the CMS guys know that there shouldn't be any technical blockers to
> upgrading...
> 
>> and then hack
>> a bit to produce the summed profile out of all AIDA files.
> 
> In the past we used profiles for this in the usual way, but then used a
> *nasty* script called something like rivet-mergeruns which was
> hard-coded to paste together groups of bins which "safely" corresponded
> to the incoming jet slices. Yuck, but it worked for us for a long time
> -- enough to do all the Professor and ATLAS Pythia tunes! Rivet2 makes
> it much easier, of course. But I just thought I'd mention that you can
> still do run merging with AIDA profiles... it's just a lot more manual
> than you'd like.
> 
>> As I am
>> rather using rivet as a way to get fast through tunes but not really
>> wanting to use the plotting functionality, I was thinking about doing
>> also some run with some pTmin cuts. If I do that I am afraid I’ll
>> have to bookkeep each events (tuple of ptHat, jet Pt, multiplicity,
>> ptsum) and match them afterwards in different ptHat region, so is
>> there a way to access the the actual pThat value of an event ?
> 
> Not really -- it doesn't exist as a well-defined thing beyond 2-parton
> final states, and each generator writes the relevant partons in
> different ways (or not at all). As mentioned above, sliced runs can
> already be used but some bookkeeping is unavoidable.
> 
> However, I have a nicer suggestion: use a weighted run with pThat
> enhancement, i.e. the sampled events will be distributed according to
> dsigma/dpThat * pThat**4 or similar (and then each event down-weighted
> by ~ pThat**-4). Certainly PYTHIA6, Pythia8, and Sherpa can all do
> this... and I think I also used it in Herwig++ in the past. Such an
> enhancement makes it quite easy to cover a very wide jet pT spectrum in
> a single run because it distributes the statistics much more widely in
> pT than in reality, where almost all will be at low pT (hence the usual
> practice of slicing). This way is both faster and avoids the need for
> bookkeeping sliced runs.
> 
> Hope that helps,
> Andy
> 
> -- 
> Dr Andy Buckley, Royal Society University Research Fellow
> Particle Physics Expt Group, University of Glasgow / PH Dept, CERN
> 
> -- 
> Dr Andy Buckley, Royal Society University Research Fellow
> Particle Physics Expt Group, University of Glasgow / PH Dept, CERN