Linear Collider Forum



Home » Analysis and Reconstruction » Tracking & Vertexing » Recent Changes in MarlinTPC trunk
Changes in PulseFinder [message #2075 is a reply to message #2033] Wed, 22 September 2010 09:00 Go to previous messageGo to previous message
rosemann
Messages: 41
Registered: March 2009
Location: hamburg.de
Hi,

after only a couple of weeks I finally get to spend some time on updating/implementing some stuff into MarlinTPC again. So I pick up on the last meeting and Ralfs initial posting.

For now I concentrate on bringing the PulseFinderProcessor to version 1.0.

ralf wrote on Wed, 11 August 2010 08:51
[...]
In the PedestalSubstractor, I think the renaming of the override parameter from "MaximumADCValue" to "MaximumADCValueOverride" is a good idea. Maybe we should make this a convention to append to optional parameters like this the word "Override"?[...]


Yes, as discussed in the last meeting. I will try to prepare the PulseFinderProcessor as the first prototype with this scheme.

ralf wrote on Wed, 11 August 2010 08:51
[...]Regarding the use of the ConditionsMap for e.g. the Pedestals instead of the PedestalHandler:
To my surprise, this works even faster than the use of the two nested maps that were used before in the handler (although speed was one of the ideas behind that approach). And I like the idea with the default key_type types.

Nevertheless, I would still vote to use the PedestalHandler (or other "Handlers", which should probably all be renamed into sth. with ChangeListener, since they are derived from the IConditionsChangeListener); probably using the ConditionsMap approach inside.
The reason for this being that you can then handle in a consistent way missing conditions data for single channel in an event or even missing conditions for a whole time span.


I would separate the two aspects of design and implementation. The implementation (for speed, simplicity, ...) is the thing that needs to follow the design.

As also proposed in the meeting, and I hope I get it right this time:
1) The default way of providing "conditions data" to the event stream is via the Conditions Processor. How this special processor accesses the data is of no direct concern to us (e.g. database, some file).
2) A processor (downstream in the chain) accesses the conditions data by a "Listener" (or "Handler"), the naming is a bit unfortunate. Maybe we can agree on a single naming scheme here.
The processor in question then always has a listener/handler object that can access (with all the overhead) the relevant information.
3) For overriding this access method, one specifies the "OverrideValues". If these are present, they will precede over the values from the Handler/Listener. Best practice might be that the Handler/Listener isn't even instantiated in the processor; I'll see if I can come up with a halfway generic solution for the PulseFinderProcessor.


The second part is then the implementation. From what I have seen in the current (revision 2256) version of the PulseFinderProcessor, there is a mixture of two access methods to the conditions data, namely the Pedestals. One is the "PedestalHandler", the other one uses the ConditionsMap.
Since the Handler adds some functionality we might (or already do) want to have, I'm in favour of using this. Especially when the new and long debated features of LCCD/CondDBMySQL can be incorporated.
Either way, I am for a uniform way of doing this access.


Regards,
Christoph


When you have eliminated the impossible, whatever remains, however improbable, must be the truth. (Sir A.C. Doyle in Sign of Four)
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic:Measurement of Impact parameter
Next Topic:Inconsistencies with "Transience Flag"
Goto Forum:
  


Current Time: Thu Oct 18 13:58:35 Pacific Daylight Time 2018
.:: Contact :: Home ::.

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