Linear Collider Forum

Home » Software Tools » Marlin et al » ADCElectronicsHandler, PedestalHandler constructors
Re: ADCElectronicsHandler, PedestalHandler constructors [message #2047 is a reply to message #2036] Thu, 12 August 2010 10:06 Go to previous messageGo to previous message
Messages: 43
Registered: August 2007
Location: DESY Hamburg
Hi Jason,

jabernathy wrote on Wed, 11 August 2010 13:07

I think this is a very good idea. Having at least three different places of accessing conditions data in a processor (GEAR, LCCD/tpcconddata, processor parameters) is difficult to maintain.

I agree, the possibility to define conditions values in Gear is a very unfortunate legacy. But this discussion is going on since a long time and I expect that this will not be changed anytime soon (again: unfortunately).

IMHO the override parameters are not a real problem as long as they are marked as such and the description makes this clear to the user. Usually they are only used during development -or at least that's how I understand them.
Maybe they should be removed after a processor is in a working state Smile

jabernathy wrote on Wed, 11 August 2010 13:07

I was wondering if we could produce a processor which combines this data into LCCD. This processor would be pretty complex as it would have to:

  • intercept the incoming lccd data stream from any source (database, file, ...)
  • convert any outside data (GEAR, etc) into conditions data
  • override any conditions with processor parameters
  • supply default values if conditions are missing
  • notify any change listeners of the new data

I also suggest that the responsibility of processors to register maps or conditions listeners is removed. When writing a processor one should not have to specify where the data is coming from; that should be handled elsewhere so it is uniformly used during the entire reconstruction.

This sounds a bit like a different framework than the one we use now Wink

The idea behind LCCD is to have one place where you get conditions data from (no matter if they come from a (database-/simple-)file or a database. The other options are workarounds that should IMO not be used in "real life". They make error catching harder and the reproducibility is minimized.

If you define a "Handler"/ChangeListener you can access the data in a consistent state -including possible default values. At least as long as every processor using the data uses the same listener.
One reason why I like the idea with the conditions processor (without any other option besides): since you define your sources in the steering file in adjoining lines, mismatchs are spotted quite easily.

I am not saying that this system is the perfect way to do it, but as I see it, it is kind of given by the framework we're using.

I personally don't see the problem that you register the "handler"/listener in the processor. But maybe I don't understand your proposal correctly.

Cheers, Ralf.

Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic:v01-09 install by ilcsoft-install fails at gear v00-14-01 install
Next Topic:TPCDigiProcessor when padTheta = nan
Goto Forum:

Current Time: Thu Feb 20 19:26:32 Pacific Standard Time 2020
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.1.
Copyright ©2001-2010 FUDforum Bulletin Board Software