Support #8024

Propagating Andy's fix to the FD Cosmic processing scripts

Added by Andrew Blake over 4 years ago.

Start date:
Due date:
% Done:


Estimated time:


I promised to create a redmine issue, describing what I think needs to be done to fix the Far Detector processing scripts, in order to support the single-muon charge ratio analysis.

In early 2013, I committed a fix to the CandFitTrackCam package, correcting an asymmetry between forward-field and reverse-field behaviour. Some details of the problem my solution are set out in a presentation I gave at the collaboration meeting in Austin:

My fix isn't in any Dogwood releases, but made it into the Elm series e.g. Elm5.

The fix uses CoilTools to look up the field polarity. It's a data-driven search (i.e. it queries the BfldDbiCoilState database table) which, by default, doesn't work for simulated data (it always returns forward-field). As a result, a re-processing of the cosmic MC failed to fix the asymmetry.

In September 2014, Robert suggested the following fix to the production scripts:

[Begin Robert Wisdom]
We can "trick" CoilTools to return the desired state. I believe CoilTools uses the DB to determine IsReverse().

Detector    Table
Near Dcs_Mag_Near
Far BfldDbiCoilState

One only need pass the system a setup such that it an artificially swapped entry for that table, i.e. an ASCII DB override. This already happens for the "BfldDbiPlaneMap" table to pick up the right field maps, so it shouldn't be hard. One has to construct the ASCII DB table files (data + VLD) and set the right environment variables, but this shouldn't require any change of the [reconstruction] code.

In the Production tarball, there should be:

  1. force reverse field during reconstruction
    export ASCII_DB_SET="elm/mcbrev"

I think there a flaw in
Production/headers/far_mc/far_mc_configure.h [and near_mc_configure.h]
that can be compensated in the top level job production script by

e.g. reco_far_spill..base_elm*.C

//RWH: turn bfield reliance on CoilTools::IsReverse back on                                                                                      
// (near|far_mc_configure turned it off) if asciidb set includes "mcbrev"
std::string asciidbstring = "";
const char* asciidbset = gSystem->Getenv("ASCII_DB_SET");
if ( asciidbset ) asciidbstring = asciidbset;
if ( asciidbstring.find("mcbrev") != std::string::npos ) {
BfldLoanPool* bfldpool = BfldLoanPool::Instance();
bfldpool->Update(); // don't forget to signal it to update

[End Robert Wisdom]

I've now validated this approach in a test release. I edited the 'Production/Elm/reco_far_cosmic_daikon07_base_elm5.C' macro and the 'Production/Elm/headers/far_cosmic_mc/far_cosmic_mc_configure.h' configuration file, inserted some print statements into the reconstruction software and processing scripts, set the ASCII_DB_SET variable to "elm/mcbrev", and processed a small sample of reverse-field cosmic MC interactively. Examining the log files, I see that the the field polarity is now returned correctly to the track fitter via CoilTools - so it works! Note that I currently don't have a way of validating the output sntp files (although perhaps these store the field polarity somewhere) - so it's very much validation 'by hand'.

I'd now like to propagate Robert's suggested changes to our cosmic (?) production scripts (which requires some further decisions to be made and modified scripts to be committed and deployed), and ultimately re-process the Far Detector Daikon07 CosmicMu simulated data using the Elm5 reconstruction. I hope that the long-standing asymmetry will be gone, and the world will make sense again!

Also available in: Atom PDF