Home » Blogs » jwebb's blog

Update 10/04/2018

Updated on Thu, 2018-10-04 15:04. Originally created by jwebb on 2018-10-04 13:00.
  1. Pythia 8.2.35 (new major version) requested
    • Installed in the StarGenerator framework
    • Interface needs to be either adapted to support both pp and HI collisions, or separate StarPythiaAA interface added
  2. Work with Prashanth to integrate the EPD fast simulator with the event model
    • He had the code mostly implemented to fill StEvent
    • Was lacking an example "bfc" macro to run / test the code.  Provided.
    • After he confirms hits are in StEvent, will work with him to fill in MuDst.  Expect request for code review ~end of month.
  3. Progress on the infamous "Prashanth" bug... it comes down to one of the hijing configuration options. 
    • Believe that too many non final-state, non-particles (e.g. a "lund string") are being created and overflowing... something...
    • need to understand this further.  
    • Should note that this single line of configuration is omitted in some (but not all) example macros.
  4. First attempt to integrate  the CA + Hnn seed finder with Stv failed. 
    • Code crashes with an apparent stack corruption
    • Corruption is there once the StFwdSeedMaker is created
    • Tried to "core it out"... essentially a NULL maker...  still an issue.
    • Tried stripping out all header files...
      • Code seemed to run fine first time, but several other runs and it crashes...
    • Reduced the StFwdTrackMaker library down to just a bare Maker that does nothing...
      • Code still crashing
    • Now remove the Eve, GenFit and KiTrack libraries
      • Code runs to completion.  Phew.
    • Test with libEve +  libGenFit loaded
      • Houston, we have a problem (code crashes)
    • Test with just libKiTrack.so loaded
      • Whisky Tango Foxtrot (code still crashes)
    • There is something screwy in the setup, and it is revealed when we load in these libraries (and/or introduced by loading in these libraries).  It does not want to be found (can't reproduce the crash in gdb).  On to valgrind, I guess...
    • Or maybe...
    • We have a few suspect chain options, and a few which are not needed
      • usexgeom, big, bbcSim, emcY2, BAna, ...
      • Removed these and ...
      • (1) Code seems to hang when run interactively, but (2) crashes under gdb
    • Crashes when AddHit is called...
    • Now we can see that the geometry is being clobbered (gGeoManager->GetPath() results in a crash)...
    • But again, this is a memory corruption.  Need not be a geometry issue per se.
    • Timestamps --
      • Code crashes with sdt20201210.000008
      • Code runs fine with sdt20161215.000000 (with a hack to load ftsref6a)
        • Houston, we have a workaround
      • Suspicion is that code in eval (which has been stable for ~year) is having trouble digesting recent DB tables...
      • Digging deeper...
      • sdt20161210.00008 runs fine, sdt20171210.000008 crashes. 
        • diff on log files seems in order ...
        •  and shows nothing obvious... 
  5. Setup BaseQA analysis for testing Stv, Stv|RK and (future) Stv|CA|Hnn
    • 200 GeV AuAu minbias
    • 5k events with constant B field
    • 5k events with standard B field
    • -2.0 < eta < 5.0
    • Run simulations with a timestamp of 20161225 (make sure we do not accidentally pickup an iTPC table or three...)
  6. First look at baseqa...
    • Confirms Victor's base QA at midrapidity.  Sti > Stv > StvRK
    • Debugging at forward rapidity\

»