sPHENIX discussion of software

["Frawley, Anthony" <afrawley AT fsu.edu>]

Hi Jamie,

Regarding the level of realism for the inner pixels, Mike added a module "PHG4SvtxDeadArea" that makes it possible to randomly kill a certain percentage of hits in each layer. If this module is not given any input, it defaults to a perfect detector. From "github/simulation/macros/macros/g4simulation/G4_Svtx.C" the present default settings are:

 // defaults to 1.0 (fully active)
  PHG4SvtxDeadArea* deadarea = new PHG4SvtxDeadArea();
  deadarea->Verbosity(verbosity);
  // deadarea->set_hit_efficiency(0,0.90);
  // deadarea->set_hit_efficiency(1,0.90);
  // deadarea->set_hit_efficiency(2,0.98);
  // deadarea->set_hit_efficiency(3,0.98);
  // deadarea->set_hit_efficiency(4,0.98);
  // deadarea->set_hit_efficiency(5,0.98);
  // deadarea->set_hit_efficiency(6,0.98);
  //if(silicon_config_ITS_pixels)
    // deadarea->set_hit_efficiency(7,0.98);
  se->registerSubsystem( deadarea );

So a presently supported option is to randomly kill a specified fraction of the hits in each layer.

Are you thinking in terms of something more realistic than perfect cylinder layers with randomly killed fraction of hits?  At the moment, the inner pixels are in the simulation as cylinder cell layers. Implementing the pixels as ladders and assigning a fixed dead map is certainly possible. But it would be a nontrivial amount of work. Doing it for the pCDR would likely prevent other things from being done.

On the time scale of the pCDR, I think the best use of our time would be to stick with the cylinder cell pixels, decide on a number for the dead fraction in each layer, and do some studies with that. I have not tried to assess the impact on the Upsilon measurement of dead areas in the pixels, for example. Once the tracking code is re-optimized, that would be pretty quick to do, and I think would answer the biggest questions.

Implementing a ladder model of the pixels could be done on a slightly longer time scale.

Cheers
Tony

---

From: sphenix-software-l-bounces AT lists.bnl.gov [sphenix-software-l-bounces AT lists.bnl.gov] on behalf of Jamie Nagle [jamie.nagle AT colorado.edu]
Sent: Wednesday, August 19, 2015 1:24 PM
To: sphenix-l AT lists.bnl.gov; sphenix-software-l AT lists.bnl.gov; sphenix-tracking-l AT lists.bnl.gov
Subject: Re: [Sphenix-software-l] [minutes] sPHENIX simulation meetings, Tue Aug 18th 1-3PM @ 2-160

Hello sPHENIX tracking experts,

The minutes from Jin on the tracking discussion at the sPHENIX simulations meeting were very useful.

For the pCDR, one important issue is the proposed re-use of the current PHENIX VTX inner two pixel layers.    Since we are considering different options for the tracking, it will be important to clearly detail the pros and cons.   The main benefit for re-using the pixel layers is cost savings (both in construction and people).    However, since there are ideas for replacing these pixels, the real performance needs to be in the pCDR in my opinion.

For the pCDR and the ladder work that Tony reported on, what is the planned level of material realism for the two inner pixel layers where we know the detailed layout?  The earlier sPHENIX proposal has a simple drawing for how the ladders would be moving to a slightly smaller radius and reconfigured.

My student Theo Koblesky helped pull together snapshots of the pixel performance in Run-14 and Run-15 (from Run 408805 at the start of the Au+Au 2014 run, Run 415752 late in the He+Au 2014 run, Run 422618 early in the p+p 2015 run, and Run 436403 late in the 2015 p+Au run -- noting that this is after the pre-fire abort dump).     Attached are two slides of the pixel live area from Run 422618 - these would be good to include in the pCDR.   Note that it is not possible to characterize additional unstable pixels in the low occupancy p+p data.

Thus, one clear issue is loss of acceptance.   In this "good run", the B0 inner layer has 92.5% good pixels and the B1 outer layer has 77.5% good pixels.    For the b-tagging of jets, probably all tracks will need to require B0 and B1 to have an accurate DCA as applied in the algorithm presented in the sPHENIX proposal.   If one is looking at N tracks in the jet and requiring both layers, there is a penalty of order (0.925 x 0.775)^N.    For the upsilon physics, one does not need DCA information and one could have B0 or B1; however, that needs a full evaluation in terms of fake tracks in central Au+Au (maybe mitigated by the EMCal energy match cut).      Is the plan for more detailed numbers in the pCDR on this acceptance loss and other physics implications?    Performance of additional needed ladders for hermetic coverage also needs to be included.

Another question that will be asked is whether the performance is degrading with time and how long they might last.   One simple issue is radiation exposure and with 2 or 3 or 4 years of sPHENIX potential running.   Another question is whether the corner regions with dead or cold pixels might be growing.    Looking globally over these 4 runs listed above spanning 2014-2015, the B0 live year went from 92.5% to 91.6% (however, that is perhaps difficult to assess the significance).    Looking at just sensors with > 90% live, for the four runs the fraction of good pixels was 95.66, 95.03, 96.31, 95.91% -- no real evidence of growing dead areas.    Looking globally over these 4 runs listed above spanning 2014-2015, the B1 live year went from 79.3% to 77.5% and then after the pre-fire abort 70.5% (however, that is perhaps difficult to assess the implication of this last number).    Looking at just sensors with > 90% live, for the four runs the fraction of good pixels was 95.64 94.81, 95.59, 94.47% -- no real evidence of growing dead areas.    If there are additional numbers or Runs that would be useful, Theo has full access to all the dead/cold/hot/unstable maps and we would be glad to help.

It might be good to put this kind of information together in a Technical Note that can be referenced.

One last item, an issue that has caused problems is the inability to run the full system in the same way outside the detector (when it has been over in Chemistry or Physics during assembly and maintenance periods).    It would be good to include a cost estimate for the new silicon configuration to have this ability.    The periodic result where an entire ladder appears to work and then does not when installed presents an unacceptable loss in terms of jet physics coverage -- see for example B1 east.

Sincerely,

Jamie

On Tue, Aug 18, 2015 at 3:03 PM, Huang, Jin <jhuang AT bnl.gov> wrote:

Also available on agenda: https://indico.bnl.gov/conferenceDisplay.py?confId=1187

 

 

Tony - SVX tracking option update

 

Page 4 -

Mike: question on the thickness for ITS thickness, is that 0.3% or 0.6%?

Tony: need to double check

 

Action Item [Tony]: double check and confirm ITS thickness

 

Page 5:

Jin: is there liquid cooling for FPHX design?

Tony: no, gas cooled.

 

Summary:

 

Jin: action item from last meeting, certify the implementation of cylinder SVX

Tony: mass resolution went to ~104 MeV.

Mike: ~5-10% track has bogus cluster. Reco eff. Is very high. May need to update quality cuts. Problem is above G4Hit level, no need to hold production for this.

 

Tony: which one is the macro to double check again before production?

Chris: the one in the master: https://github.com/sPHENIX-Collaboration/macros/blob/master/macros/g4simulations/G4_Svtx.C

 

Alan: Is Kalman filter with SVX ladder working?

Tony: having trouble finding track once turn on covariant matrix option.

 

 

Ron S. and Alan - TPC update

 

Ron Page 3:

Volunteer welcomed: function study with TPC

 

Alan page 1:

Mike: what's the quantification of the effect?

Alan: need to work out.

Dave: good to improve communication to ALICE. May deserve to simulate the current ALICE setup as our simulation calibration too.

Ron: Need measurement for calibration of the gain structure of readout, leads to uncertainty in this study at this stage.

Craig: ALICE are looking at a few readout options. The space charge is dominated by the readout ion back flow.

Dave, John and Jin: what about pp at improved luminosity ?

Craig: coincidentally, the effects are similar due to similar #track/s in HI VS pp.

Alan: need to quantify the smearing residual after the correction. Need to study and talk to experts.

Chris: there is a 2006 NIM paper on STAR and a thesis from ALICE: Simulation & Calibration of the ALICE TPC including innovative space charge calculations:

http://inspirehep.net/record/887113/files/CERN-THESIS-2009-124.pdf

 

Alan: what is the time scale?

John H.: document final in Mid Oct. Draft early Sept. Detector definition very soon.

Ron: plan not implementing space charge effect for now.

Craig: suggest quote a rough relative deterioration based on existing, e.g. STAR's experience.

 

Alan page 2:

Alan: what plot we would need for pre-CDR.

Mike/Tony/Ron: consistent with SVX option studies, suggest tracker performance plots (dp/p, eff., purity, DCA) for pp and central HIJING. dE/dx for TPC only studies.

 

Alan page 3

Alan: what is criteria to merge?

Mike: will help in certification.

 

Alan: Time scale need?

Mike: sooner than later since it gets harder and harder.

 

Dave: Talked with Jim Thomas. He is willing to join this meeting to discuss directly. Many useful comments.

Action Item [Jin, Dave, TPC team]: Email to organize a discussion with Jim Thomas at a future meeting.

 

 

Tracking in general:

 

Dave: shall we try GenFit for general Kalman fit framework?

Both Dave and Mike are interested in working on this direction. 

 

Jin: what is the portion of photon conversion background for Upsilon?

Tony &  Alan: should be negligible small. Need to double check Sasha's past study.

 

 

Calorimeter Updates

 

Jin - full projective SPACAL merged to nightly build. Small bug fix in the weekend. Chris running test production.

Chris: New field map from Achim. Start trying single particle simulation in the new reference simulation.

Achim: Walter is also working on 3D magnetic field.

Jin: will cross check with after-burner once receiving it. 

 

Ron: what is the status of the finalization of HCal code

Chris: recently adjusted air gap. Outer Hcal use fixed tilt angle. Ready for test production.

 

 

Mike - Analysis software

 

Many progress made in the past a few weeks:

 

Finished Items:

·       Jet storage

·       Jet reconstruction module

o   https://github.com/sPHENIX-Collaboration/macros/blob/master/macros/g4simulations/G4_Jets.C

o   Although set to disable by default, but ready for test in private by activate flag in

Fun4All_G4_sPHENIX.C

·       Tracking evaluation

o   New scheme in evaluator objects

·       Pythia 8 driver module (imported from Matt Snowball)

o   https://github.com/sPHENIX-Collaboration/coresoftware/tree/master/generators/PHPythia8

·       A few bug fix in vertex module and tracking

 

John H. (Offline): PHENIX beam pipe is 43.2 mm in diameter and the wall is 0.76 mm thick Beryllium

Action Item [Mike]: Update the macro

 

Jin: Should user use the new Ntuple maker as example for using the evaluator objects?

Mike: Yes. User can copy it to get example of using evaluators:

https://github.com/sPHENIX-Collaboration/coresoftware/blob/master/simulation/g4simulation/g4eval/SvtxEvaluator.C

 

Issue: x4 slower from various pointer copying?

Chris: We can try profilers, including GNU gprof and callgrind. Not yet tested on RCF.

 

TODO items:

·       Calo Eval.

·       Optimization

·       ATLAS Jet reco

·       FastSim

 

Chris/Peter: Vertex reco has problem in truth container. Multi-vertex problem.

Mike: on TODO list, though not top

 

 

 

 

 

 

 

 

 

______________________________

 

Jin HUANG

 

Brookhaven National Laboratory

Physics Department, Bldg 510 C

Upton, NY 11973-5000

 

Office: 631-344-5898

Cell:   757-604-9946

______________________________

 

From: Huang, Jin
Sent: Monday, August 17, 2015 4:28 PM
To: 'sphenix-l AT lists.bnl.gov' <sphenix-l AT lists.bnl.gov>; 'sphenix-software-l AT lists.bnl.gov' <sphenix-software-l AT lists.bnl.gov>
Subject: [reminder] sPHENIX simulation meetings, Tue Aug 18th 1-3PM @ 2-160

 

Dear All,

 

Despite of the EMCal review dry run, we will still have a brief weekly sPHENIX simulation meeting Tue Aug 18^th 1-3PM. Let’s start the meeting with brief updates on software status for TPC, calorimetry and analysis software. More contributions are welcomed too.

 

For residents at BNL, we will meet in the 2-160 conference room (the regular room and time slot).

 

The agenda page is at https://indico.bnl.gov/conferenceDisplay.py?confId=1187 , for which the modification password is 1008

 

To join via Browser:

https://bluejeans.com/377457648/browser

 

To join via Phone:

1) Dial:

+1 408 740 7256

+1 888 240 2560(US Toll Free)

+1 408 317 9253(Alternate Number)

(see all numbers - http://bluejeans.com/numbers)

2) Enter Conference ID: 377457648

 

 

Cheers,

 

Jin

 

 

 

______________________________

 

Jin HUANG

 

Brookhaven National Laboratory

Physics Department, Bldg 510 C

Upton, NY 11973-5000

 

Office: 631-344-5898

Cell:   757-604-9946

______________________________

 

_______________________________________________
Sphenix-software-l mailing list
Sphenix-software-l AT lists.bnl.gov
https://lists.bnl.gov/mailman/listinfo/sphenix-software-l

--

||--------------------------------------------------------------------------------
|| James L. Nagle   
|| Professor of Physics, University of Colorado, Boulder
|| EMAIL:   jamie.nagle AT colorado.edu
|| SKYPE:  jamie-nagle        
|| WEB:      http://spot.colorado.edu/~naglej 
||---------------------------------------------------------------------------------