[Rivet] Minor problems in Rivet 1.5.0

[Andy Buckley]

Only to blame for LWH... not the AIDA that's it's based on! If we'd had
a clearer picture when we started, Rivet would always have used LWH
objects directly, without any of the AIDA API getting in the way.

YODA is fairly well progressed, via a very slow accumulative procedure
with regular redesigns... getting it "right" has been fraught with
multiple U-turns, but I think it's converging to something quite nice.
Your input would be very useful, I think: sorry for not involving you,
but I thought you were keeping your distance from Rivet things :)

We have 1D histograms and profiles, based on a 1D distribution object
which keeps track of the required moments for the bins (x and y), and
for the overall histogram, underflow/overflow, etc. This is arguably a
bit heavyweight (HWH?) but also allows full reconstruction of all
histogram features, completely correct statistics in histo addition,
etc. And we don't require bins to be contiguous, so gaps are permitted
and the annoying Rivet vs. HepData "different binnings so I can't make a
ratio plot" issue will go away. All data objects can be arbitrarily
annotated for metadata, which could provide a de facto standard
mechanism for passing out cross-section information.

My major queries are over persistency: I've long pondered how to get
around C++'s lack of introspection, and strong typing vs. loading
collections of mixed data object types from file. The major motivations
for the persistency design are that merging of multiple runs to increase
statistics should be completely standard, the bin-chopping stuff used
for profile merging should become obsolete (but maybe still functionally
present for those odd occasions when it is wanted), and the "booking
histograms from DataPointSets" stuff from Rivet should be part of the
histogramming system... but with the ability to query more information
than just the binnings: for those observables where the normalisation
just *can't* be obtained from even the most perfect event generator,
this will allow us to remove the hard-coded normalisations and hence
keep that part also auto-synced with the HepData output.

I now need to find a bit of time to write a proper AIDA XML parser (any
recommendations of embeddable XML parsers other than TinyXML?) and then
I think we're 90% ready to start converting Rivet... on a branch. I'm
going to have a couple of project students this summer working on Rivet
& Professor things, and one seems keen and competent to work on
histogramming, so maybe they will add 2D histograms and improve our
plotting.

Andy


On 18/03/11 20:29, Leif Lönnblad wrote:
> On 2011-03-18 16:46, Andy Buckley wrote:
>> Wow, please do!
> 
> Done.
> 
>> I thought that reset *was* the Boost shared_ptr way of
>> assigning a shared ptr value, and was in some way more suitable than the
>> operator=, cf. operator[] on std::map -- I didn't realise that they had
>> different semantics about the implied ownership. Seems I have some
>> re-reading of the Boost pointer definitions to do. Thanks, Leif :)
>>
>> I believe that there is still a problem in that the projection
>> shared_ptrs are then put into a std::set, but that operator<(shared_ptr,
>> shared_ptr) is not quite what you think it should be. But perhaps by
>> changing the ownership as above, this issue is also resolved: the
>> comparison operator distinction also related to the ownership.
> 
> Well, again according to the boost reference manual, the operator< for
> shared pointers is designed to be used in sets and maps.
> 
>> I can also now test putting back the fixed versions of some singletons
>> as well... when I tried to do this before, it turned out that cleaning
>> them up properly resulted in a segfault at the end of every Rivet job!
> 
> Isn't the whole point that they should clean themselves up in the end?
> 
>>
>> We'll have to test this a bit, but combined with a few more analyses it
>> would be a nice thing to have in a 1.5.1 patch release, while we get on
>> in parallel with histogramming improvements.
> 
> Sounds good. I wouldn't mind hearing what you have in mind for the
> histograms. Although I'm to blame for LWH, I may have some input to the
> discussions.
> 
> /Leif
> 
> 


-- 
Dr Andy Buckley
SUPA Advanced Research Fellow
Particle Physics Experiment Group, University of Edinburgh

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.