If you are having trouble installing or running rivet, some of these tips might help.
If your problem still persists after following any guidelines you might find on this page, please contact the Rivet authors at rivet@… and we will try to help.
Running on Mac OS X?
I just installed a new Rivet version and now it segfaults/crashes when I try to list analyses
Do you have private analyses, i.e. ones you wrote/downloaded and built yourself, in addition to those which came built-in to the Rivet system? This is usually the problem.
Compiled analysis plugins are code libraries, and they are sensitive to the version of Rivet, because our binary interface can change a bit even with minor release updates. So when you upgrade the core Rivet library, your private analysis plugin libraries go out of date and can potentially crash Rivet when it tries to load them.
The solution is to delete or rebuild your private Rivet*.so plugins using the currently installed version of rivet-buildplugin. If it still crashes, maybe you missed one: try unsetting the RIVET_ANALYSIS_PATH shell environment variable. If it *still* crashes, maybe we did screw up and some *system* plugin from the previous version hasn't been overwritten. You could try a make uninstall in the previous version's build directory if you still have that, but I tend to just delete all $prefix/lib/Rivet*.so files and the $prefix/lib*/python*/site-packages/rivet* dirs/files from my install area, and reinstall the latest version (this should be quick, since no rebuilding is needed). Sometimes the personal touch is best...
Running gdb on Rivet
gdb can be a handy tool for debugging fiddly analysis code... although we hope it wasn't the Rivet design that forced you to do fiddly things: please complain if it was. However, running gdb on the usual rivet program does not work straightforwardly, because that's a Python script rather than a compiled binary.
Personally, I use this sort of command: gdb --arvgs python `which rivet` --analysis FOO. It finds the absolute paths to python and rivet, and runs gdb on the Python executable with the Rivet script and its options treated as arguments to python. You can do something similar via gdb python and passing the rivet path and arguments to the gdb shell's run command.
Another route is to use the rivet-nopy program, which will be found in the bin directory of the Rivet build dir -- note, it is *not* installed to the $prefix dir like rivet, etc.. This *is* a compiled program which allows you to run Rivet analyses without any Python involvement, but its functionality is very limited -- hence we don't install it and only recommend using it if all else fails.
Merging multiple runs
Merging of multiple runs of generators -- either multiple copies of the same process with different seeds so that generation is faster, or orthogonal runs to efficiently populate analysis phase space (e.g. jet pT slices) -- is very useful.
In Rivet version 1, the data format written out did not contain the statistical information required to do exact merging, and so approximate "hacks" had to be used instead (see http://rivet.hepforge.org/hg/contrib/raw-file/tip/aidamerge aidamerge for a script that assumes asymptotic error scaling suitable for normalized histograms and profiles).
In Rivet version 2, the new YODA format is fully capable of run merging with full fidelity, and the yodamerge standard script can merge runs correctly and with optional per-file weighting if wished, including automatic handling of normalized and unnormalized objects. If you want to use multiple runs, this is definitely the way to go.
This is not quite the end of the story: complex data objects constructed from multiple histograms, e.g. ratios or asymmetries, cannot be merged post-hoc since the objects needing to be merged are not the final composite ones, but the simple histograms from which they are made. This requires a more complex treatment, but will be possible in a future version of Rivet via re-running of the analysis finalize step.
"internal constants have been clobbered" error from make-plots / rivet-mkhtml
The rendering backend for the Rivet plotting system is LaTeX, which produces very nice output but suffers from the limitations and idiosyncracies of a system little changed since the 1970s. In particular, TeX was written in an era when systems with megabytes let alone gigabytes of RAM was inconceivable, and it has a fundamental memory size limitation... whose value is unfortunately system-dependent. You may encounter problems with this if writing LaTeX documents with lots of floating figures in a row: TeX will give up and ask you to give it some manual help.
For making plots with lots of points and lines, we need to tell LaTeX to allocate more memory than the usual system default. This is done via the $prefix/share/Rivet/texmf/cnf/texmf.cnf that Rivet installs. But on some systems the value that we set may be too high (as mentioned, it's not possible to work out a universally good value) and this produces the strange TeX error "Ouch---my internal constants have been clobbered" (see http://tex.stackexchange.com/questions/67014/latex-gives-me-the-error-ouch-my-internal-constants-have-been-clobbered). To fix this, you should open the texmf.cnf file mentioned above and reduce the value of the main_memory value that it sets: a suggested lower value is 12000000, but you may want to experiment a little to find a near-maximum value for your system.
SELinux security warnings
If you are running a Security Enhanced Linux (SELinux) system, you may get warning messages in the SELinux troubleshooter when trying to run an executable which uses Rivet:
"SELinux is preventing <execname> from loading /usr/local/lib/libRivet.so.1.1.0 which requires text relocation."
This is referring to Rivet's use of binreloc to improve portability when reading the installed reference histogram files. It is not a real security issue. We recommend that you use the chcon command suggested by SELinux's troubleshooter to allow text relocation on libRivet (and libRivetAnalysisStd, as well as any user-written analysis libraries). Rivet should then run as it would on a non-SE Linux system.