[Rivet] ATLAS ttbar+jets analysis

[roman lysak]

   Hi Andy,



On 21/07/14 16:14, Andy Buckley wrote:
> Hi Roman,
>
> I've seen this analysis already and realised the issue. This is a case
> where it would have been nice if we could have worked with the authors
> to discuss the new projections and get them directly into the Rivet
> trunk rather than need to do it retrospectively.
>
> It would help us if you/they could provide diffs with respect to the
> latest Rivet version -- have these modifications been made on top of
> version 2.1.2?
they have been made w.r.t. version 2.1.1, as far as I know.

>   We need to make sure that we don't undo our own
> developments when merging this. Having looked at the source of the
> FromElectroweakDecay projection, it doesn't actually do what that name
> suggests, so I would like to change that to match the sort of scheme
> that we've used for Particle.fromDecay(), or perhaps define IsPrompt /
> IsNonPrompt particle classifiers.
>
> Getting a new Rivet out with these features and some others in time for
> the BOOST conference in mid-August is high on my priority list, so I'll
> be back in touch. But if you can talk with Will and Alexander (right?)
right, cc-ing to them, so that the communication is hopefully quicker

> to make minimal patches (or ideally an hg branch that we can clone,
> modify and merge) that we can apply, that would help a lot.
Alex, Will, could you try to do as suggested by Andy, i.e. at least try 
to compare to Rivet 2.1.2?

Thanks a lot,
   Roman

>
> Thanks,
> Andy
>
>
> On 21/07/14 15:03, Roman Lysak wrote:
>>    Dear Rivet authors,
>>
>> in ATLAS, we've got another analysis we would like to eventually get
>> included into Rivet (right now, it's being validated): ttbar+jets analysis.
>> However, while implementing this analysis, the authors made changes to
>> some core Rivet routines (FastJet, Jet, and DressedLepton projections)
>> and also added one new Projection (FromElectroweakDecay). I'm attaching
>> the changes they made.
>>
>> We would like to ask you, what would be the best way to proceed: whether
>> you would be willing to accept any of the updates to the core routines
>> or you would prefer to have everything implemented inside the analysis
>> routine (in the second case, the validation/re-validation will probably
>> take longer, obviously :)).
>>
>> Thanks,
>>    Roman
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Rivet mailing list
>> Rivet at projects.hepforge.org
>> https://www.hepforge.org/lists/listinfo/rivet
>>
>