Redmine: Issueshttps://redmine.jlab.org/https://redmine.jlab.org/favicon.ico?16338348402017-05-17T21:56:27ZRedmine
Redmine Hall A Analyzer - Feature #52 (In Progress): Output data should support integer types and morehttps://redmine.jlab.org/issues/522017-05-17T21:56:27ZOle Hansenole@jlab.org
<p>Currently, THaOutput writes out every variable as Double_t. At the minimum, Int_t should also be a supported output type. Having at least a basic integer type will improve accuracy and reduce the output file size.</p>
<p>Additionally, data that are contiguous in memory should be streamed directly, without copying them to a dummy location. The ROOT tree branch address can simply be set to the start of the memory region.</p>
<p>Also, if arrays are parallel, i.e. multiple variables from objects in a TClonesArray, there should only be one array size counter, not one for each variable. Redundant array size counters should be detected automatically. Of course, this optimization will break scripts that explicitly used those counters. I am not sure if people actually used those counters much.</p> Hall A Analyzer - Bug #51 (New): Replace fEvtHdr.fEvtNum with absolute event counterhttps://redmine.jlab.org/issues/512017-05-17T21:53:47ZOle Hansenole@jlab.org
<p>If one replays multiple input files in a single analysis session (to add all their events together in the output), duplicate event numbers appear in the event header. This is expected since the event number recorded there is simply the CODA event number of the respective input file, which usually start at 1 for each file. However, what's missing is some sort of continuous counter for the effective event number. Perhaps we should replace fEvtHdr.fEvtNum with this counter value. To keep the original information available, we could add fRawEvtNum (=CODA even number) and fInputFileIdx (input file index). Also, at least the continuous counter should be a 64-bit integer since one might conceivably have more than 2G/4G events.</p> Hall A Analyzer - Bug #50 (New): Replay of multiple input files should save all Run_Data objectshttps://redmine.jlab.org/issues/502017-05-17T21:33:10ZOle Hansenole@jlab.org
<p>It looks like currently the number of versions of all objects in the output file is pruned to 2. This is fine for trees and histograms (I guess), but if more than 2 input files where analyzed into a single output, one wants all the Run_Data info.</p> Hall A Analyzer - Feature #49 (In Progress): THaHRS algorithm reorganizationhttps://redmine.jlab.org/issues/492017-05-17T21:28:43ZOle Hansenole@jlab.org
<p>It was a poor design decision to include the s1 and s2 scintillators in the THaHRS spectrometer class. Including the VDC by default is fine, but the scintillators are not really required and not always installed. So, from version 1.6 on, they should be removed.</p>
<p>Also, we should probably create a THaBareHRS or THaHRSBase class without any predefined detectors. This would be useful for checkout of individual detector systems.</p>
<p>Target reconstruction should be moved from the THaVDC class into THaHRSBase. It operates on focal plane tracks regardless of how these tracks are found, so it is not a property of the VDCs, but definitely one of the spectrometer (per its physical construction). THaHRS would then inherit from THaHRSBase.</p>
<p>This issue is related to issue <a class="issue tracker-2 status-1 priority-2 priority-default" title="Feature: THaSpectrometer/THaTrack should be made abstract base classes (New)" href="https://redmine.jlab.org/issues/48">#48</a> - The THaHRSBase class should implement a MakeTrack method that produces tracks with HRS-style coordinates.</p> Hall A Analyzer - Feature #48 (New): THaSpectrometer/THaTrack should be made abstract base classeshttps://redmine.jlab.org/issues/482017-05-17T21:17:00ZOle Hansenole@jlab.org
<p>THaSpectrometer is currently limited to generating THaTrack objects. THaTracks, in turn, describe tracks in TRANSPORT style, appropriate for small-acceptance focusing spectrometers. Other spectrometer types are conceivable, for example 4pi detectors for which spherical coordinates are best suited, or SoLID with its cylindrical coordinate system. One might even want a different type of tracks for focusing spectrometers than THaTrack.</p>
<p>To support this, turn THaSpectrometer into a base class for various spectrometer classes that differ by the tracks that they generate. Similarly, THaTrack should become a base class for various types of tracks. Common among all tracks is that they represent physics 4-vectors at the vertex; everything else is specific to the spectrometer type.</p> Hall A Analyzer - Feature #47 (New): Let THaRun autodetect run segmentshttps://redmine.jlab.org/issues/472017-05-17T21:14:19ZOle Hansenole@jlab.org
<p>THaRun should automatically detect files that are split into segments with the usual CODA *.0, *.1 etc. naming convention. Such split runs should be presented as one large run, as far as that is possible.</p> Hall A Analyzer - Feature #46 (New): Reorganization of src and hana_decode directorieshttps://redmine.jlab.org/issues/462017-05-17T21:12:32ZOle Hansenole@jlab.org
<p>It would be nice if only the pieces of code (*.h and *.C) files that are actually needed for building the analyzer were located in these directories, so that wildcards could be used in the build files (either Makefiles or SConstruct/SConscripts). One could possibly move the pieces required for building standalone codes to another parallel directory, or to a and appropriate subdirectory.</p> Hall A Analyzer - Feature #45 (New): Consider t0 in matching clusters between lower and upper VDC...https://redmine.jlab.org/issues/452017-05-17T21:08:30ZOle Hansenole@jlab.org
<p>If using a 3-parameter cluster fit, the resulting time offset, t0, of each cluster needs to be used in the matching algorithm between the lower and the upper chambers.</p> Hall A Analyzer - Feature #44 (New): Support choosing VDC cluster fitter via configurationhttps://redmine.jlab.org/issues/442017-05-17T21:01:13ZOle Hansenole@jlab.org
<p>We will need to add an appropriate database key or keys. If we want to get fancy, we can allow plug-ins, as we do for the time-to-distance converter.</p> Hall A Analyzer - Feature #43 (New): Handle drift distance sign ambiguitieshttps://redmine.jlab.org/issues/432017-05-17T20:54:55ZOle Hansenole@jlab.org
<p>One complication with analyzing VDC clusters is the ambiguity of the sign of the drift distances derived from the drift times.</p>
<p>Without a time offset, only the smallest drift distance is ambiguous, but when allowing an offset, more combinations are possible.</p>
<p>One could look for the characteristic "V shape" of drift time vs. wire number to identify the wire with the smallest drift distance ("pivot wire"). With the pivot wire identified, we can proceed as before.</p>
<p>A large uncertainty in the drift times might require that more possibilities are considered, for example one of the wires immediately next to the apparent pivot wire might be the real pivot instead. Whether or not this additional analysis is necessary depends on the actual value of the time uncertainty. The code could check for it.</p> Hall A Analyzer - Feature #42 (New): Develop 3-parameter cluster fit algorithmhttps://redmine.jlab.org/issues/422017-05-17T20:46:48ZOle Hansenole@jlab.org
<p>We need a numerically stable 3-parameter cluster fit routine. It should fit the wire drift <em>times</em> vs. the corresponding wire positions. The drift times have a non-linear relationship to the drift distances, and we expect a linear relationship between wire positions and drift distances. The fit parameters are a common time offset to all drift times and the slope and intercept of the fitted straight line.</p> Hall A Analyzer - Feature #41 (New): Integrate VDC multihit analysis from APEX branchhttps://redmine.jlab.org/issues/412017-05-17T20:22:50ZOle Hansenole@jlab.org
<p>We developed a special analysis mode for the HRS VDCs in 2010 that correlates clusters in u and v by their timing. This mode is important for experiments operating with very high singles rates in the HRS, causing a significant accidental coincidence rate within the VDC drift time window - i.e. APEX.</p>
<p>This new algorithm should be integrated into the VDC code. However, it should only be enabled on demand via a configuration option since (a) it is slow and (b) it may reduce the tracking efficiency in the analysis of standard, low-rate experiments because of the presence of multiple in-time clusters coming from knock-ons, scraping etc.</p>
<p>To be clear: this new algorithm only filters out accidentally coincident tracks, but does little, if anything, to eliminate "multitracks" resulting from multiple in-time clusters (see item (b) above).</p> Hall A Analyzer - Feature #40 (In Progress): Replace THa prefix with namespaceshttps://redmine.jlab.org/issues/402017-05-17T20:20:16ZOle Hansenole@jlab.org
<p>The archaic THa prefix to class names should be replaced with appropriate namespaces like Podd and HallA. The old names may still be made available to legacy code via typedefs.</p> Hall A Analyzer - Feature #39 (New): Add timezone support to timestampshttps://redmine.jlab.org/issues/392017-05-17T20:19:03ZOle Hansenole@jlab.org
<p>All analysis objects should use a timezone-aware class like TTimeStamp instead of TDatime to indicate run dates etc. TDatime is not portable between time zones.</p> Hall A Analyzer - Feature #38 (New): Split libraries into core and hall partshttps://redmine.jlab.org/issues/382017-05-17T19:58:54ZOle Hansenole@jlab.org
<p>Shared libraries should be split into a core part with generally useful classes and hall A/C-specific libraries containing only hall code. The Hall C library will be managed in the hcana repository.</p>