[Halld-offline] changes to the TAGM channel numbering scheme

[Richard Jones]

Hello Mark, Dave, and all

I originally called the tagger fixed hodoscope subsystem TAGF back a few
weeks when I started implementing the tagger reconstruction. I see that you
have started using this, as you have been integrating these DTAGFHit types
into your danaevio plugin. But more recently I discovered that Fernando has
been using TAGH as a designation for this subsystem. His nomenclature goes
back further than mine, and is included in documentation that is being
tracked for the project. Since this is a convention rather than a matter of
fact, I think it will be simpler to avoid this ambiguity and switch
everything in the offline software over to the name TAGH and "hodoscope"
rather than TAGF and "fixed array".

M / F in TAGM / TAGF means "movable" vs "fixed"
M / H in TAGM / TAGH means "microscope" vs "hodoscope"

This change has already been made in my working copy of sim-recon branch,
and I will start checking it in shortly. I am also reconfiguring the tables
in ccdb to support the code in the new hits factories, and will follow this
new convention in those as well.

-Richard J.


On Sun, Aug 3, 2014 at 10:07 PM, Richard Jones <richard.t.jones at uconn.edu>
wrote:

> Hello David,
>
> Sounds good.
>
> -Richard J.
>
>
> On Sun, Aug 3, 2014 at 8:30 PM, David Lawrence <davidl at jlab.org> wrote:
>
>> Hi Richard,
>>
>>   Alex S. is the person officially responsible for that particular page
>> so you can coordinate with him.
>>
>> It looks from the TT that only half of the last fADC250 is populated so
>> in principle, there may be
>> another 8 channels available. The current TT actually just lists those as
>> “SPARE”. I guess there is a
>> tagger meeting tomorrow. Perhaps you could discuss it there and let me
>> know the outcome. I’ll
>> hold off updating the SQLite file until I hear what the final plan is.
>>
>> Regards,
>> -David
>>
>> On Aug 3, 2014, at 3:39 PM, Richard Jones <richard.t.jones at uconn.edu>
>> wrote:
>>
>> David,
>>
>> I am not sure who came up with those numbers, certainly not anyone in our
>> group. What matters is that the total number of cables, splitters,
>> discriminators, tdc and adc spiggots, etc is no less than 120. Beyond that,
>> it is just a matter of changing the maps as you say. Sounds like it is a
>> simple process.
>>
>> The fiber bundles have 30 fibers each, so we will actually deliver 102
>> columns, and have 102 sum channels delivering signals to the backplane.
>> Originally I thought we would just leave those outputs disconnected, but if
>> we have 122 readout channels available, we can use them.
>>
>> -Richard J.
>>
>>
>> On Sun, Aug 3, 2014 at 3:28 PM, David Lawrence <davidl at jlab.org> wrote:
>>
>>>
>>> Hi Richard,
>>>
>>>   Thanks. This explanation makes it clear and is consistent with what is
>>> in the XML
>>> you committed to the CCDB. I’ll go ahead and make the necessary changes
>>> to the
>>> SQLite file. I also need to make changes to fix some issues with the FDC
>>> so once I’ve
>>> got those in, I’ll regenerate the tt.xml file from the SQLite and make a
>>> new entry into the
>>> CCDB which hopefully will have all known issues fixed.
>>>
>>>   It looks like we do need to update the document I mentioned though. It
>>> currently
>>> states the number of scintillators is “102x5” and the readout channels
>>> are “97 (column
>>> sums)  + 5 individual columns  |  122” .
>>>
>>> Regards,
>>> -David
>>>
>>>
>>> On Aug 3, 2014, at 3:15 PM, Richard Jones <richard.t.jones at uconn.edu>
>>> wrote:
>>>
>>> Hello David,
>>>
>>> You are close. The array contains 100 columns of 5 fibers each. They are
>>> numbered column 1..100 and row 1..5. A few of the fibers are read out
>>> individually, and those channels are numbered by their row, column address.
>>> These are columns 7, 25, 79, and 97. Because of the way the backplanes are
>>> populated, only a few of the columns are instrumented for individual
>>> channel readout, every 18'th column starting with 7.  I decided to connect
>>> the first two and the last two of these 6 to the available 20 readout
>>> channels, so hence the 7, 25, 79, and 97.
>>>
>>> All of the columns, including 7, 25, 43, 61, 79, and 97 are instrumented
>>> with sum circuits for reading out the column sum. We need all of these,
>>> including the ones that are ALSO individually read out, because there is
>>> more flexible control over the gain on the sum circuits than there is for
>>> the individuals. Only the sum signals will actually be used to make tags to
>>> be used in the offline; the individual channels are only there to monitor
>>> the vertical electron distribution and to allow us to tune the quadruple
>>> field for optimal tagging efficiency. To make the nomenclature clear, we
>>> designate the individual channels by non-zero row numbers, and the sums we
>>> distinguish using row=0.
>>>
>>> In summary, we have row=0, column=1..100, and then row=1..5,
>>> column=7,25,79,97
>>>
>>> Does that help?
>>>
>>> -Richard Jones
>>>
>>>
>>> On Sun, Aug 3, 2014 at 1:21 PM, David Lawrence <davidl at jlab.org> wrote:
>>>
>>>> Hi Richard,
>>>>
>>>>   I’m looking at changes you committed to the the Translation Table for
>>>> the TAGM channels and
>>>> some things don’t seem quite right. This may be due to out of date
>>>> knowledge of the geometry
>>>> on my part so let me first describe how I *thought* the geometry is
>>>> supposed to be for the tagger
>>>> microscope:
>>>>
>>>> - Scintillating fibers are arranged in columns with 5 fibers each.
>>>> - Most of the columns have the 5 fibers summed into a single DAQ
>>>> channel.
>>>> - Every 20th column has a separate DAQ channel for each of the 5 fibers.
>>>>
>>>> This seems mostly consistent with what is described in the summary
>>>> document:
>>>>
>>>> http://argus.phys.uregina.ca/gluex/DocDB/0023/002376/008/halld_summary.pdf
>>>>
>>>> The exception is that the document indicates 97 summed columns instead
>>>> of the 95 we had in
>>>> the original TT.
>>>>
>>>> What I see in the XML you committed is:
>>>>
>>>> - columns 7, 25, 79, and 97  have 6 rows (I would have thought they
>>>> should have 5 rows and be evenly distributed)
>>>> - column numbers start at “1” while row numbers start at “0”
>>>>
>>>> Please confirm that the values in the CCDB are really correct and I
>>>> will go ahead and
>>>> update the SQLite file. Also, if these are correct, we’ll need to
>>>> update the
>>>> controlled document D00000-00-00-S006.
>>>>
>>>> Regards,
>>>> -David
>>>>
>>>>
>>>> On Aug 1, 2014, at 6:45 PM, Richard Jones <richard.t.jones at uconn.edu>
>>>> wrote:
>>>>
>>>> Hello Mark and all,
>>>>
>>>> As we finalize the assembly of the tagger microscope, we need to update
>>>> the translation tables with the identifiers of the channels that are
>>>> actually being connected to the DAQ inputs. After speaking with David, I
>>>> checked out the latest copy of the tt_xml translation table from ccdb, made
>>>> the appropriate changes, and checked it back in with a brief comment. To do
>>>> that, I fetched a copy of the add_custom_data.py script found in the
>>>> TranslationTable package, and ran it from the machine ifarm1101. This seems
>>>> to have worked. However... words on the wiki suggests that I have been
>>>> naughty -- note the exclamation point below.
>>>>
>>>>  [quoted from
>>>> https://halldweb1.jlab.org/wiki/index.php/Translation_Table]
>>>> *It is important to emphasize that the above mentioned SQLite file
>>>> should be maintained as the definitive source of TT information, even for
>>>> the offline software. If a change needs to be made, it should be made to
>>>> that file and then regenerate the tt.xml file from that. Don't just modify
>>>> a tt.xml file downloaded from the CCDB and reinsert it!*
>>>>
>>>> Modifying the mysql db is one thing; checking changes into a project
>>>> with a name like "/trunk/controls/epics/..." sounds like it is a bit above
>>>> my pay grade. Should I really be fiddling with that?  Maybe one of you
>>>> could manage the updating of the definitive copy from the one I just
>>>> checked into ccdb? Should we have a policy regarding this? I can imagine
>>>> that detector channel -> DAQ input maps might change frequently during the
>>>> initial period, as we try to get things set up and working properly.
>>>>
>>>> -Richard Jones
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.jlab.org/pipermail/halld-offline/attachments/20140804/52bea5d0/attachment-0001.html