Project

General

Profile

Analysis How-To » History » Revision 2

Revision 1 (Richard Trotta, 04/30/2019 01:14 PM) → Revision 2/18 (Richard Trotta, 04/30/2019 01:25 PM)

h1. Analysis How-To 

 {{>toc}} 

 h2. How should I analyze data? 

 * Doing things locally will always be your best option for actual analysis.  
 ** Fork a repo of hallc_replay_kaonlt %{color:red}and% UTIL_KAONLT for your own custom version that you can play with 
 ** !! 

 * Once you have forked the repo, clone hallc_replay_kaonlt to a local directory 
 ** !! 

 * Now the tricky part, UTIL_KAONLT is a submodule of hallc_replay_kaonlt so some intermediate steps will need to be made 
 ** !! 
 ** Check .gitmodules to make sure submod is listed 
 ** !! 
 ** !! 

 * If HEAD is detached (check with git branch -a) 
 ** !! 
 ** !! 

 * Check if head is really detached 
 ** !! 
 ** !! 

 * Change to master branch 
 ** !! 

 * Pull and check branch again, everything should be set! 
 ** !! 

 * Now that we have our repo locally we should set it up to pull from the “main” JeffersonLab version 

 * First check your remote “origin” repo (this is where you will push to) 
 ** !! 

 * Now that we have our repo locally we should set it up to pull from the “main” JeffersonLab version 

 * First check your remote “origin” repo (this is where you will push to) 
 ** !! 

 * Next lets set up the “upstream” which is the JeffersonLab repo (DO NOT push HERE) 
 ** !! 

 * You will not be able to push to upstream unless you’re Stephen or me so don’t worry too much. Just be cautious. 

 * A similar procedure can be performed with UTIL_KAONLT 

 * Finally, let's talk about branches. Let’s add the develop branch to our local system… 
 ** First create a branch locally called develop and change to it 
 ** !! 

 * Now simply pull develop 
 ** !! 

 * To create a new branch you must first create it in github 
 ** !! 

 * Then simply repeat the steps for setting up a branch from the previous slide 

 h2. Replaying 

 * Before we can analyze we must replay. This should be done in the farm to save yourself time and local cpu effort.    The easiest way is to do a batch job submission, but this comes with some prep work. 

 * Before a batch submission, I highly encourage two preliminary steps 
 ## Do all debugging of replays locally, once this works move to the farm 
 ## Once on the farm you have two options; your ifarm version or our group (discussed soon).    This is for final debugging purposes to assure everything works in the farm, then you can submit a batch job. Save the root files in /volatile/hallc/c-kaonlt/<USER> (note: volatile is NOT backed up) 

 * There is a batch script I have created and Stephen as changed with the help of Brad to assure it will not mess things up.    Again, I highly recommend the two above steps before moving onto this script or you will be wasting time and resources. 

 * Your final batch job submissions can be saved directly to tape.