[Rivet] LHCB_2010_S8758301 Rivet analysis corrected

[Alex Grecu]

Hi Andy,

OK, I understand your reluctance to add a new library dependence, 
especially if that library is HepPDT.
The question is not how many I need but how many particles is it corect 
to have and I feel I need to clarify some more things about the way 
prompt particles are selected. The algorithm is based on a longest 
living ancestor lifetime cut which implies that I need a table 
containing the lifetimes of all particles that may decay to a K0s. I 
don't think it is a good idea to hardcode just a few particles that at 
the moment may decay to these mesons but rather have a way of leave 
future developers or even users the possibility to change this table 
whenever needed. Of course,  the fastest way I can think of  is to have 
a separate .cc file or even append to the analysis file a std::set 
mapping PDG_ids to lifetime values but that is hard to maintain and may 
lead to various compilation problems when modified. I have another 
idea/proposal for you, namely to use the .info file accompanying the 
analysis to store additional data. However, at the present you have no 
field designed for this purpose so I'd like to use the 'ToDo' field. 
Obviously, this will introduce a strong dependence between the C++ code 
and the metadata but in my opinion, for a validated analysis is not very 
bad...Please, let me know of your opinion on this matter and which 
method do you think is more suited to use!

Best regards,
Alex

----------------------
LHCb Experiment
Office: 11/1-014
Phone: +41 22 76 79058
Postbox: F26500


On 9/14/2011 22:45, Andy Buckley wrote:
> Hi Alex,
>
> Thanks very much for the analysis. As I'm sure you can guess, we're 
> very happy to have it... but I'm a bit unsure about what to do with 
> the HepPDT dependence. We'd rather not introduce that on to Rivet 
> right now.
>
> How many entries from this PDT do you need? I can actually see an 
> argument for hard-coding the masses and lifetimes that you used in the 
> analysis, so that in the distant future the analysis will still 
> reflect exactly what LHCb used at the time, rather than whatever is in 
> the future's standard PDT file. Would hard-coding the relevant values 
> be possible?
>
> Cheers,
> Andy
>
>
> On 08/09/11 21:56, Alex Grecu wrote:
>> Dear all,
>>
>> I attach to this message the preliminary version of the Rivet plugin
>> code for the LHCB_2010_S8758301 analysis. The informations about the
>> paper are accesible in SPIRES (http://inspirebeta.net/record/865584) and
>> there is a link at the bottom of this page to the measured points that
>> are stored in the HepData database. In its present state the code is
>> able to reproduce all the 7 plots corresponding to the 3 tables. In the
>> "plots" directory in the archive you can see the result of a 1M events
>> run using Pythia6 stand-alone steered by agile and setup to use the
>> Perugia 0 tune. The same plots are easily obtainable using our own
>> simulation system (Gauss).
>>
>> However, since the code relies on empirical data (lifetime cuts) to
>> decide the promptness of the K_s^0 particles, it has to be linked
>> against the HepPDT library and use an external file to read this
>> information at runtime. For this purpose I added in the archive a
>> makefile and a file with masses and widths in PDT format
>> (lhcb_mass_width.mcd). Since I was not able to find a way to provide the
>> PDT file name to an analysis at runtime I opted to hard code the name.
>> There is a compilation constant PDT_FILENAME that when passed to
>> rivet-buildplugin sets the PDT file name to the value provided. Last but
>> not least, since the existing, unvalidated plugin for this analysis was
>> selected prior to my version, I was forced to modify a little the name
>> of the analysis by appending the letter "B" to its name:
>> LHCB_2010_S8758301B. Of course this breaks some links like the one to
>> the SPIRES database, but this code can be easily changed before
>> integrating the analysis into the next Rivet release.
>>
>> I tried to keep the description and title in the .info file as short and
>> clear as possible so please let me know if you prefer them rephrased or
>> changed in some other way.
>>
>> I'm at your disposal with further informations (that I may have
>> forgotten to add) and technical support to help you run and test the
>> plugin. In the meantime I'll continue to work mainly on documenting the
>> code better.
>>
>> Best regards,
>> Alex
>>
>
>