| Bug in parameter handling? [message #12082] |
Sun, 19 June 2011 11:50  |
Felix Boehmer
Messages: 149
Registered: May 2007
Location: Munich
|
first-grade participant |
From: *gsi.de
|
|
Dear framework experts,
on our bug hunt we came across a strange behavior in the parameter management.
Apparently, when reading the parameters from the ASCII file, everything works, meaning up to the digi macro.
However, when reading in the root parameter files in the reco macro, with EXACTLY the same calls for first and second input, the parameter files are no longer found (e.g. the GAS file seems to be looked up in the wrong path)!
After 2 days of checking and re-checking every line of code in the fitting algorithms to find the problem I now have to conclude that something like a missing geometry must be the problem of the fit as well.
What is going on? Can somebody imagine how this could have been introduced with the latest upgrade? I have been working on 2 weeks old version of the rest-framework before ...
Can somebody confirm this behavior? I know that Dima saw the same thing for the TPC reco macro. Is somebody having likewise problems with the STT reco? If not, then something with the macro has to be off, but I can't find it. And I wonder why it has worked before ...
Cheers
Felix
[Updated on: Sun, 19 June 2011 11:52] Report message to a moderator |
|
|
|
| Re: Bug in parameter handling? [message #12084 is a reply to message #12082] |
Sun, 19 June 2011 12:16  |
Dima Melnychuk
Messages: 213
Registered: April 2004
Location: National Centre for Nucle...
|
first-grade participant |
From: *play-internet.pl
|
|
Hi Felix,
Talking about problem of GAS file, it's not a problem of parameter handling.
It's a problem that in PndTpcRiemannTrackingTask position of GAS file is taken not from parameters file but hardcoded value without path is used.
Calling PndTpcRiemannTrackingTask::Init at line 219
fnsectors= PndTpcDigiMapper::getInstance()->getPadPlane()->GetNSectors();
PndTpcDigiMapper is called.
If PndTpcDigiMapper was not properly initialised before, its constructor is called
PndTpcDigiMapper::PndTpcDigiMapper(bool autoinit)
with autoinit=true
and hardcoded file names are used without any path
if(autoinit){
// objects instantiated here may be replace with the init method!
fgas= new PndTpcGas("NEON-90_CO2-10_B2_PRES1013.asc",400);
//TODO: Get these things from Database!!!
fgem=new PndTpcGem(5000, // Gain
0.02); // Spread
fzGem=0.;
fpadShapes = new PndTpcPadShapePool("2mmPads.dat",
*fgem,
0.5, // lookup range
0.02, // Lookup Step
0.01); // LookupIntegrationStep
fpadPlane= new PndTpcPadPlane("padplane.dat", fpadShapes);
}
When tpc reco macro contained PndTpcClusterFinderTask initialised before PndTpcRiemannTrackingTask
there at line 128 PndTpcDigiMapper was properly initialised with parameters from RTDB
PndTpcDigiMapper::getInstance(false)->init(fpadplane,fgem,fgas,fpar->getPadShapes(),fzGem,t0,sf);
and later in PndTpcRiemannTrackingTask this properly initialised instance was called.
Dima
|
|
|
|
|
|
|
|
GSI Forum
Search
Help
Members
Login
Home
