SoftwareHints » History » Revision 16

Revision 15 (Dobbs, Adam, 27 June 2014 12:10) → Revision 16/17 (Dobbs, Adam, 27 June 2014 12:18)

h1. Software Hints and Tips 

 A presentation giving a tracker software "How To", covering general code design, where things are found, how to run a simulation, and access and analyse output data, is available at: 

 document#90 

 h2. Running a tracker simulation 

 There is a dedicated directory holding top level scripts for producing tracker data within MAUS at: 

 <pre> 
 bin/user/scifi 
 </pre> 

 For example to run a MAUS simulation of the tracker in the presence of a magnetic field (helical tracks) do the following from the MAUS root directory: 

 <pre> 
 source env.sh 
 cd bin/user/scifi 
 ./simulate_scifi.py --configuration_file datacard_mc_helical 
 </pre>  

 The equivalent command for no magnetic field (straight tracks) is: 

 <pre> 
 ./simulate_scifi.py --configuration_file datacard_mc_straight 
 </pre> 

 h2. Datacard variables 

 Datacard variables control the various parameters passed to MAUS. The variables assume the default values set in src/common_py/ConfigurationDefaults.py unless overridden in a datacard or elsewhere.    Here are a few common variables:  

 * Number of spills. The number of spills to simulate can be set by editing the relevant datacard file and changing the variable 'spill_generator_number_of_spills'. 
 * The number of particles per spill is controlled by the beam variable. This has a number of sub-variables, two of which can be set to alter the number of particles per spill: 
 ** 'binomial_n' is the number of attempts at generating a track 
 ** 'binomial_p' is the probability an attempt succeeds 
 * Helical pattern recognition can be turned on or off by setting 'SciFiHelicalPROn' to 1 or 0 respectively 
 * Straight pattern recognition can be turned on or off by setting 'SciFiStraightPROn' to 1 or 0 respectively 

 h2. Accessing the output data 

 Example ROOT and PyROOT scripts for accessing the data are available "here":http://micewww.pp.rl.ac.uk/documents/89 

 In order for ROOT to understand the classes we have written, a ROOT dictionary, built automatically by MAUS, must first be loaded. In an interactive ROOT session this done with following command: 

 <pre> 
 .L $MAUS_ROOT_DIR/build/libMausCpp.so 
 </pre> 

 The equivalent command if using "PyROOT":http://root.cern.ch/drupal/content/pyroot is  

 <pre> 
 import libMausCpp 
 </pre> 

 An example ROOT session to open a data file would be: 

 <pre> 
 > .L $MAUS_ROOT_DIR/build/libMausCpp.so 
 > TFile f1("maus_output.root") 
 > TBrowser b 
 </pre> 

 The equivalent PyROOT session would be: 

 <pre> 
 >>> from ROOT import * 
 >>> import libMausCpp 
 >>> f1 = TFile("maus_output.root") 
 >>> b = TBrowser() 
 </pre> 


 The tracker MC data can then be found by browsing to: 
 <pre> 
 Spill:data:_spill:_mc:_sci_fi_hits 
 </pre> 

 The reconstructed data is stored under: 
 <pre> 
 Spill:data:_spill:recon:_scifi_event 
 </pre> 

 An example PyROOT session to access some data: 

 <pre> 
 >>> from ROOT import * 
 >>> import libMausCpp 
 >>> f1 = TFile("maus_output.root") 
 >>> t1 = f1.Get("Spill") 
 >>> t1 
 <ROOT.TTree object ("Spill") at 0x8bfa970> 
 >>> t1.Draw("_spill._recon._scifi_event._scifitracks._f_chi2") 
 >>> data = MAUS.Data() 
 >>> t1.SetBranchAddress("data", data) 
 >>> t1.GetEntry(1) 
 51435 
 >>> spill = data.GetSpill() 
 >>> spill 
 <ROOT.MAUS::Spill object at 0x92f4a40> 
 >>> spill.GetReconEvents().size() 
 1L 
 >>> revt = spill.GetReconEvents()[0] 
 >>> sfevt = revt.GetSciFiEvent() 
 >>> htrks = sfevt.helicalprtracks() 
 >>> htrks.size() 
 2L 
 >>> spoints = htrks[0].get_spacepoints_pointers() 
 >>> spoints.size() 
 5L 
 >>> sp = spoints[0] 
 >>> sp.get_position().x() 
 8.468833333333333 
 </pre> 

 h2. Running the tests 

 All branches should pass the testing framework before being pushed up to launchpad.    The full set of tests can be run with: 

 <pre> 
 ./tests/run_tests.bash 
 </pre> 

 This can take quite a while to run however.    Running smaller sections of the tests first will generally save you time.    Two common places where test errors creep in are in cpp style and python style checks.    The cpp style test can be run on its own with: 

 <pre> 
 python tests/style/test_cpp_style.py 
 </pre> 

 The python style test can be run with: 

 <pre> 
 python tests/style/test_python_style.py 
 </pre> 

 The unit tests (which include the cpp style check but not the python style check) can be run with: 

 <pre> 
 ./tests/unit_tests.bash 
 </pre> 

 An individual cpp unit test module can also be run. For example, to run just the Pattern Recognition unit tests: 

 <pre> 
 build/test_cpp_unit --gtest_filter=PatternRecogntionTest.* 
 </pre> 

 Once these all pass, make sure you run full test suite before pushing to launchpad if you have made any significant code changes. 

 The MAUS documentation for unit tests can be found on the [[maus::Unit tests|MAUS wiki]].