Alberto Ribon Witek Pokorski 25042013 Motivation our starting point extract the kaon and hyperons crosssections from CHIPS make sure that all the production physics list use the same crosssections set ID: 499577
Download Presentation The PPT/PDF document "First discussion on the cross-sections d..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
First discussion on the cross-sections debugging and clean up
Alberto
Ribon
Witek Pokorski
25.04.2013Slide2
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) Slide3
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
hadElastic
Crs
sctns
:
GheishaElastic
:
Emin(GeV
)= 0
Emax(GeV
)= 100000
KaonPlusInelastic
Models: FTFP:
Emin(GeV
)= 4
Emax(GeV
)= 100000
BertiniCascade
:
Emin(GeV
)= 0
Emax(GeV
)= 5
KaonPlusInelastic
Crs
sctns
:
CHIPSInelasticXS
:
Emin(GeV
)= 0
Emax(GeV
)= 100000
GheishaInelastic
:
Emin(GeV
)= 0
Emax(GeV
)= 100000Slide4
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
class
G4QHadronInelasticDataSet : public G4VCrossSectionDataSet
however... CHIPS cross sections are not called during the tracking!!! Instead
Gheisha
cross-sections are usedSlide5
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
dataSetSlide6
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
!!!Slide7
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 Slide8
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...Slide9
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 implementedSlide10
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?
Slide11
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 classesSlide12
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)