Michael Kuss is kindly leading the charge to check that our simulation results when running RHEL4 builds of GlastRelease are at statistically equivalent to our RHEL3 builds.
Simulations Run
GR v17r34p0rhell4 in systests see: http://glast-ground.slac.stanford.edu/SystemTests/?releaseVersionId=11861
Unsigned versus Signed Ints
There are a number of warnings in our builds concerning unsigned/signed match. These should be looked over and fixed.
An audit of existing JO properties is also in order to check for mismatches, as these will not be caught at compile time.
One specific JO issue concerns TriggerAlg.mask:
Trigger: there is something really weird with the trigger mask:
In the jobOptions:
TriggerAlg.mask = -1;
rh9_gcc32opt logs:
TriggerAlg INFO No trigger requirement
rhel_gcc34opt logs:
TriggerAlg INFO Applying trigger mask: 589cba38
In TriggerAlg::TriggerAlg() we find:
declareProperty("mask" , m_mask=0xffffffff);
and later, in TriggerAlg::initialize()
log << MSG::INFO;
if(log.isActive())
mask is an unsigned int. For the moment, could we rerun both systests with simply the Trigger.mask=-1; line commented, as all bits set is the default anyway? And note anyway that the code should be changed? rh9 interprets correctly in the sense that with (signed int)-1 0xffffffff is intended. How rhel4 comes up with 0x589cba38 beats me.
Suggested Fix:
Make TriggerAlg.m_mask a StringProperty and convert the value to an unsigned int via the tools available in facilities::Util. This has been tried out and seems to work.
Exception in CalLikelihoodManagerTool
rhel4 also contains one event that threw an exception in CalLikelihoodManagerTool
Random Sequences Diverge
"As Richard mentioned, the two random sequences will diverge eventually. Hence, the particle mix for the 40k triggers is different. The biggest discrepancy is in "1002 CrElectronSplash", with 6409 trigger for rh9_gcc32opt vs. 6603 for rhel4. Consequently, the other sources are weighted stronger in rh9, in general."