Many "Conditional jump or move depends on uninitialised value(s)" errors detected by valgrind in the following places: G4NeutronHPPhotonDist::GetPhotons(double) (G4NeutronHPPhotonDist.cc:208) G4NeutronHPPhotonDist::GetPhotons(double) (G4NeutronHPPhotonDist.cc:342) G4NeutronHPPhotonDist::NeedsCascade() (inline function) All of these turn out to be due to accessing "repFlag", which is not initialized. The above two functions are sometimes being called from G4NeutronHPInelasticCompFS::CompositeApply(), and sometimes being called from G4NeutronHPInelasticBaseFS::BaseApply(). I tracked it down, and found in G4NeutronHPInelasticCompFS::Init() and G4NeutronHPInelasticBaseFS::Init(), there is the following logic: ... else if(dataType==12) { theFinalStatePhotons[it] = new G4NeutronHPPhotonDist; theFinalStatePhotons[it]->InitMean(theData); } else if(dataType==13) { theFinalStatePhotons[it] = new G4NeutronHPPhotonDist; theFinalStatePhotons[it]->InitPartials(theData); } ... It turns out that only G4NeutronHPPhotonDist::InitMean() initializes repFlag. Neither the G4NeutronHPPhotonDist constructor nor G4NeutronHPPhotonDist::InitPartials() initializes repFlag. Since InitMean occurs only in one place in G4NeutronHPInelastic*FS.*, in the dataType==12 case, it follows that repFlag will _always_ be uninitialized in the dataType==13 case, and inelastic interaction photon distributions from isotopes using dataType==13 will _always_ be buggy, i.e., physics results dependent on the garbage uninitialized values in repFlag. I confirmed this is the case by following the initialization of oxygen 16 inelastic states in the debugger. To quote the author of report #943, "Please fix this strange code." It looks like maybe G4NeutronHPFSFissionFS could have the same problem. I'm not sure about G4NeutronHPCaptureFS. Some of the isotope inelastic final state files that have this dataType==13 case include G4NDL3.10/Inelastic/F23/7_14_Nitrogen G4NDL3.10/Inelastic/F23/7_15_Nitrogen G4NDL3.10/Inelastic/F24/7_14_Nitrogen G4NDL3.10/Inelastic/F24/7_15_Nitrogen G4NDL3.10/Inelastic/F25/7_14_Nitrogen G4NDL3.10/Inelastic/F25/7_15_Nitrogen G4NDL3.10/Inelastic/F27/7_14_Nitrogen G4NDL3.10/Inelastic/F27/7_15_Nitrogen G4NDL3.10/Inelastic/F23/8_16_Oxygen G4NDL3.10/Inelastic/F24/8_16_Oxygen G4NDL3.10/Inelastic/F25/8_16_Oxygen G4NDL3.10/Inelastic/F27/8_16_Oxygen G4NDL3.10/Inelastic/F27/8_16_Oxygen I hope you can put in an appropriate fix as quickly and effectively as you addressed #943. Maybe this will also help solve other reports, like 821, 900, 902? Please be careful: it looks to me like simply initializing repFlag to some value won't be enough to make GetPhotons() and NeedsCascade() work correctly with the data loaded by InitPartials(), although I could be wrong.
Hi, Thank you very much for investigations. Unfortunately the case you mentioned corresponds to “the partial cross-section case", and it was mentioned on the line 204 of G4NeutronHPPhotonDist.cc v8.3 “// the partial cross-section case is not in this yet. @@@@” Thank you very much for your patience in this matter.
Hi This was impleneted some time before! So I close this entry. Tatsumi
