gistfile1.txt

First, I start with a reminder of the raw data structure and amp level data structure. (I won't include the Muon Modules…).  TCA = TClonesArray


KRawEvent
            -- TCA of KRawBolometerRecords
                        - detector name, mass, etc..
                        - TRefArray links to KRawBoloPulseRecords
                        - TRef link to KRawSambaRecord


            -- TCA of KRawBoloPulseRecords
                        - channel specific configuration details (gains, bolobox number, other bolo information, channel name, etc…)
                        - raw pulse trace
                        - Samba/DAQ pulse characteristics estimations: amp, baseline, baseline noise, , rise-time (***)
                        - TRef link to KRawBolometerRecord


            -- TCA of KRawSambaRecords
                        - trigger bit map 1/2
                        - delay, stream mode, data source, buffer length
                        - file number, regen flag, event time, etc.. 
                        - some samba run info (like dead time.. not sure how that is calculated. i've never looked), temperature




Now, when a KAmpEvent is created, notice what happens with the samba data (*** flagged above). In this example, I'll explicitly show two KPulseAnslysisRecords.


KAmpEvent
            -- TCA of KAmpBolometerRecords (essentially the same as the Raw record)
                        --base class info
                        --TRefArray links to KAmpBoloPulseRecords
                        -- TRef link to KRawSambaRecord


            -- TCA of KAmpBoloPulseRecords
                        - channel specific configuration details (gains, bolobox number, other bolo information, channel name, etc…)
                        - TRef link to KAmpBolometerRecord
                        - TRefArray link to KPulseAnalysisRecords


            -- TCA of KRawSambaRecords !!!***!!!  -- NOTE - KRawSambaRecords are stored in the Amp file. I chose this instead of making a new class.




            -- TCA of KPulseAnalysisRecords
                        - amp, start time, chi**2, etc… pulse characteristics.
                        - name


                _here are 6 potential elements in this array_ for a particular pulse channel...
                        [0]
                                    name: "samba"
                                                The pulse characteristic information in the KRawBoloPulseRecord supplied by Samba is stored here. 
                                   
                        [1]
                                    name: "KChamonixKAmpSite"        
                                                The analysis results from this kampsite are stored here.
           
                        [2] 
                                    name: "JulesANA"
                                                hypothetical results from a port of Jules's code/data into the Amp-level data file
                       
                        [3] 
                                    name: "ERA"
                                                hypothetical…


                        [4] 
                                    name: "KFeldbergKAmpSite_1"
                                                from Unrau's code with a particular set of filter parameters


                        [5]
                                    name: KFeldbergKAmpSite_2
                                                from Unrau, but with a different set of filter parameters...


The Samba analysis data gets moved to a pulse analysis record. So, Samba provides two things - DAQ status and Pulse Analysis information. 
In the raw file, the pulse analysis information from samba is stored in the raw bolo pulse record. 
But that information then gets stored in a KPulseAnalysis record. (( digression:  Note that name 
given in the KPulseAnalysisRecords MUST be unique. However, this is NOT enforced anywhere in the code…. yet.
Maybe I should add that somewhere. The reason is that you have to uniquely identify the different analysis algorithms. 
that should probably go in the AddPulseAnalysisRecord method, requiring the user to give a name ))




The samba pulse analysis record is "on par" with any other type of pulse analysis. 
The HLA level file will contain the calibration results for different amplitude estimators.  
And potentially, it can contain multiple calibration estimates for each amplitude estimator! 
(Is this too complicated of a data structure…??… Maybe we should stick to just one calibration 
estimator and agree that we use the best method for calibration… although, I think the following 
structure would still support multiple calibration estimators so long as the 'names' are unique. )


So, we have two things now in the HLA - pulse energy estimates and bolometer event energy 
estimates (recoil and ionization), plus bolometer event categorizations - fiducial, surface, other...


Include the particular instances as I did above to show where the data lives, we need the structure to look like this:


KHLAEvent
            -- TCA of KHLABolometerRecords (essentially the same as the Raw record)
                        -- base class info
                        -- TRefArray links to KHLABoloPulseRecords
                        -- TRef link to KRawSambaRecord
                        -- TRefArray links to KBolometerAnalysisRecords


            -- TCA of KHLABoloPulseRecords
                        - channel specific configuration details (gains, bolobox number, other bolo information, channel name, etc…)
                        - TRef link to KHLABolometerRecord
                        - TRefArray link to KPulseAnalysisRecords
                       
            -- TCA of KRawSambaRecords !!!***!!!  -- NOTE - KRawSambaRecords are stored in the HLA file. I chose this instead of making a new class.




            -- TCA of KPulseAnalysisRecords
                        - energy, start time, chi**2, etc… pulse characteristics.
                        - name
                        [0]
                                    "samba"
                        [1]  
                                    "KChamonixKAmpSite"
                        [2] 
                                    "JulesANA"
                        [3]
                                    "ERA"
                        ...etc...




            -- TCA of KBolometerAnalysisRecords
                        - recoil energy, Q value, ion energy, event category, etc...
                        - name
                        [0]
                                    "samba"
                        [1] 
                                    "KChamonixKAmpSite"
                        [2]
                                    "JulesANA"
                        [3]
                                    "ERA"
                        [4]
                                    "KFeldbergKAmpsite_1"
                        ... etc... 
 
 
So, you can see that the samba pulse analysis record should be handled just like any other pulse analysis record. 
Its up to the routine that converts the amp level data into the (calibrated) HLA data to select to use the "samba" pulse analysis records. 
The samba KPulseAnalysisRecord should not automatically be recreated whenever you add a bolopulse record to the HLA event. 
The AmpLevel method does create a new KPulseAnalysisRecord for the samba analysis data stored in the RawBoloPulse record.  
So, just remove this code here. (Additionally, your code assumes that first pulse analysis record for each channel is 
always the 'samba' analysis record. Try not to make these kinds of assumptions.) 
 
 One should, in principle, be able to create an HLA event with no pulse analysis records. 
This can't be done with the Amp level because I don't throw away the 'samba' analysis result. 
But, one could create an Amp level file with only the 'samba' analysis records.
 
I understand the confusion. In fact, if I could rewrite the data structure again, I would. 
Its not quite as logically tight as I wish it would be. But.. c'est la vie...
 
What we want, I think, is a calibration tool that takes each event, and can calculate the energy for each pulse and the 
bolometer event energies for any subset of KPulseAnalysisRecord "name"s. That is, we should be able to tell the tool to 
produce an HLA file for just the "samba" records, or for just the "ERA", or for each of the "samba", "JulesANA", and 
"KChamonixKAmpSite" analysis.  And then have a special keyword "all" where it reads the first event and finds all of the 
unique KPulseAnalysisRecord names and produces the HLA data file using each of the analysis records.