[Rivet] Bugfixes

[Andy Buckley]

On 01/12/14 23:04, Andrii Verbytskyi wrote:
> Dear Andy,
> 0)
>>> 0) One should run autoreconf to make "make" working.
>>
>> You mean after check-out from version control? That's always the case,
>> but it shouldn't be necessary from tarballs -- so please let us know if
>> it's the latter and we'll look into it.
> 
> Yes, I use tarball. I assume your system is quite modern and therefore
> configure requires aclocal-1.14 or something which is newer than mine
> aclocal-1.11. I assume you are using only basics of autotools and the
> version of aclocal doesn't matter. But I don't know how to turn off the
> versioning.

Hmm, that's very strange. An autotools tarball shouldn't need the user
to have autotools installed at all: the configure etc. scripts should be
pure sh, and the Makefile.in templates just get transformed into proper
Makefiles by the scripts.

> 1)
>>> 1) Compilation with
>>>  ./configure --prefix=/usr --libdir=/usr/lib64 --enable-root 
>>> doesn't work at all for me --  some Cython files are missing, but
>>> I don't need python, I'm interested in ROOT only, so I skip it.
>>
>> Ah, good point -- ROOT compatibility must have been disabled when I made
>> the tarball. We'll fix that with the next release.
> OK. I mean I don't need it and therefore I don't debug it.

Oh, I thought you meant that the rootcompat.cpp file was missing. What
Cython files were reported as missing when Python wasn't disabled? It
worked for the LCG software group when they made their build for
experiment use. We do require a new version of Cython for anyone who
wants to rebuild the interface, but like the autotools scripts this
shouldn't be needed for just building the tarball.

> 2)
> 
>> Thanks, I'll apply those patches.
> That would be great.

It's done on the trunk. I hope we can get a 1.3.1 release out before
Christmas (remaining targets are 2D histogram overflows and fixing a 2D
object limitation in the YODA format I/O).

> However I should mention that with "conversion with python scripts" approach
> no python==no conversion. C++ binary would look better.

We discussed that ;-) The scripts give us a degree of flexibility and
decoupling that we can't get with binaries, as well as being a lot
easier to do powerful things. We could distribute source for a format
converter binary in a "contrib" area, though, if you have a working one.
Some other people might prefer that, too.

> 3)
>>> P.S. What about ROOT support?
>>
>> It's still on our to-do list, but other things in the design,
>> implementation and plotting integration have been higher priority for
>> us. Since it will involve a breaking interface change to the reader and
>> writer classes, reading and writing ROOT files will have to wait until
>> YODA v2. For now the in-memory conversion routines are hopefully good
>> enough -- please let us know if you have any issues or suggestions about
>> those.
> If I will find some issues I will report. 

Thanks :-)

> Also...
> Maybe that would be interesting for you but on the recent HERA workshop
> Rivet was mentioned multiple times and some people (e.g. Hannes Jung)
> were trying to convince the others to submit their analysis to Rivet
> repository.
> As for me that is a VERY good idea, but it requires some manpower. Few
> people will do that. And if it requires a learning of some very new
> histograming system like YODA the chances to have the analysis in Rivet
> going even lower. Actually nobody at HERA symposium(I've asked them!)
> was familiar with YODA, even Hannes, as far as I understood.

Rivet uptake is actually increasing fairly well -- it's still something
that a minority of experimentalists have hands-on experience with, but a
surprising number have embraced it. And I've had quite a bit of feedback
about how nice the interface is, including praise for YODA: people are
surprised that they don't need to rewrite the workarounds that ROOT
requires!

Unfortunately improving an interface means breaking compatibility with
bad designs, and all my experience with ROOT tells me it's a bad design.
>From the Rivet user point of view, there is virtually no difference
between ROOT histogram objects and YODA ones, except that you don't have
to write workarounds for the ROOT global state or non-handling of
weighted fills and bin widths/areas. Internally, work that we are doing
for handling multi-weighted events would be much more difficult if we
had to deal with the ROOT system's approach to histogram object
ownership, uniqueness, and lifetimes. Having support for several
different histogram codes & formats in Rivet would be incoherent, which
is against our design aims, and since I've seen many cases where ROOT
files (an undocumented binary format) are only readable in particular
versions of ROOT, I think it would be a very dangerous choice for
long-term data storage.

Some will disagree with this but that's their prerogative :-)  We
thought long and hard about whether ROOT would meet Rivet's requirements
-- it's obviously easier to use something that already exists -- and
eventually decided that it did not, and we needed to make something new
that didn't have those downsides. That's where YODA started... and
continues to evolve, because doing histogramming really well turns out
to be quite hard!

> So, having
> a ROOT support would be a big deal for the preservation of results of
> old (e.g. HERA) results for the future. In the best case having PAW also
> would be a very nice bonus...

No :-)  Some code needs to die. If analysis data can't be dumped into a
simple text format (low edge, high edge, value, error) and the logic of
when to call "fill" isn't equally valid with another histogramming
package, then there are bigger problems than our level of ROOT support.

> P.S. I'm sorry, I forgot if I send you Rivet patches. Did I?

I don't think I saw them. Please (re)send to rivet at projects.hepforge.org
 (that and YODA dev list now re-added to CC)

Thanks again,
Andy

-- 
Dr Andy Buckley, Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow / PH Dept, CERN