Linear Collider Forum



Home » Analysis and Reconstruction » Tracking & Vertexing » Conditons Data for MarlinTPC
Conditons Data for MarlinTPC [message #1458] Fri, 02 May 2008 04:48 Go to next message
killenberg
Messages: 125
Registered: July 2005
Location: CERN
In preparation for data taking with the large prototype (LP) TPC I would like to present the current status of the TPCCondData (lccd/lcio conditions data objects in the MarlinTPC package) and discuss what has to be changed/implemented.

Current status (MarlinTPC r1076):
  • ADCChannelMapping
    Mapping of H/W channles to GEAR pad indices
    • ChannelID
    • PadID
    • Type
  • ChannelCorrection
    Per channel calibration
    • Quality flags (broken, noisy)
    • Calibration factors
    • Time offset
  • Pedestal
    Per channel
    • Value
    • Width
  • TPCConditions
    Calibrated TPC Parameters
    • DriftVelocity
    • Diffusion (trans/long)
    • "Defocussing"
    • Amplification
  • GasConditions
    • Mixture
    • Pressure
    • Temperature
    • OxygenContent
    • WaterContent
  • FieldSettings
    • Nominal drift field
    • Nominal B-Field
    Especiall for GEMs
    • GEM voltages
    • Transfer fields
  • WeatherConditions
    • Temperature
    • Humidity
    • Pressure
  • TimePixPixelMode
    • Mode
    • Status (broken/noisy)


Results from the LP software meeting on 2008-04-30 http://ilcagenda.linearcollider.org/conferenceDisplay.py?con fId=2692:

  • The readout specific items ADCChannelMapping, ChannelCorrection, Pedestal and FieldSettings need a ModuleID to be able to handle multiple modules
  • The FieldSettings need information whether GEMs or Micromegas have been used, and store the Micromegas voltage.
  • The FieldSettings will be replaced by VoltageSettings, which is the more basic information. A handler implemented as LCCDChangeListener will provide the field settings and can recalibrate the fields in case improved information on the cathode position or GEM spacing is available.
  • Data objects for TriggerConditions (cosmic or beam trigger, which scintillator slab has fired) and BeamConditions (particle typ, particle energy) have to be defined
  • The magnetic field map and the map with electric field distortions are stored as conditions data (detailes description see below). There is a B-Field in GEAR, but it is only a homogeneous field. Especially the E-field can change due to ion backdrift, so it cannot be stored in the geometry description.


The magnetic and electric field consist of a simple conditionsdata class to
store the field on a 3D grid
  • 3 ints (x, y, z) for the voxel index
  • 3 floats for the field in x, y ,z

The grid infomation (coordinate of voxel 0,0,0 and bin width in x, y, z) are
stored as collection parameters.

Handler classes allow simple access to the fields (for instance
MagneticFieldHandler::getMagneticField(float *position)). These handlers
update the fields and perform the overlay e. g. of static electric field and
field distortions from ion backdrift. As an example the proposed class
structure for the magnetic field is attached. Actually the design has already
been improved wrt. this image: getMagneticField returns a struct with the three
values instead of a pointer to simplify the memory management.

Proposal: The E-field and B-field classes and the handlers should not be
stored together with the other conditions data but have a separate section, so
one does not always have to link the whole, rather large field-handler package.


Martin Killenberg

CERN
martin.killenberg@cern.ch
Re: Conditons Data for MarlinTPC [message #1460 is a reply to message #1458] Fri, 02 May 2008 13:32 Go to previous messageGo to next message
jabernathy
Messages: 78
Registered: March 2006
Location: University of Victoria
Would it be useful if there were a field somewhere which stored the precision of the readout electronics?

I think it would be useful in determining whether a pulse was an overflow or underflow. However, I'm not sure if it would be a per-channel parameter.

Currently in the simulation I am working with the signal is shaped and then digitized. The digitizer has N number of bits and I store that in a ChannelCorrection::calibration factor, along with other factors.
Re: Conditons Data for MarlinTPC [message #1462 is a reply to message #1460] Fri, 02 May 2008 14:18 Go to previous messageGo to next message
jabernathy
Messages: 78
Registered: March 2006
Location: University of Victoria
Another condition which may be useful is the polarity of the readout electronics.
Re: Conditons Data for MarlinTPC [message #1857 is a reply to message #1458] Thu, 17 September 2009 05:52 Go to previous messageGo to next message
rosemann
Messages: 41
Registered: March 2009
Location: hamburg.de
Hi Martin,

pushing up the old topic a bit. I think there are two items missing in the "TPCConditions" section:
- readout frequency of the electronics
- electronics polarity

And somehow I can't really spot a nice way to incorporate the conversion between ADC counts and charge -- either in terms of number of primary electrons or the actual charge on the readout. Or is that supposed to be the "calibration factors" for the "ChannelCorrection" ?

Hoping to revive the thread,
Christoph


When you have eliminated the impossible, whatever remains, however improbable, must be the truth. (Sir A.C. Doyle in Sign of Four)
Re: Conditons Data for MarlinTPC [message #1862 is a reply to message #1458] Fri, 25 September 2009 08:23 Go to previous messageGo to next message
ralf
Messages: 43
Registered: August 2007
Location: DESY Hamburg
Another topic, that will need attention in the next weeks/months, is the way we want to store the conditions data in the database.

The way I understand it the database holds a folder structure and every folder contains the objects for one specific condition. In the folder you can access the objects by the timestamp and a tag. So if you write new (for example: corrected) conditions for a specific time there, you can later choose which ones to use by the tag. I would suggest that we tag every version.
Another question is how to tag? Maybe always start with 1 (assuming that the conditions data are right in the beginning) and for smaller changes sth. like 01.01 and for larger changes 02.00 ...


For the basic folder structure, I would suggest sth. like:
/lctpc/large_prototype/<location>/<module>/<condition>/

One could even think of subdividing this structure by the types of conditions (see Martins list above)?!

Before we do this, we would also have to decide, which data is stored together in an object and which alone in a single object. For the Pedestals this is for example already fixed and the value and the width are in the same object.

Does anybody have an opinion about this? Maybe this would be a topic for a MarlinTPC Meeting or the mailing list (so every group is aware of this fact).
Re: Conditons Data for MarlinTPC [message #1891 is a reply to message #1458] Fri, 04 December 2009 02:50 Go to previous messageGo to next message
ralf
Messages: 43
Registered: August 2007
Location: DESY Hamburg
Regarding the folder structure in the conditions database, here is a new proposal:
/lctpc/large_prototype_1/<location>/<runnumber>/<condition >[/<module>]

I introduced the run number in my proposal. This is due to the fact, that the tagging of conditions can only be done on a folder basis. Since I guess one would want to tag conditions data for each run separately, I think we have to include the run number in the path.
The question is now where in the path? Smile

Re: Conditons Data for MarlinTPC [message #1892 is a reply to message #1891] Fri, 04 December 2009 03:06 Go to previous messageGo to next message
killenberg
Messages: 125
Registered: July 2005
Location: CERN
Hello Ralf,

I do not know if LCCD works correcly if the data is stored in a different folder for each run. And there is also some data that is not correlated to a run, the gas conditions or the environmental conditions for instance. These are written to the data base with a time stamp in regular intervals, no matter if a run is active or not.

For those data that are (or can be) correlated with a run this structure might be good.

I also have some questions:

  • What does tagging of data mean? Is it something specific for LCCD/CondDBMySQL?
  • What is location?
  • Is module the readout module on the end plate? If yes we should not have it in the folder structure but as a data member of the condition.


Cheers

Martin


Martin Killenberg

CERN
martin.killenberg@cern.ch
Re: Conditons Data for MarlinTPC [message #1893 is a reply to message #1892] Fri, 04 December 2009 05:18 Go to previous messageGo to next message
ralf
Messages: 43
Registered: August 2007
Location: DESY Hamburg
killenberg


I do not know if LCCD works correcly if the data is stored in a different folder for each run. And there is also some data that is not correlated to a run, the gas conditions or the environmental conditions for instance. These are written to the data base with a time stamp in regular intervals, no matter if a run is active or not.



You're right, I haven't thought of these...
But this shouldn't be a problem with LCCD. You have to specify a folder for every condition object anyway and it's no problem if they differ. The only problem would be if you use run specific conditions and reconstruct data from two or more runs in one call of MarlinTPC. I guess this is no the usual use case.

So my proposal should read ([] brackets for optional folders):
/lctpc/large_prototype_1/<location>/[<runnumber>]/<condition >[/<module>]

So we could store run depended conditions with the run number and the rest without.


killenberg


For those data that are (or can be) correlated with a run this structure might be good.

I also have some questions:

  1. What does tagging of data mean? Is it something specific for LCCD/CondDBMySQL?
  2. What is location?
  3. Is module the readout module on the end plate? If yes we should not have it in the folder structure but as a data member of the condition.




Here the answers:
  1. Tagging means, that you have in LCCD the possibility to assign a tag (std::string) to a folder. This is nessesary to retrieve old data if you have written new one in a folder for the same time period. Then the older data is available only via the tag.
  2. With location I mean the physical place of the measurement like "DESY_T24-1" for example. This idea came actually from CALICE who found it useful.
  3. Yes, I meant the readout module. This I added as an additional, optional (therefore the [] brackets) sub-folder in case there are conditions where it makes sense to split them like this. For most conditions, you wouldn't need it. Like for the pedestals, this distinction is done in the condition object. Right now I can't think of a situation, where it is necessary, but I wanted to include the idea as an option nevertheless...



CU, Ralf.
Re: Conditons Data for MarlinTPC [message #1991 is a reply to message #1458] Fri, 14 May 2010 17:47 Go to previous messageGo to next message
jabernathy
Messages: 78
Registered: March 2006
Location: University of Victoria
What about adding a parameter for gain in the ChannelCorrection class?

This would allow a consistent method for doing channel-by-channel gain correction in the GainCorrectorProcessor.
Re: Conditons Data for MarlinTPC [message #2012 is a reply to message #1991] Wed, 02 June 2010 09:46 Go to previous message
ralf
Messages: 43
Registered: August 2007
Location: DESY Hamburg
jabernathy wrote on Fri, 14 May 2010 17:47

What about adding a parameter for gain in the ChannelCorrection class?

This would allow a consistent method for doing channel-by-channel gain correction in the GainCorrectorProcessor.


When checking the class, I also noticed, that it does not seem to be multi-module compatible.
If someone needs the amplification gain separately -which I could imagine is the case in the simulation- it would be good to store it there. For the normal combined amplification/electronics gain correction, the calibration factor should be enough. Or am I missing something?

Proposal: I would implement it in a way, that if it isn't set (you don't always know this value), the object returns 1.0, so a multiplication wouldn't change anything. But you could still set the other correction values and use them.
Similar to the pedestals, where the handler returns 0.0 when there is no value, so that the loop can run even when there is no value for a particular channel...

Since I am -slowly- going through the conditions objects anyway, I can look after this.

CU, Ralf.
Previous Topic:Fitting scheme
Next Topic:Hit errors in MarlinTPC
Goto Forum:
  

[ PDF ]

Current Time: Sat Feb 22 08:16:41 Pacific Standard Time 2020
.:: Contact :: Home ::.

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