1 / 19

IAEA Benchmark

IAEA Benchmark. V.Ivanchenko, A.Ivantchenko 9 February 2009. Introduction. In December 2009 Jose Manuel proposed to take part in IAEA benchmark on spallation models assumed participation of Fluka, INCL5, MCMPX? We implement the benchmark in general

osma
Download Presentation

IAEA Benchmark

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. IAEA Benchmark V.Ivanchenko, A.Ivantchenko 9 February 2009

  2. Introduction • In December 2009 Jose Manuel proposed to take part in IAEA benchmark on spallation models • assumed participation of Fluka, INCL5, MCMPX? • We implement the benchmark in general • results for neutrons, pions, isotopes are acceptable • results for light ions are bad • Jose Manuel and Miguel worked in January to improve PreCompound/Deexcitation • several attempts were done to introduce better models

  3. New test30iaea • http://antoni.web.cern.ch/antoni/results/iaea/geant4-09-02-ref-00/ Mandatory set of data *Neutron production Double-differential Cross Sections Multiplicity Distributions *Light charged particle production Double-differential Cross Sections *Production cross-sections up to 3 GeV (excitation functions) *Isotopic distribution cross-sections in inverse kinematics *Pion production Double-differential Cross Sections n_Bi_542_ddxs, n_Fe_65_ddxs, p_Al_160_ddxs, p_Al_2205_ddxs, p_Al_730_ddxs, p_Au_1200_ddxs, p_Au_160_ddxs, p_Au_2500_ddxs, p_Bi_62_ddxs, p_C_730_ddxs, p_Cu_730_ddxs, p_Fe_100_res_isot, p_Fe_1200_ddxs, p_Fe_1600_ddxs, p_Fe_3000_ddxs, p_Fe_300_res_isot, p_Fe56_62_ddxs, p_Fe_800_ddxs, p_Ni_175_ddxs, p_Pb_1000_res_isot, p_Pb_1200_ddxs, p_Pb_1600_ddxs, p_Pb_256_ddxs, p_Pb_3000_ddxs, p_Pb_500_res_isot, p_Pb_63_ddxs, p_Pb_730_ddxs, p_Pb_800_ddxs, p_Ta_1200_ddxs, p_U_1000_res_isot_gsi Isotope production directories

  4. Models used • Bertini is the fastest • Binary about 3 times longer • INCL about 10 times longer than Bertini • QMD is about 100 times longer and many warnings about big energy non-conservation

  5. neutron production, Geant4 9.2

  6. π- production, Geant4 9.2

  7. π+ production, Geant4 9.2

  8. proton production, Geant4 9.2

  9. He4 production, Geant4 9.2

  10. Bug fix of probabilities for the emission of light ions by Jose Manuel, 6 Feb 2009

  11. He4 production after bug fix

  12. Deuteron production after bug fix

  13. Proton production

  14. Binary_ion and Binary provide the same results if Tripathi cross sections is used Shen cross section is buggy

  15. Possible actions to complete benchmark • Include/increase pion absorption (LHC !) • Quasi-elastic light ion production by cascades • Coalescence? • Further fixes from Jose Manuel • Fission ? • In benchmark specification there is a requirement to provide additional information including ROOT trees with intermediate data between cascade and pre-compound • In long term: • Quasi-elastic scattering with excited nucleus in final state

  16. Few comments to working plan • In 2008 some infrastructure upgrade have been introduced: • G4HadronicProcessStore • Review of masses • Additional modifications pending in Bonsai: • G4HadronicInteractionRegistry fixed • G4CrossSectionDataSetRegistry added • Fixed main leakage at initialization in hadronics by introduction of register/deregister mechanism • Remaining minor leaks are in specific models • Code cleanup

  17. Further clean up of infrastructure? • What can be done in 2009 for infrastructure? • Natural isotope composition class review • Rotation of final state removal • Z1/3, log(Z), N! – repeated computations in many places • Constructors/destructors/inline cleanup • Too many classes describe target nucleus

More Related