How To Setup ORCA v5_x_x at Fermilab







 
 

What we want to do :

     We want to setup ORCA v5_x_x for use with the rest of the CMS Software and import a set of particles to an Objectivity Database (which we will create) for later analysis.
 

How To generate a bunch of particles for the ORCA Analysis :

     Follow the instructions for making particles and turning on the CMSIM detector simulation package as described in "How To Simulate CMS Detector Response to Particles in CMSIM".
 

How To Setup ORCA v5_x_x at FNAL :

We need to setup the program ORCA as well as an Objectivity Database for ORCA to use.  You can check out  "Creating Executables for OOHits & OODigis" on the CMS Production web page for information (v4_x_x was the last update on that page, v5_x_x utilizes a different reorganization of things with COBRA -- That reminds me to warn you that ORCA v6 or v7 or whatever may make the things I suggest here completely wrong !  Such is life with rapidly developing software.).  I used ORCA_5_3_1, when you do 'scram list ORCA' below, you'll see what's available for you.

    cd /home/leer/cmsim/cms_sim/
    project ORCA
    scram list ORCA
    scram project ORCA ORCA_5_3_1
    cd ORCA_5_3_1/src
    eval `scram runtime -csh`
    project ORCA

ORCA is ready to go.  Now let's check out one of the Example Programs and compile it.  The sample program we will check out is the one which writes the Hits and Digis to the database.

    cvs co -r ORCA_5_3_1 Examples/ExProduction/
    cd Examples/ExProduction/
    scram b shared
    scram b bin
    rehash

At this point we have created to executables
     writeHits  -> this puts .fz file info into database
     writeDigis -> this is 1st step in reconstruction (digitization)

We are just about ready to go, but first we will create the Objectivity Database ...
One more thing, when you are compiling your own programs late on, note that the commands 'scram b clean', 'scram b shared', and 'scram b bin' are used to clean the work area, build the shared libraries, and build the binary.

How To Your Own Objectivity Federation/Database for ORCA at FNAL :

We need to create a Federation (in which we will put/create databases)
This Federation will be created on the local pc.  To make the federation/databases, we need to turn on the 'lockserver' and 'ams'.

    oocheckls       // Is the lockserver on ???
    oocheckams   // Is ams on ???

    oolockserver
    oocheckls
    oostartams
    oocheckams

So hopefully they come up without any problem.  Go to the head of your ORCA directory.

     cd home/leer/cmsim/cms_sim/ORCA_5_3_1
     ls .SCRAM/Linux__2.2/

Now check ORCA_5_3_1/.SCRAM/Linux__2.2/ to see compatible COBRA version
When I list the contents of that directory I see files like :  cobra_COBRA_5_3_2.dat
So I will use COBRA_5_3_2 ....

     scram list COBRA
     scram project COBRA COBRA_5_3_2
     project COBRA
     cd COBRA_5_3_2/src/
     cvs co -r COBRA_5_3_2 Utilities/Configuration
     cd Utilities/Configuration/src/
     nedit makefd.local &

Now, look in the makefd.local file its a big script to setup your federation.  You need to change the schema file, though.  Look for the line in this file that says 'set schemafile'.  Set it to the following schema file:

/afs/fnal.gov/files/code/cms/Releases/ORCA/ORCA_5_3_1/src/Data/domain/ORCAschema.dmp

The database/federation is actually created in this directory, under the 'myoofd' sub-directory.  If there is a problem executing the makefd.local script, or you want to remove your federation/database, you need to  'rm -rf myoofd', try to figure out what went wrong, and run it again

The *.boot file is crucial - it allows Read/Write access to database. You need to set the location as an environmental variable. If you logout or the OO_FD_BOOTFILE in your env gets lost, you need to reset it.

setenv OO_FD_BOOT   /data1/leer/COBRA_5_3_2/src/Utilities/Configuration/src/myoofd/ORCATEST.boot

You can't do anything without that being set.

The database is now ready to go. Documentation and Help for database operation is available at:
/afs/fnal.gov/files/code/cms/sw/lhcxx/specific/redhat61/Objectivity/5.2.1/doc/administration.pdf

You could have customized all sorts of things when you created the federation (location, etc).  But who cares where it is or how it looks as long as you set the bootfile and it works.
 

Writing the Hits and Digis to your new Federation/Database :
 

     Go back to that example that we checked out a few steps ago :

     cd ORCA_5_3_1/src/Examples/ExProduction

     Now we want to write the so called Hits and Digis to our database (ie the particle tracks and the digitized information that elements in the detector send back in response to those tracks).   If you don't know exactly what Hits and Digis are, you really should figure it out.  Someone already wrote the code to do this for you, and you checked it out earlier when you did 'cvs co Examples/ExProduction'.  To use the programs and your new database, we need to tell the program where your database and .fz files (from the CMSIM production) are and what you want done.  Since your OO_FD_BOOT is set, it knows about your database.

     We are interested in the following files : writeHits.env,  writeHits.orcarc, and writeDigis.orcarc.  These files are located in ORCA_5_3_1/src/Examples/ExProduction/ .

     Now check that writeHits.env has correct value for DETINPUT.  We used the cms120 geometry when we made particles and ran them on CMSIM back on the CMSIM Production page.   Use what's appropriate, but I used :

    <Runtime name=DETINPUT value=/afs/cern.ch/cms/oo/reconstruction/datafiles/cms120/cms_geom_out.rz></Runtime>

     We need to update these files and provide job names, database names, etc.  For simplicity, I will assume that the particles were generated in the manner outlined in "How To Simulate CMS Detector Response to Particles in CMSIM"  with a title card call higgs_muon_gen.tit producing the CMSIM output file higgs_muon_800001.fz

    In writeHits.orcarc, change the FZInputFiles variable to point to the .fz file that you made with CMSIM.
Following the example I used earlier in the CMGEN/CMSIM stage, my FZInputFile variable looks like:

    FZInputFiles=/home/leer/cmsim/cms_gen/cms_production/Projects/higgs_muon/results/higgs_muon_800001.fz

Also check that the writeHits.orcarc file has the OutputDataSet and # of events to process set correctly:

      SimApplication:MaxEvents=-1                                         (-1 means examine all the events)
      OutputDataSet = /System/SimHits/higgs_muon

Now we write the particle Hits in the detector to the database :

    cp writeHits.orcarc .orcarc
    rehash
    echo $OO_FD_BOOT
    eval `scram runtime -csh writeHits.env`
    writeHits

Once it finished, in writeDigis.orcarc file, update the following variables :

     InputCollections = /System/SimHits/higgs_muon/higgs_muon
     OutputDataSet = /System/NoPileup/higgs_muon

Note:  The "higgs_muon/higgs_muon" double namimg is not a mistake !

Now we can write out the Digitization of detector electronics and check the results :

    cp writeDigis.orcarc .orcarc
    writeDigis

Check the results :

    oodumpcatalog

Hopefully the output of the oodumpcatalog command generates a table of what has been stored by the writeDigis command.  You should see the names of datasets in that table correspond to the variables we changed earlier.  The format of the table is : <name>.<dataset>.<owner> where the dataset and owner names are set in the writeHits.env file

 If you made more than one .fz file (ie higgs_muon_800002.fz), to do the writeHits and writeDigis on the second job
 it is necessary to again edit the .orcarc file and change the FZInputFiles parameter.  Iterations after the first execution of writeHits are faster since the geomtery file is now loaded.
 

Things You Want To Know:

The Database stuff gets corrupted easily and is tough to work with.  I hate it.  There is talk about moving to something else.  Hope that they do.  If you have problems with your database, always make sure ams and the lockserver are running.  Check that your BootFile is set correctly as well.  Its always easy to delete stuff in the database, but it is very hard to move stuff (import/export to other DB) or copy stuff to a disk or cd.

If you keep getting errors when trying to use ORCA, you might find that you need to do this once again (esp. after loggin out and then in again) :

    cd ~leer/cmsim/cms_sim/ORCA_5_3_1/src
    eval `scram runtime -csh`
    setenv
    echo $ORCA_DATA_DIR
 
 

Whats Next ?  Doing some sort of analysis.  Thats not exactly easy so you should work with some examples first.  Take a look at "Some Simple ORCA Examples".