Citations from CMS documents

• from Report of the CMS Data Management RTAG

  A The RTAG Process

  The CMS data management RTAG was initiated on June 23, 2004 by the CMS CPT Joint Technical Board with the following introduction, motivation and mandate. The requirements for the CMS Data Management System (DMS) are defined by the needs of the PRS groups and the use cases for performing data analysis, event simulation and data handling by physicists, the CMS offline group and the regional center staff in the LHC distributed computing environment. The DMS should be build on top of the emerging grid tools and grid services and interface to the CMS COBRA framework and the (yet to be defined) environment for Distributed Analysis (DA). A blueprint for the CMS DMS needs to be developed in time for the CCS Computing TDR.
• from

  IGUANA Architecture, Framework and Toolkit for Interactive Graphics

  Core Overview

  The main units relating to the IGUANA architecture are:
  • A thin portability and utilities layer
  • A small kernel that manages a number of plugins:
    • application personalities
    • session with extensions forming the shared application state
    • user interface components: sites, browsers;
    • representation methods to map between the experiment and the various browsers;
    • ...
• from

  Iguana Developer Guide: How To Create a Rep Mapping

  (what follows is a sublime piece of technical prose full of object oriented terms)

  IGUANA has a number of multi-methods that bridge the application objects and the reps. Each such multi-method has a base method in IgBrowserMethods plus an extensible family of functions in plug-ins. Each method takes a main argument pair (for example, represent takes a pair <object, model> for which to create a rep); the method implementation selects from the family of functions the best match for the pair of actual arguments used. In this context, "best" means that no exact match is required -- the system uses the polymorphic nature of classes as one would expect.

  Perhaps the important concept with these methods is that the family of functions varies based on which shared libraries are loaded. Thus, functions for a multi-method family need not be linked into the programs but can be put into separate IGUANA plug-in libraries. When dropped into the plug-in directories, IGUANA will automatically detect these libraries and load them on demand -- when objects of those arguments combinations are handled. It is therefore an advantage to split the rep mapping methods into fairly small granularity shared libraries. That way the minimum of code will be loaded, and even then only when it is actually needed. (Note that although the focus here is on lazy dynamic loading of extension code in shared libraries, IGUANA's plug-in mechanism is orthogonal to dynamic loading. It is possible to build plug-ins directly into the program itself, either fully so that it will never try to load anything dynamically, or partly so that some plug-ins are built into the program and others are loaded at run time.)

  Multi-methods are not a native feature of C++, and hence are implemented by an additional library (classlib). We provide a number of preprocessor macros to make their use as simple and intuitive as possible. This guide explains both how to use and understand the macros as well as what the purpose of each method is. The methods available in IgBrowserMethods are explained below; each method consist of a pair: a front-end class-static function that should be used to call the method, and the multi-method itself.

  • represent/doRepresent: This method is used to create a rep for an application object (representable) into a browser model.

  • commit/doCommit: This method is used to commit changes made to a rep (in some browser) back into the application object. The change may apply to the whole object or only some part of it.

  • update/doUpdate: This method is used to update the existing reps of an application object when the object has changes.

  • expand/doExpand: This method is used to expand the representation of an object. It is used by browsers that construct a model for several objects lazily. When invoked, the method should create the "next level" of representations, whatever that means in the context of the model in question. For example, it could mean creating representations for the children of that object.

  The functions for the multi-method families are usually "free functions" -- functions outside any class. That is, they are normally not members of the application object nor of the rep, but mediators between the two, and simply use the public interfaces of both classes to do their job. The package they are contained in normally links against both the application object library and the model libraries -- but typically not against the browsers that view the model.

• from a presentation of Orca to newbies by Boccali

  Come girare il codice 
   ovvero come cominciare a 
  programmare / girare codice senza 
  capirci molto
  Dove e  il codice? 
  Dove e  la documentazione? 
  Dove sono i sample di simulazione? 
  Come compilo?
  Come eseguo? 
  Come scrivo Ntuple   Root files   o che altro?
          SCRAM e' la chiave di tutto!
  

• Recognize cross-project nature of key deliverables in CPT
     Core Software and Computing       CSC
        MOUable deliverables (e.g. TierX computing centers, plus core 
        software ­ graphics, libraries, GEANTx, CARF, etc)
     Physics Reconstruction and Selection    PRS
        Consolidate Physics Software work between the detector groups 
        targeted at CMS deliverables (HLT design, test-beams, calibrations, 
        Physics TDR...)
     Trigger and Data Acquisition        TRIDAS
        Online Event Filter Farm + online software framework (the other parts of
        TriDAS, e.g. Evt-Builder, RunControl, outside the CPT reorganization)
  

• Instruction generated by scram to compile a single object(!?!)

  /usr/local/gcc-alt-2.95.2/bin/c++ -c -DPROJECT_NAME=ORCA -DPROJECT_VERSION=ORCA_5_3_4
   -DHEP_ODBMS_EXPORT='' -DOS_NEW_CHECK -DOS_STL_ASSERT -DOS_NO_WSTRING -DOS_NO_ALLOCAT
  ORS -D__USE_BSD -D__USE_XOPEN_EXTENDED -DOS_LINUX_2_0 -DOS_MULTI_THREADED -DOS_LINUX_
  PTHREADS -DOS_REALTIME -DOS_USE_ALTERNATE_STD -DQT_ALTERNATE_QTSMANIP -DQT_CLEAN_NAME
  SPACE -DQT_THREAD_SUPPORT  -I/afs/cern.ch/cms/Releases/COBRA/COBRA_5_3_6/src/Porting/
  Linux2-EGCS/wrappers -I/afs/cern.ch/cms/Releases/COBRA/COBRA_5_3_6/src/Porting/Linux2
  -EGCS/wrappers -I/afs/cern.ch/user/g/gzito/orca/ORCA_5_3_4/src -I/afs/cern.ch/cms/Rel
  eases/ORCA/ORCA_5_3_4/src -I/afs/cern.ch/sw/lhcxx/specific/redhat61/gcc-2.95.2/3.6.2/
  include -I/afs/cern.ch/sw/lhcxx/specific/redhat61/gcc-2.95.2/3.6.2/include -I/afs/cer
  n.ch/sw/lhcxx/specific/redhat61/gcc-2.95.2/Objectivity/6.1/include -I/afs/cern.ch/sw/
  lhcxx/specific/redhat61/gcc-2.95.2/ObjectSpace/2.1.0.1/ToolKit -I/afs/cern.ch/sw/lhcx
  x/specific/redhat61/gcc-2.95.2/Qt/2.2.4/include -I/afs/cern.ch/sw/lhcxx/specific/redh
  at61/gcc-2.95.2/OpenInventor/2.6/include -I/afs/cern.ch/sw/lhcxx/specific/redhat61/Me
  sa/3.2/include -I/usr/X11R6/include -I/afs/cern.ch/cms/Releases/COBRA/COBRA_5_3_6/src
   -I/afs/cern.ch/cms/Releases/IGUANA/IGUANA_2_5_0/src -I/afs/cern.ch/cms/Releases/IGUA
  NA/IGUANA_2_5_0/include/Linux__2.2/src -I/afs/cern.ch/user/g/gzito/orca/ORCA_5_3_4/sr
  c -I/afs/cern.ch/cms/Releases/ORCA/ORCA_5_3_4/src  -O2 -pthread -pipe -felide-constru
  ctors -fnonnull-objects  -fPIC /afs/cern.ch/user/g/gzito/orca/ORCA_5_3_4/src/Visualis
  ation/MuonVis/src/TwigMuBarRpcSimHits.cc -o TwigMuBarRpcSimHits_pic.o     
  

• (On standalone Installation of ORCA)
  • Take Orca to the sea
  • Ready to use ORCA installation
    • with 3 commands(copy & paste)
    • in 15 min
• Possible objectives for Cobra

    More flexibility
      Event by event high-granularity control of output
         On demand digitization
         Multiple-streams by reference
           One copy of the event,many collections
         Multiple-streams by value
           Multiple copy of the event
         Dynamic clustering
           one copy of the event,location stream-dependent
      Full re-clustering
         of data
         of meta-data
  

• Vincenzo reported on the plans for COBRA for the near future. The main
  question is to keep the code stable or to implement new interfaces.
  Currently, he is making access to the database as lazy as possible.
  It followed a discussion on the use of the interfaces to CARF at different
  layers in the inheritance tree (very abstract vs. very concrete).
  Stephan will ask all subsystem coordinators to compile a list of the CARF
  interfaces they use, merge and compare, and try to see where 
  a grand unification is possible and makes sense.
  

•   Pal has a new version of the ntuple maker, that he hopes can be used
    for production.  However, it has problems from memory leaks, because
    the ORCA code it uses has memory leaks. He has notified the authors
    of this ORCA code.  He plans to add muons and tracking as well, provided
    they have acceptable memory leakage (muon is rumored to have leaks).