[Rivet] LHC analysis database

[James Monk]

Hi Peter,

I thought we were already aware at some level of this work - we'd briefly discussed Weiler et al.'s "ATOM" project, and I guess this is the same thing.  As far as I understood it, their setup was initially comparing not-unfolded data directly to particle level MC, but with a system of checks to make sure the unfolding would not have affected the results of the comparison - basically finding regions of BSM phase space that can be eliminated even without unfolding.

Obviously in an ideal world the BSM measurements would be unfolded and put into Rivet, but neither we nor the ATOM people can force them to be so, and for the initial searches not unfolding is not completely unreasonable, despite our preference.  Maybe something like this is as good a place to start the conversation as any.  We considered inviting Weiler at al. to the last Rivet collaboration meeting, but there wasn't enough time to fit it in the agenda, so a dedicated discussion with them would be useful.

cheers,

James

On 20 Jun 2013, at 10:30, Peter Richardson wrote:

> Hi Leif,
> 
>  So I think its going to be less of an issue than I originally feared. There are a lot of BSM people who spend a lot of time talking and do nothing other than make work for other people and make me wish I could have made the first session of Les Houches. However talking to the people who have done something i.e. Andy Weiler and Ben Fuks, afterwards I think they are more open to collaboration. They have done a lot of work, particularly Weiler, which in his case is based on Rivet anyway, and if we can get that into Rivet in some form it would be a good thing. They are much more open to working together to come up with a good solution and are reasonable people who I think the Rivet people could work with. To me the main issues are technical related to storing their efficiency maps etc as the data isn't corrected and things of that nature. They seem open to
> collaboration with the Rivet developers to discuss things and come up with a workable solution. So I would propose that as a first step we arrange a phone/video meeting to discuss things with them and see how it goes
> 
> Peter
> 
> 
> 
> 
> On Thu, 20 Jun 2013, Leif Lönnblad wrote:
> 
>> I'm adding the MCnet management to the discussion, since I think this
>> possibly is a political problem which needs to be addressed.
>> 
>> Not being part of it myself, I often get the feeling that the BSM
>> community behaves more like gold diggers than scientists. A huge amount
>> of work is put into sifting through data looking for new physics, and it
>> seems like the people involved forget that they actually do real
>> measurements which could be of interest for other people as well. Now,
>> I'm not sure how much extra work it would be to make these analyses
>> useful (in my world "making useful" is basically equivalent to "putting
>> into Rivet" ;o) but considering how large the BSM community is, there
>> should be enough of manpower for doing it. If they won't do it
>> voluntarily, maybe we should consider talking to the heads of the
>> experimental collaborations to put some pressure from above...
>> 
>> /Leif
>> 
>> 
>> On 2013-06-19 18:58, Hendrik Hoeth wrote:
>>> So ... if they don't take the efficiencies into account, they can't
>>> compare to MC. If the take the efficiencies into account, what
>>> difference does it make for them to code them in Rivet or somewhere
>>> else? I can't see the drawback of using Rivet.
>> 
>> 
>> On 2013-06-19 18:38, Peter Richardson wrote:
>>> Hi Guys,
>>> 
>>>  So I'm currently sat in Les Houches discussion which I think is a bit
>>> worrying. This is being pushed by a combination of Andy Weiler from DESY
>>> and the mad analysis people, who are more serious and competent people,
>>> together with a number of others who are less competent.
>>> 
>>>  So what they seem to want is a database of the, entirely, BSM analyses
>>> they have been coding to look at different models at the LHC. They seem
>>> to be determined not to use rivet as they don't want to be bothered to
>>> code the efficiencies they need as the data is not corrected into a
>>> rivet analysis, although my understanding is Weiler's stuff is based on
>>> rivet analyses somehow.
>>> 
>>>  It's not entirely clear to me what they are planning but it looks like
>>> they are coverging on something based on madanalysis with simpler
>>> analyses in python and then more complicated ones in C++
>> 
> _______________________________________________
> Rivet mailing list
> Rivet at projects.hepforge.org
> http://www.hepforge.org/lists/listinfo/rivet