1 / 9

Separate distribution of the analysis code (and more)

Separate distribution of the analysis code (and more). P. Hristov 19/03/2014. Reminder. After a lot of discussions in PWGs (and outside) Jan Fiete presented the proposal on 10/02/2014 Motivation Some parts of AliRoot change more frequently than others

shay-young
Download Presentation

Separate distribution of the analysis code (and more)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Separate distribution of the analysis code (and more) P. Hristov 19/03/2014

  2. Reminder • After a lot of discussions in PWGs (and outside) Jan Fietepresented the proposal on 10/02/2014 • Motivation • Some parts of AliRoot change more frequently than others • AN tag often only for analysis code • Proposal • Split AliRootinto two parts • PWG = (PWG, PWGCF, PWGDQ, …): 9 folders in total = 0.3 GB • CORE = STEER, subdetectors, OCDB, OADB, ANALYSIS, etc.: i.e. everything else = 0.9 GB • Separate repositories • Separate tagging • CORE for example monthly, or on request • PWG twice weekly (like AN tags now)

  3. Reminder: Tagging • Separate tagging, for example • CORE for example monthly, or on request • PWG twice weekly (like AN tags now) GEANT3 ROOT COREv1 COREv2 PWGv1 PWGv2 PWGv3 PWGv4 PWGv5

  4. Reminder: Some Comments • Advantages • Stable CORE part • Regular PWG tags lead to faster build & smaller archive • Committers to PWG don't need to update CORE part on each commit • Implications for users • Need to download one package more • Detector developers may not need PWG package • Need to build one package more • May build into same directory, no change in includes, library path required • AliRoot download script can do this transparently • Implications for train operators • Selection of PWG tag instead of AliRoot tag, dependencies automatic • Decision: split the PWG code in a separate package after QM

  5. Discussion • The main question is how we keep consistency between the packages • Other experiments use Code Management Tools: quite heavy • The versioning can be improved and the dependencies between the packages described in a way similar to what RPM and deb do • The solution should be extensible to the external packages (Geant3, Geant4, BOOST, CGAL, FASTJET, etc.) • We can use the FairRoot way of distribution

  6. FairRoot distribution method • “Meta-repository” for the external packages + compilation macro (configure.sh). Example: dec13 release (or FairSoft from github) • Git 1.8.4 • HepMC 2.06.09 • Millepede-II V04-00-01 • ØMQ 3.2.24 • CMAKE 2.8.11.2 • BOOST 1.54.0 • ROOT 5.34.13 • Geant 4 9.6.2 • Geant 3.21 v1-15 • Geant4_VMC v2-14a • VGM v3-06 • PYTHIA 8 180 • GSL 1.15 • GTEST 1.7.0 • PLUTO 5.37 • PYTHIA 6 6416 • Core package (FairRoot) • Experiment specific code, i.e. CbmRoot

  7. Proposal for a new AliRoot distribution method • Meta-repository for the external packages + installation script • Links to the needed versions of the original distributions: repositories, tarballs, etc. • ROOT • Generators • Transport packages & VMC • Additional software • Patches for the original distributions • Distributions, not available in original form (i.e. DPMJET) • Interfaces to packages (i.e. THijing) • The versions in each release will be decided on a dedicated offline meeting taking into account the requests from the PWGs • Core package (STEER, detectors, ANALYSIS, etc.) • Analysis package (PWG, PWGXX)

  8. Benefits • Clear set of versions for each release of external packages, core and analysis • Easy introduction of new external code • Clear set of patches (now they are on the build server, but rarely people take them) • Low/high frequency of changes => low/high release frequency • Smaller distribution size for the frequently updated code (PWG analysis) • Easier installation • Better access control and notification

  9. Plan • Analysis packages (2-3 weeks) • Split gitrepositories • Split cmakefiles. Profit to implement the “native CMake build”, if not yet done • Adapt build server • Adapt train system • Adapt MonALISAscripts • Adapt AliRoot download scripts • Adapt documentation • External packages (2-3 weeks) • Prepare list of external packages with their versions, interfaces, patches, etc. • Create the meta-repository and the compilation script • Extensive tests on different platforms • Adapt the build system • Modify the versioning in CORE and introduce the requirements for the external packages • Exclude the existing external packages from CORE • Documentation • CORE (1-2 weeks) • Modifications in CMake build system and the servers

More Related