Re: BRAT update - 1.15.2

From: Stephen J. Sanders (ssanders@ukans.edu)
Date: Wed Apr 11 2001 - 12:05:01 EDT

  • Next message: Al.Jipa: "Easter"

    Hi Christian,  I'm at fault for the lock files--I had a number of these
    created when my network connection was broken last week.  I removed quite a
    few of the  files when cvs refused me access.  Once I regained access, I had
    assumed things were cleaned up.  Is there a general command available to do
    a global cleanup of lock files that an individual is responsible for? I was
    deleting them one at a time logged onto the rcas machines.
    
    I will try out the new code later today and tomorrow.  It sound like we
    might be close to being able to "retire" BrRdoModuleMult.
    
    ...steve
    
    
    
    
    > From: Christian Holm Christensen <cholm@hehi03.nbi.dk>
    > Reply-To: brahms-dev-l@bnl.gov
    > Date: Wed, 11 Apr 2001 16:59:42 +0200
    > To: brahms-dev-l@bnl.gov
    > Subject: BRAT update - 1.15.2
    > 
    > Hi BRATs, 
    > 
    > I've updated BRAT and bumped the version number to 1.15.2.  The CVS
    > repository has the tag BRAT-1-15-2.
    > 
    > Changes are (most in mult):
    > * Many fixes to BrSiRdoModule. It should be functional now.
    > * Corrected number of rings in BrSiRdo.
    > * Fixed some errors in BrSiCalibration
    > * Added Print method to BrSiRdoModule for more informative output.
    > * Added Print method to BrTileRdoModule for more informative output.
    > * BrTileRdoModule and BrTileCalibration is updated to use latest
    > calibrations from Steve and Hiro.
    > * Removed members of class BrTileRdoModule and BrSiRdoModule in
    > BrRdoModuleMult, since they were not used and obstructed other
    > code. 
    > * Took out message BrParameterDbManager::SetDebugLevel from
    > BrRdoModuleMult, since a module _may_not_ set such things on a
    > manager. That is up to the user in the setup phase.
    > * Added .cvsignore file to dbapp (I was going crazy over some of the
    > messages from CVS).
    > 
    > Also, I've updated quite a few classes and scripts in my CVS area in
    > brahms_app. In particular:
    > 
    > * Added the class KansasModule which is a wrapper around
    > BrRdoModuleMult so that I could put it in a module pipeline.
    > * Updated GlbPackage to include BrSiRdoModule
    > * Updated GlbTreeModule to also store silicon strip data on the tree.
    > * Added configuration script NbiConfig.C (Some path names are specific
    > to NBI) which I've used for debugging BrSiRdoModule and compare
    > against output from BrRdoModuleMult (via KansasModule)
    > * Added function listfiles to jobs subdir for getting data files in a
    > directory matching a pattern. (also used in mergehistos and
    > mergefiles). 
    > 
    > I urge everyone to take a look at my configuration scripts in the
    > "scripts" subdirectory, to see how to use the application
    > TestMainModule for thier analysis.  I believe it's a quite flexible
    > and powerful way to set up an analysis job, and in addition, it'd be
    > much easier to run a job on CRS.  As described in TestMainModule and
    > BrMainModule, a configuration scripts consist of setting up the
    > modules one want in a given job, and then execute TestMainModule with
    > the configuration script as the first argument, plus any additional
    > arguments for the script:
    > 
    > TestMainModule MyConfig.C -i myinput.dat -o myoutput.dat ...
    > 
    > Steve, I have not seen what you reported in your previous email about
    > the centrality from BrTileCentModule. I see many centralities
    > distributed as you'd excpect. I've used 10 sequnces from run 2530,
    > triggers 1, 4, 5, and 6, |Vz| < 45cm for my test.
    > 
    > Also, I particulary urge Steve and Hiro to look at KansasModule and
    > NbiConfig.C.  Could I ask you to try to use the BrTileCalibration and
    > BrSiCalibration for you E2N conversion functions as well as you Vz
    > correction.  In that way, we can keep everything consistent easily.
    > 
    > Uh, someone (AFS UID 2485) had CVS lock files
    > 
    > Mar 22 03:35 #cvs.rfl.sjs2lt.6589
    > 
    > dangling in brat/params/mult and
    > 
    > Mar 22 03:42 #cvs.rfl.sjs2lt.6590
    > 
    > in brat/tof/inc. Since they were rather old, I brutaly removed
    > them.  Please PLEASE make sure you don't leave dangling locks in the
    > CVS repository.  
    > 
    > (uh, only 70 something lines, I must be sick!)
    > 
    > Yours, 
    > 
    > Christian  -----------------------------------------------------------
    > Holm Christensen                             Phone:  (+45) 35 35 96 91
    > Sankt Hansgade 23, 1. th.                  Office: (+45) 353  25 305
    > DK-2200 Copenhagen N                       Web:    www.nbi.dk/~cholm
    > Denmark                                    Email:       cholm@nbi.dk
    > 
    > 
    



    This archive was generated by hypermail 2b29 : Wed Apr 11 2001 - 12:06:10 EDT