Linear Collider Forum



Home » Analysis and Reconstruction » Tracking & Vertexing » Recent Changes in MarlinTPC trunk
Recent Changes in MarlinTPC trunk [message #2033] Wed, 11 August 2010 08:51 Go to next message
ralf
Messages: 43
Registered: August 2007
Location: DESY Hamburg
Hello everyone,

following the latest changes of the MarlinTPC trunk, I have found some problems and some suggestions/discussion topics.


---------------------------------------

In the latest trunk version (r2207), there seems to be an error in the tools/Field/FindCGA.cmake file. The path to the CGAPack library seems to look in the Geant4 lib directory. This kept this version from compiling at my place. After I changed the line
PATHS $ENV{G4LIB}/$ENV{G4SYSTEM}/

to
PATHS ${Mokka_HOME}/lib/$ENV{G4SYSTEM}/

it works for me.

---------------------------------------

On my computer, using latest trunk (r2207), a simple chain using the ConditionsProcessor, the TrackerRawDataToDataConverterProcessor and the PedestalSubtractorProcessor does always stop with:
*** glibc detected *** Marlin: double free or corruption

and then some more messages.
This worked in the last trunk revision before (r2198). Haven't yet figured out why this happens.

---------------------------------------

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

---------------------------------------

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.

For example: in the Pedestal"Handler", if a pedestal for a channel is missing, you get the value 0 for the value and -1 for the width. So your processor goes on processing without doing basically anything to the data. With the map solution, an exception will be thrown.
Of course, we would have to discuss what behavior is wanted in such a case (only a warning or really stopping the processing). This would of course also depend on the condition in question.

Also, using the latest versions of LCCD/CondDBMySQL, there is finally a solution how to treat times when a certain condition(s) is missing in the database. As far as I understood it, the proposed solution is to use a class derived from the ChangeListener and implement the handling of this case there.
With these changes, you can implement if to use in such a case a default value, the last valid conditions collection or stop processing. Also checks for which time span a condition is allowed to be missing (and probably the last valid one would be used) should be possible. From experience of other groups using real data, the case, that a condition missing for a short period of time, will happen.

---------------------------------------

Related to this and referring to this older thread:
I would still vote to use only one approach throughout MarlinTPC to access conditions data. In my opinion, using the ConditionsProcessor would be the cleanest way.
Using two ways makes making errors easier and finding errors harder. Also, the ConditionsProcessor does in principle the same thing as is done in the backup solution.

---------------------------------------


So, after going on for probably too long: tell me what you think Smile

Cheers, Ralf.
Re: Recent Changes in MarlinTPC trunk [message #2034 is a reply to message #2033] Wed, 11 August 2010 09:06 Go to previous messageGo to next message
ralf
Messages: 43
Registered: August 2007
Location: DESY Hamburg
Another question:

Shouldn't we get rid of this "#ifdef USE_LCCD" tests?
IMHO MarlinTPC depends on a conditions system and there is only LCCD available if we stick to the ILC software.

Cheers, Ralf.
Re: Recent Changes in MarlinTPC trunk [message #2035 is a reply to message #2033] Wed, 11 August 2010 12:16 Go to previous messageGo to next message
jabernathy
Messages: 78
Registered: March 2006
Location: University of Victoria
Hi Ralf,

ralf wrote on Wed, 11 August 2010 08:51

In the latest trunk version (r2207), there seems to be an error in the tools/Field/FindCGA.cmake file. The path to the CGAPack library seems to look in the Geant4 lib directory. This kept this version from compiling at my place. After I changed the line
PATHS $ENV{G4LIB}/$ENV{G4SYSTEM}/

to
PATHS ${Mokka_HOME}/lib/$ENV{G4SYSTEM}/

it works for me.


In the GNUMakefile.common the target directory for the CGAPack library is set as

LIBPACKNAME := libCGAPack.so
TARGETDIR := $(G4WORKDIR)/lib/$(G4SYSTEM)
LIBPACK := $(TARGETDIR)/$(LIBPACKNAME)


The problem occurs because G4WORKDIR is set differently when Mokka is installed by the ilctool scripts. In the new version of the file written by Jan both directories are used.

---------------------------------------

ralf wrote on Wed, 11 August 2010 08:51
On my computer, using latest trunk (r2207), a simple chain using the ConditionsProcessor, the TrackerRawDataToDataConverterProcessor and the PedestalSubtractorProcessor does always stop with:
*** glibc detected *** Marlin: double free or corruption

and then some more messages.
This worked in the last trunk revision before (r2198). Haven't yet figured out why this happens.


I don't have the same error using those processors. Can you send me your files so I can test it locally?

---------------------------------------

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


In the latest version of the trunk it is named correctly.

---------------------------------------

ralf wrote on Wed, 11 August 2010 08:51

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.


Regardless of the solution used I suggest that it is handled globally.

One disadvantage of creating ConditionMaps / ConditionHandlers is that they are created locally: ie one per processor. This leaves the possibility of two processors using different default values.

I'll respond to your other suggestion in the older thread to revive it Smile

- Jason
Re: Recent Changes in MarlinTPC trunk [message #2037 is a reply to message #2034] Thu, 12 August 2010 01:54 Go to previous messageGo to next message
killenberg
Messages: 125
Registered: July 2005
Location: CERN
Hello Ralf,

yes, I think we should remove the "#ifdef USE_LCCD" tests. The same hold for "#ifdef USE_GEAR" and "#ifdef USE_AIDA", which I think are also still in in some places.

MarlinTPC cannot run or compile without these packages, they are defined as dependencies in the CMakeLists.txt.

Cheers

Martin


Martin Killenberg

CERN
martin.killenberg@cern.ch
Re: Recent Changes in MarlinTPC trunk [message #2048 is a reply to message #2035] Thu, 12 August 2010 10:22 Go to previous messageGo to next message
ralf
Messages: 43
Registered: August 2007
Location: DESY Hamburg
Hi

thanks for the fast replies Smile

---------------------------------------

jabernathy wrote on Wed, 11 August 2010 12:16

ralf wrote on Wed, 11 August 2010 08:51
On my computer, using latest trunk (r2207), a simple chain using the ConditionsProcessor, the TrackerRawDataToDataConverterProcessor and the PedestalSubtractorProcessor does always stop with:
*** glibc detected *** Marlin: double free or corruption

and then some more messages.
This worked in the last trunk revision before (r2198). Haven't yet figured out why this happens.


I don't have the same error using those processors. Can you send me your files so I can test it locally?


I figured out that it happens after all the processing of the events is done (took some hours to run it in DEBUG mode).
Do you have access to AFS? Tomorrow, I could place the input files somewhere there.

---------------------------------------

jabernathy wrote on Wed, 11 August 2010 12:16

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


In the latest version of the trunk it is named correctly.


I know. I just wanted to point out, that I liked your idea and that one might do it like this in the other processors Smile


CU, Ralf.
Re: Recent Changes in MarlinTPC trunk [message #2050 is a reply to message #2048] Thu, 12 August 2010 12:34 Go to previous messageGo to next message
jabernathy
Messages: 78
Registered: March 2006
Location: University of Victoria
ralf wrote on Thu, 12 August 2010 10:22

I figured out that it happens after all the processing of the events is done (took some hours to run it in DEBUG mode).
Do you have access to AFS? Tomorrow, I could place the input files somewhere there.


I have access to AFS but I don't think I have a DESY login.

Another thing that might work is running it inside a debugger (if you haven't already).

> gdb Marlin
> set arg steering_file.xml
> run
> *** glibc detected *** Marlin: double free or corruption
> backtrace

---------------------------------------

ralf wrote on Thu, 12 August 2010 10:22

I know. I just wanted to point out, that I liked your idea and that one might do it like this in the other processors Smile


Thanks, it is always wise to keep variable_names_as_verbose_as_possible. Smile
Re: Recent Changes in MarlinTPC trunk [message #2051 is a reply to message #2033] Fri, 13 August 2010 10:24 Go to previous messageGo to next message
ralf
Messages: 43
Registered: August 2007
Location: DESY Hamburg
I have put the files of the now failing example here:
/afs/desy.de/group/flc/pool/rdiener/public

There is:

  • TPCRawData.slcio : file with 100 events (7 modules with 5000 channels each)
  • condDB_pedestal_HEAD_1262304000000000000.slcio : contains the pedestals as simple file
  • pedestal_substraction_trunk.xml : MarlinTPC steering file; the MaximumADCValueOverride parameter is set wrong (should be 255), but this shouldn't be a problem. I have now set that is processes 3 events, since it doesn't matter for the error how many events it processes.
  • generateRawData.cpp : a small program with which I created the raw data - not programmed too clean (more copy&pasted from other programs I had). The pedestals are calculated from the RawData using the PedestalCalculator.


I hope there are no problems with access rights. They should be set in the right way now.

I tried the debugger, but at least for me it didn't provide much useful information.
I hope it isn't some embarrassing, simple error I overlooked Smile

[Updated on: Fri, 13 August 2010 10:25]

Re: Recent Changes in MarlinTPC trunk [message #2052 is a reply to message #2033] Mon, 16 August 2010 01:09 Go to previous messageGo to next message
sailer
Messages: 34
Registered: February 2009
ralf wrote on Wed, 11 August 2010 08:51

On my computer, using latest trunk (r2207), a simple chain using the ConditionsProcessor, the TrackerRawDataToDataConverterProcessor and the PedestalSubtractorProcessor does always stop with:
*** glibc detected *** Marlin: double free or corruption

and then some more messages.
This worked in the last trunk revision before (r2198). Haven't yet figured out why this happens.


Hi,
this looks very similar to some problem I also encountered, it had to do with the fact that some libraries were loaded twice, due to the fact that one they showed up in the wrong place of the MARLIN_DLL. If one of the libraries loaded first are linked to one of the libraries loaded later they are "unloaded" twice at the end, which is not possible and this error shows up.

If that is the reason, the error should also show up if just running
Marlin -c steering.xml

Cheers,
André
Re: Recent Changes in MarlinTPC trunk [message #2053 is a reply to message #2033] Tue, 17 August 2010 09:12 Go to previous messageGo to next message
ralf
Messages: 43
Registered: August 2007
Location: DESY Hamburg
Hi,

sorry for the late reply, but I wasn't at work yesterday.

Thanks for the tip André, although I have to admit I don't fully understand your comment.
Actually, it also happens when I only start Marlin (without any steering file or other command line options), which I tried after the Marlin -c test.

When comparing the two MarlinTPC libraries, the difference was mainly the inclusion of the CGAPack lib. After I compiled the newer version without Mokka, the error was gone.
I used Geant4 9.3 with Mokka 07-04 from the latest ILCSoft release (v01-09).


CU, Ralf.

Re: Recent Changes in MarlinTPC trunk [message #2054 is a reply to message #2053] Tue, 17 August 2010 09:36 Go to previous messageGo to next message
sailer
Messages: 34
Registered: February 2009
Hi,
I'll try to explain more clearly. Smile

I encountered this problem, when my MARLIN_DLL looked something like this

MARLIN_DLL=libMarlinPandora.so:libPandoraPFANew.so

Now libMarlinPandora depends on PandoraPFA, so when MarlinPandora was loaded by Marlin, it also loads libPandoraPFANew, which is then loaded again by Marlin, because it is in the MARLIN_DLL.
(PandoraPFANew is now no longer added to the MARLIN_DLL.)

At the end the library is tried to be "unloaded" twice or what ever happens at the end of a program, which causes this "double free".

The CGAPack lib contains a lot of libraries, maybe one of them was loaded twice, like for me with the PandoraPFANew?

Cheers,
Andre
Re: Recent Changes in MarlinTPC trunk [message #2055 is a reply to message #2033] Tue, 17 August 2010 09:50 Go to previous messageGo to next message
ralf
Messages: 43
Registered: August 2007
Location: DESY Hamburg
Thanks for the detailed explanation Smile

I will check this...

CU, Ralf.
Re: Recent Changes in MarlinTPC trunk [message #2062 is a reply to message #2033] Wed, 18 August 2010 05:23 Go to previous messageGo to next message
ralf
Messages: 43
Registered: August 2007
Location: DESY Hamburg
Just to stay up-to-date:

I looked at the libraries but couldn't spot anything obvious. Jan said he would try to reproduce the problem. I hope he spots something Smile
Re: Recent Changes in MarlinTPC trunk [message #2064 is a reply to message #2051] Thu, 19 August 2010 07:02 Go to previous messageGo to next message
engels
Messages: 106
Registered: August 2006
Hi Ralf,

i get 'permission denied' when trying to access:
/afs/desy.de/group/flc/pool/rdiener/public

Cheers,
Jan
Re: Recent Changes in MarlinTPC trunk [message #2065 is a reply to message #2064] Thu, 19 August 2010 08:54 Go to previous messageGo to next message
engels
Messages: 106
Registered: August 2006
ok, now it's working Wink

even running with the files in your public in an SL5 machine I could not reproduce the problem Sad

anyway, here the output from ldd in my MarlinTPC library:

$ ldd $MARLIN_DLL
	linux-gate.so.1 =>  (0xffffe000)
	libMarlin.so.0.12 => /scratch/engels/nbuilds/2010-08-19/nb-release/Marlin/HEAD/lib/libMarlin.so.0.12 (0xf7ec4000)
	liblcio.so.1.51 => /scratch/engels/nbuilds/2010-08-19/nb-release/lcio/HEAD/lib/liblcio.so.1.51 (0xf7df1000)
	libsio.so.1.51 => /scratch/engels/nbuilds/2010-08-19/nb-release/lcio/HEAD/lib/libsio.so.1.51 (0xf7de0000)
	libdcap.so => /scratch/engels/nbuilds/2010-08-19/nb-release/dcap/1.9.5-5/lib/libdcap.so (0xf7dc5000)
	libgearxml.so.0.14 => /scratch/engels/nbuilds/2010-08-19/nb-release/gear/HEAD/lib/libgearxml.so.0.14 (0xf7d84000)
	libgear.so.0.14 => /scratch/engels/nbuilds/2010-08-19/nb-release/gear/HEAD/lib/libgear.so.0.14 (0xf7d2b000)
	libMarlinTPCAnalysis.so.0.0 => /scratch/engels/nbuilds/2010-08-19/nb-release/MarlinTPC/HEAD/lib/libMarlinTPCAnalysis.so.0.0 (0xf7cba000)
	libMarlinTPCValidation.so.0.0 => /scratch/engels/nbuilds/2010-08-19/nb-release/MarlinTPC/HEAD/lib/libMarlinTPCValidation.so.0.0 (0xf7c8f000)
	libMarlinTPCDigitisation.so.0.0 => /scratch/engels/nbuilds/2010-08-19/nb-release/MarlinTPC/HEAD/lib/libMarlinTPCDigitisation.so.0.0 (0xf7c26000)
	libMarlinTPCCalibration.so.0.0 => /scratch/engels/nbuilds/2010-08-19/nb-release/MarlinTPC/HEAD/lib/libMarlinTPCCalibration.so.0.0 (0xf7c06000)
	libMarlinTPCSimulation.so.0.0 => /scratch/engels/nbuilds/2010-08-19/nb-release/MarlinTPC/HEAD/lib/libMarlinTPCSimulation.so.0.0 (0xf7bd8000)
	libMarlinTPCPhotoelectricSimulation.so.0.0 => /scratch/engels/nbuilds/2010-08-19/nb-release/MarlinTPC/HEAD/lib/libMarlinTPCPhotoelectricSimulation.so.0.0 (0xf7bcb000)
	libMarlinTPCCloudSimulation.so.0.0 => /scratch/engels/nbuilds/2010-08-19/nb-release/MarlinTPC/HEAD/lib/libMarlinTPCCloudSimulation.so.0.0 (0xf7b91000)
	libMarlinTPCReconstruction.so.0.0 => /scratch/engels/nbuilds/2010-08-19/nb-release/MarlinTPC/HEAD/lib/libMarlinTPCReconstruction.so.0.0 (0xf7a67000)
	libMarlinTPCPhotoelectricReconstruction.so.0.0 => /scratch/engels/nbuilds/2010-08-19/nb-release/MarlinTPC/HEAD/lib/libMarlinTPCPhotoelectricReconstruction.so.0.0 (0xf7a29000)
	libtpcconddata.so.0.0 => /scratch/engels/nbuilds/2010-08-19/nb-release/MarlinTPC/HEAD/lib/libtpcconddata.so.0.0 (0xf7a02000)
	libMarlinTPC_tools_Position.so.0.0 => /scratch/engels/nbuilds/2010-08-19/nb-release/MarlinTPC/HEAD/lib/libMarlinTPC_tools_Position.so.0.0 (0xf79fa000)
	libPadGeometryChecker.so.0.0 => /scratch/engels/nbuilds/2010-08-19/nb-release/MarlinTPC/HEAD/lib/libPadGeometryChecker.so.0.0 (0xf79f1000)
	libHepRepOutput.so.0.0 => /scratch/engels/nbuilds/2010-08-19/nb-release/MarlinTPC/HEAD/lib/libHepRepOutput.so.0.0 (0xf79da000)
	libMarlinTPCField.so.0.0 => /scratch/engels/nbuilds/2010-08-19/nb-release/MarlinTPC/HEAD/lib/libMarlinTPCField.so.0.0 (0xf79b7000)
	libMarlinTPCToolProcessors.so.0.0 => /scratch/engels/nbuilds/2010-08-19/nb-release/MarlinTPC/HEAD/lib/libMarlinTPCToolProcessors.so.0.0 (0xf7985000)
	libIntersectionCalculator.so.0.0 => /scratch/engels/nbuilds/2010-08-19/nb-release/MarlinTPC/HEAD/lib/libIntersectionCalculator.so.0.0 (0xf7981000)
	libLCObjectCopier.so.0.0 => /scratch/engels/nbuilds/2010-08-19/nb-release/MarlinTPC/HEAD/lib/libLCObjectCopier.so.0.0 (0xf797d000)
	libgsl.so.0 => /afs/desy.de/group/it/ilcsoft/gsl/1.8/lib/libgsl.so.0 (0xf781e000)
	libgslcblas.so.0 => /afs/desy.de/group/it/ilcsoft/gsl/1.8/lib/libgslcblas.so.0 (0xf77f0000)
	liblccd.so.1.0 => /scratch/engels/nbuilds/2010-08-19/nb-release/lccd/HEAD/lib/liblccd.so.1.0 (0xf77c9000)
	libCore.so => /afs/desy.de/group/it/ilcsoft/root/5.26.00b/lib/libCore.so (0xf7115000)
	libCint.so => /afs/desy.de/group/it/ilcsoft/root/5.26.00b/lib/libCint.so (0xf6b61000)
	libRIO.so => /afs/desy.de/group/it/ilcsoft/root/5.26.00b/lib/libRIO.so (0xf69e5000)
	libNet.so => /afs/desy.de/group/it/ilcsoft/root/5.26.00b/lib/libNet.so (0xf68e7000)
	libHist.so => /afs/desy.de/group/it/ilcsoft/root/5.26.00b/lib/libHist.so (0xf6566000)
	libGraf.so => /afs/desy.de/group/it/ilcsoft/root/5.26.00b/lib/libGraf.so (0xf63bc000)
	libGraf3d.so => /afs/desy.de/group/it/ilcsoft/root/5.26.00b/lib/libGraf3d.so (0xf62d9000)
	libGpad.so => /afs/desy.de/group/it/ilcsoft/root/5.26.00b/lib/libGpad.so (0xf621e000)
	libTree.so => /afs/desy.de/group/it/ilcsoft/root/5.26.00b/lib/libTree.so (0xf6074000)
	libRint.so => /afs/desy.de/group/it/ilcsoft/root/5.26.00b/lib/libRint.so (0xf604a000)
	libPostscript.so => /afs/desy.de/group/it/ilcsoft/root/5.26.00b/lib/libPostscript.so (0xf600a000)
	libMatrix.so => /afs/desy.de/group/it/ilcsoft/root/5.26.00b/lib/libMatrix.so (0xf5e04000)
	libPhysics.so => /afs/desy.de/group/it/ilcsoft/root/5.26.00b/lib/libPhysics.so (0xf5d7f000)
	libMathCore.so => /afs/desy.de/group/it/ilcsoft/root/5.26.00b/lib/libMathCore.so (0xf5bd8000)
	libThread.so => /afs/desy.de/group/it/ilcsoft/root/5.26.00b/lib/libThread.so (0xf5b95000)
	libMinuit2.so => /afs/desy.de/group/it/ilcsoft/root/5.26.00b/lib/libMinuit2.so (0xf5a77000)
	libCLHEP-2.0.4.2.so => /afs/desy.de/group/it/ilcsoft/CLHEP/2.0.4.2/lib/libCLHEP-2.0.4.2.so (0xf5925000)
	libRAIDA.so.1.4 => /scratch/engels/nbuilds/2010-08-19/nb-release/RAIDA/HEAD/lib/libRAIDA.so.1.4 (0xf587c000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xf5767000)
	libm.so.6 => /lib/libm.so.6 (0xf5740000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf5734000)
	libc.so.6 => /lib/libc.so.6 (0xf55f0000)
	libstreamlog.so.0.1 => /scratch/engels/nbuilds/2010-08-19/nb-release/Marlin/HEAD/lib/libstreamlog.so.0.1 (0xf55eb000)
	libz.so.1 => /usr/lib/libz.so.1 (0xf55d7000)
	libdl.so.2 => /lib/libdl.so.2 (0xf55d3000)
	libpthread.so.0 => /lib/libpthread.so.0 (0xf55bc000)
	libconddb.so.0 => /scratch/engels/nbuilds/2010-08-19/nb-release/CondDBMySQL/HEAD/lib/libconddb.so.0 (0xf553a000)
	libncurses.so.5 => /usr/lib/libncurses.so.5 (0xf54f1000)
	libcrypt.so.1 => /lib/libcrypt.so.1 (0xf54be000)
	/lib/ld-linux.so.2 (0x00b77000)
	libmysqlclient.so.15 => /afs/desy.de/group/it/ilcsoft/mysql/5.0.45/lib/mysql/libmysqlclient.so.15 (0xf5460000)
	libnsl.so.1 => /lib/libnsl.so.1 (0xf5448000)



Cheers,
Jan
Changes in PulseFinder [message #2075 is a reply to message #2033] Wed, 22 September 2010 09:00 Go to previous messageGo to next 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)
Re: Recent Changes in MarlinTPC trunk [message #2086 is a reply to message #2033] Fri, 15 October 2010 08:41 Go to previous message
ralf
Messages: 43
Registered: August 2007
Location: DESY Hamburg
Late solution, but I thought, I anyway keep this thread up-to-date:
The
*** glibc detected *** Marlin: double free or corruption

problem is now solved. I used the latest release of ILCSoft v01-09-03 and since then it has vanished (it was still present with v01-09-02). Could be that the cause is removed since this is the first time SL5/32bit is especially considered in the ilcinstaller.



Previous Topic:Measurement of Impact parameter
Next Topic:Inconsistencies with "Transience Flag"
Goto Forum:
  

[ PDF ]

Current Time: Sun Sep 22 16:08:25 Pacific Daylight Time 2019
.:: Contact :: Home ::.

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