Feature #49
openFeature #76: Code reorganization
THaHRS algorithm reorganization
Description
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.
Also, we should probably create a THaBareHRS or THaHRSBase class without any predefined detectors. This would be useful for checkout of individual detector systems.
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.
This issue is related to issue #48 - The THaHRSBase class should implement a MakeTrack method that produces tracks with HRS-style coordinates.
Related issues
Updated by Ole Hansen almost 7 years ago
- Related to Feature #48: THaSpectrometer/THaTrack should be made abstract base classes added
Updated by Ole Hansen almost 7 years ago
- Subject changed from THaHRS reorganization to THaHRS algorithms reorganization
- Start date deleted (
12/17/2013) - Estimated time set to 24.00 h
Updated by Ole Hansen almost 7 years ago
- Subject changed from THaHRS algorithms reorganization to THaHRS algorithm reorganization
Updated by Ole Hansen almost 7 years ago
- Estimated time changed from 24.00 h to 16.00 h
Updated by Ole Hansen almost 7 years ago
Implemented backward compatibility for the set of detectors in THaHRS. If no detector named "vdc" is found at Init time, define the set of old detectors (quietly avoiding duplicates). (Perhaps I should also check that this "vdc" is a THaVDC?)
This can be turned off by calling AutoStandardDetectors(false) before Init.
Also, a bugfix of sorts. If AddDetector discovers that a detector is already defined, it deletes the object passed to the call. The rationale here is that the detector object was given to the apparatus with the assumption that it will be managed by the apparatus. If the apparatus rejects it because it is already there, it should clean it up since it will never be used. This allows calls like
AddDetector( new THaMyDetector("existing_name") );
to run cleanly without memory leaks. Of course, if the user keeps a reference to the object in the caller, it would become a dangling pointer if the AddDetector calls does not succeed. But this can be detected by checking the return value. It is a bit risky - some people might have written
THaScintillator* s2m = new THaScintillator("s2m");
LHRS->AddDetector(s2m);
s2m->SetSomething(123);
But "s2m" already existing in such cases would be extremely unusual.
Perhaps we should throw an exception in such cases? After all, if a detector cannot be inserted, the analysis might not work as the user intended, and so the problem needs attention, not just be a warning. I'll leave that for later.
All this is in commit 3cf18e970826f87af064d96eb07547ef65b92fbc
Updated by Ole Hansen almost 7 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 10