You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

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
GR v17r34p0rhel4B:  http://glast-ground.slac.stanford.edu/SystemTests/?releaseVersionId=11881
Use v17r34p0 as a reference which is the RHEL3 version of the systests.

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()) {  
        if (m_mask==0xffffffff) log.stream() << "No trigger requirement";  
        else            log.stream() << "Applying trigger mask: " <<  std::setbase(16) <<m_mask <<std::setbase(10);  
        if( m_throttle) log.stream() <<", throttled by rejecting  the value "<< m_vetobits;
    }
log << endreq;

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."

  • No labels