1 / 12

First discussion on the cross-sections debugging and clean up

First discussion on the cross-sections debugging and clean up. Alberto Ribon Witek Pokorski 25.04.2013. Motivation. our starting point: extract the kaon and hyperons cross-sections from CHIPS make sure that all the production physics list use the same cross-sections set

loe
Download Presentation

First discussion on the cross-sections debugging and clean up

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. First discussion on the cross-sections debugging and clean up Alberto Ribon Witek Pokorski 25.04.2013

  2. Motivation • our starting point: extract the kaon and hyperons cross-sections from CHIPS • make sure that all the production physics list use the same cross-sections set • clean-up and simplify the structure, remove redundant classes, make sure there is no duplication and all cross sections are accessed using the same interfaces (entry points)

  3. First look • FTFP_BERT was supposed to be using CHIPS cross-sections for kaons and hyperons Hadronic Processes for <kaon+> ----------------------------------- hadElastic Models: hElasticLHEP: Emin(GeV)= 0 Emax(GeV)= 100000 hadElasticCrssctns: GheishaElastic: Emin(GeV)= 0 Emax(GeV)= 100000 KaonPlusInelastic Models: FTFP: Emin(GeV)= 4 Emax(GeV)= 100000 BertiniCascade: Emin(GeV)= 0 Emax(GeV)= 5 KaonPlusInelasticCrssctns: CHIPSInelasticXS: Emin(GeV)= 0 Emax(GeV)= 100000 GheishaInelastic: Emin(GeV)= 0 Emax(GeV)= 100000

  4. Second look • CHIPSInelasticXS is first on the list so it should be used • it is supposed to call CHIPS cross-sections classes G4QKaonPlusNuclearCrossSection through the interface classG4QHadronInelasticDataSet : public G4VCrossSectionDataSet • however... CHIPS cross sections are not called during the tracking!!! Instead Gheisha cross-sections are used

  5. Source of the problem (1/2) • calls to cross-sections are done by G4CrossSectionDataStore where following checks are made for the cross-section data set (starting from the top on the list i.e. CHIPS) ... if (dataSetList[i]->IsElementApplicable(part, Z, mat)) { ... if(dataSetList[idx]->IsIsoApplicable(part, Z, A, elm, mat)){ ... } else { // search for other dataSet

  6. Source of the problem (2/2) • IsElementApplicable and IsIsoApplicable have default implementation in the base class G4VCrossSectionDataSet always returning FALSE • the two method are not reimplemented in G4QHadronInelasticDataSet!!! • the answer is always FALSE and CHIPS cross sections are never used!!! • btw, in my opinion the base class should not implement those methods, they should be virtual • CHIPS interface for cross sections is incompatible with the implementation of G4CrossSectionDataStore • FTFP_BERT says it uses CHIPS cross sections for Kaons, but it never does, it always falls back to Gheisha!!!

  7. Remark about Elastic • G4QHadronElasticDataSet has exactly the same problem • but... apparently it is not used, instead processes/hadronic/models/coherent_elastic/include/G4CHIPSElasticXS.h is used which point to CHIPS cross-sections • very confusing because the same name of the dataset is used in both cases: CHIPSElasticXS • CHIPS elastic cross-sections needs also to be extracted from CHIPS and the 'interface' in coherent_elastic should be (re)moved/adapted

  8. Remark about FTF • FTF uses internally CHIPS cross sections... through yet another interface hadronic/models/parton_string/diffraction/include/G4ComponentCHIPShadronNuclearXS // Calculation of the total, elastic and inelastic cross-sections // of hadron (proton, neutron, pi+, pi-, K+, K-, anti_proton, anti_neutron // interactions with nuclei based on CHIPS model // // Created by V. Uzhinsky, 31.05.2011 • this inherits from G4VComponentCrossSection and combines elastic and inelastic cross-sections...

  9. Side remark about Gamma-Nuclear • cross-sections used for gamma nuclear (in QGSP_BERT and FTFP_BERT) are the ones in: processes/hadronic/cross_sections/src/G4PhotoNuclearCrossSection.cc • they inherit from G4VCrossSectionDataSet and the interface is OK • IsIsoApplicable method is implemented

  10. Actions • extract elastic and inelastic cross sections from CHIPS (for Proton, Neutron, K, Pi, hyperon, anti-baryon) • copy them and remove inheritance/dependence on G4VQCrossSection and G4QPDGCode • get rid of (reimplement in a clean way) the existing interfaces to CHIPS cross section (in coherent_elastic and parton_string) and remove from the physics lists G4QHadronInelasticDataSet ( • implement physics list properly to use the right cross sections • remove Gheisha cross sections as the default fall-back solution?

  11. Proposal • copy CHIPS cross-sections to processes/hadronic/cross_sections • use the following naming convention: • G4KossovKaonMinusNuclearCrossSection • G4KossovKaonMinusElasticCrossSection • make them inherit from G4VCrossSectionDataSet • once this is done • modify/remove the existing interfaces to CHIPS cross-sections in coherent_elastic and in parton_string/diffraction/ to use the new extracted cross-sections • modify the physics list accordingly to use the new cross-sections classes

  12. Conclusion • actions should be taken now! • we are giving (to LHCb for instance) FTFP_BERT incorrectly claiming that CHIPS x-sections are used for kaons • the clean up should be done for both inelastic and elastic cross-sections • all moved to one directory with no redundant interfaces • proposal to have in the next beta release all the production physics list use the same, unique set of cross-sections • alternative sets have to follow our standard interface • available to the users by the mean of explicit configuration of PL (to avoid any confusion)

More Related