hosted by CEDAR HepForge

Ticket #215 (assigned task)

Opened 2 years ago

Last modified 8 months ago

Finish validation framework

Reported by: fsiegert Assigned to: fsiegert (accepted)
Priority: blocker Milestone: Release 1.3.0
Component: Validator Version: HEAD
Keywords: Cc:

Description (Last modified by buckley)

For a given Rivet version, we want to be able to document which analysis/generator combination is known to work (and how to run it). A framework should be created that makes it as easy as possible to generate such a validation table, in the beginning exemplifying it for e.g. two analyses and two generators.

Gen1 Gen2
Ana1 working not tested
Ana2 not working working

Per analysis (linked from each row title):

  • Doxygen documentation similar to Debrecen tutorial

Per generator (linked from each column title):

  • Standardized script to run the generator (assuming given parameter files)

Per analysis/generator combination (linked from each cell):

  • Parameter files (also for multiple runs per analysis)
  • Histogram files
  • Plot page

Most of the work is probably in the parameter files for each A/G and in figuring out a way to determine working/not working (maybe with respect to a previous version of Rivet or, more difficultly, the generator). The latter might not need to be automatic at first.

There will be two separate phases implemented in separate "scripts", probably in Python:

  1. Distributing the jobs to the GRID/batch system/...: This will operate on a column (optionally with analysis-exclusion) and start a daemon in the background which knows about all jobs submitted and their status. It would be good to have it persistable, such that it can be restarted in a certain state, should it get killed accidently (cf. Pickle).
  2. Analysing the output of jobs: Plots, comparison RivetA vs. RivetB or GenA vs. GenB etc., creating the matrix, ...

The distribution tool needs to be able to run essentially arbitrary scripts for each generator, to allow optimisations like caching Sherpa libraries and integration results, or running with sockets/FIFOs rather than AGILe. The Rivet configuration and analysis merging parts can be less general since the interface is constant.

The distribution tool should be written so as not to preclude integration of validation tests like this into a continuous build system like Hudson (used by Herwig++): https://hudson.dev.java.net/

Change History

29/09/08 12:41:16 changed by fsiegert

  • status changed from new to assigned.
  • description changed.

29/09/08 14:03:37 changed by buckley

  • version set to HEAD.
  • milestone set to Version 1.2.

29/09/08 14:20:32 changed by buckley

  • description changed.

03/10/08 14:08:28 changed by buckley

  • description changed.

04/12/08 17:26:20 changed by buckley

  • milestone changed from Version 1.2 to Version 1.1.2.

Enough should be present for 1.1.2 that we can validate the YETI analyses. I think this is pretty much already the case. We're approaching the stage where we can close this ticket and make more specific issue tickets like "use Ganga", "support multi-run analyses", etc.

04/12/08 17:26:35 changed by buckley

  • component changed from External to Validator.

29/01/09 14:29:45 changed by buckley

  • priority changed from major to blocker.

05/05/09 18:06:29 changed by buckley

  • summary changed from Validation framework for Rivet analysis/generator combinations to Finish validation framework.
  • milestone changed from Version 1.1.3 to Version 1.2.

Moving this to 1.2.0, since the description is still useful, but what's already there should be sufficient for 1.1.3.

06/07/09 15:32:28 changed by buckley

  • milestone changed from Version 1.2 to 1.1.4 release.

The Python script builder that I made for Pythia worked nicely for 1.1.3 validation, but I didn't use the rest of the validator framework. I think that this kind of script builder, combined with a plugin system for swapping the generators for which the scripts are built, is a simpler and more flexible method than the super-clever system we have currently. Also, there are signs of a path to automatically merging different kinematic runs via the new Rivet analysis metadata plans.

Moving this to 1.1.4, with the aim of using the completed system for Rivet 1.1.4 validation in ~August/September

25/11/09 14:31:47 changed by buckley

  • milestone changed from Version 1.2.0 to Version 1.3.0.

Not for this release, unless anyone's feeling very enthusiastic. We'll use Hendrik's scripts for the systematic version-version checks.