Castor fs noncompensation 7 6 0 pre1

[ralfulrich]

This code change is related to the non-compensation simulation of the CASTOR calorimeter. In general, the method can be used easily for any calorimeter, however, is used so far only for CASTOR.

There is a study to validate the code with particle gun simulations, which has been presented here:

https://indico.cern.ch/event/406099/session/5/contribution/5/attachments/812726/1113869/fs_noncompensation_and_cmssw7_electron_response.pdf

This is needed for Run2 detector simulations for detector unfolding. We need the code in the respective CMSSW versions used for MC productions. This is most probably at least CMSSW_7_5_X , thus, we will need a back-port to this.

This pull request is identical to the ones #10195 (CMSSW_7_1_X) and #10196 (CMSSW_7_4_X).

Best regards,
R. Ulrich

[cmsbuild]

A new Pull Request was created by @ralfulrich (R Ulrich) for CMSSW_7_6_X.

Castor fs noncompensation 7 6 0 pre1

It involves the following packages:

SimG4CMS/Forward
SimG4Core/Notification

@cmsbuild, @civanch, @mdhildreth can you please review it and eventually sign? Thanks.
@makortel this is something you requested to watch as well.
You can sign-off by replying to this message having '+1' in the first line of your reply.
You can reject by replying to this message having '-1' in the first line of your reply.
If you are a L2 or a release manager you can ask for tests by saying 'please test' in the first line of a comment.
@Degano you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of your comment.

[civanch]

@ralfulrich , yes, 7_6_X is a correct place to start this correction. However, it is not clear if at SIM step we should add compensation factor. The fact that there is some problem described in the attached talk, which is not fully understood make me confused. If we need modification in SIM at this stage then we should fully understand the problem. The modification in CastorSD will affect only Castor but modification inside NewTrackingAction will affect all. I would first discuss this PR at closest SIM meeting (may be next week Friday). If it is too late for you, let us discuss via HyperNews thread SimDevelopments.

Vladimir

[ralfulrich]

Dear Vladimir,

thanks for your reply. Just let me answer to your concerns, since they do not reflect very much the status/context of this pull request:

The pull request serves only one single purpose: to describe the pion response (relative to the electron response) for the CASTOR calorimeter. In the attached slides, these are the BLUE and BLACK points on slide 2 (validation of this pull request), where the RED markers are test-beam data.

The electron/pion response ratio is a standard problem for all calorimeters, and is typically not very well reproduced just by GEANT. This is why we need this scaling factor. We have this scaling factor ALREADY in the past, but only for the shower library (SL), with this pull request we can also get it correctly in full simulations (FS).

Thus, there is clearly no problem at all, there is only a solution to a well known and important problem. The code is validated and does what it should do.

We are very careful to make sure that our modification to TrackInformation.cc / NewTrackAction.cc do not have any impact on anything beside CASTOR (CastorSD.cc) itself. Please consider, that we did not change any functionality, but we rather added two data members in a very transparent way. In general, we believe that such a modification of TrackInformation.cc could be extremely useful also for other CMS calorimeters (they all have this problem on some level, at least HCAL), thus our code could be generalized (just by more generic naming convention) eventually at a later time.

We would need this code rather soon. We are working on publications of 13TeV data and need updated MC for this as soon as possible for unfolding.

Best regards and thanks for your time and help,
Ralf

[civanch]

@ralfulrich , non-compensation is in practically all calorimeters by design. Geant4 usually make reasonable prediction of e/p ratio, at least within test-beam uncertainty for combined ECAL/HCAL, recently HF was confirmed to be in agreement. However, it is OK if Castors use sampling factor in CastorSD and has it different for particle type, if everything is internal to Castor and does not affect the rest. What I really do not understand from this PR where these new members added to TrackInformation are used?

[ralfulrich]

These members are only used in CastorSD lines 224-228. The functionality is the following: When a G4Track hits CastorSD and none of its parent G4Tracks has ever hit CastorSD, then the value of its PID and a boolean flag are stored in the TrackInformation. Subsequently, Geant will pass this information (PID and flag) to all daughter G4tracks during tracking, thus, when a G4Track is handled in CastorSD and this property is set to the PID of a pion/hadron, then the corresponding signal response is scaled.

[civanch]

please test

[cmsbuild]

The tests are being triggered in jenkins.

[civanch]

+1

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_6_X IBs (tests are also fine). This pull request requires discussion in the ORP meeting before it's merged. @davidlange6, @Degano, @smuzaffar

[davidlange6]

+1