Review and update CRP channel ranges and groups

[dladams]

We should review and update the dataprep channel ranges and groups for the CRP coldbox tests and upcoming protDUNE run.

These are used to specify which channels are processed in dataprep and to specify the range of channels and labels for dataprep channel metric plots and event displays.

[vgalymov]

For the coldbox I think one might want to revisit the channel groups used in the CNR. In particular if there is any coherent noise pattern specific to FEMBs.
Then for the protodune the channel view channel ranges / groups used for the coldbox CRP should be applicable to the four CRPs. I would propose the following naming conventions:
CRPB1 (Bottom CRP closest to the cryostat wall of the beam pipe in hardware people call it CRP4)
CRPB2 (Bottom CRP2, hardware CRP5)
CRPT1 (Top CRP closest to the cryostat wall above CRPB1, aka CRP3 in the hardware vernacular)
CRPT2 (Top CRP above CRPB2, hardware CRP2).
Within each CRP group there will be the sub-groups for induction and collection channels. If we stick with the above naming conventions these can then be designated as CRPB1U, (U plane of bottom CRP 1), CRPB1V (V plane of bottom CRP 1),
CRPB1Z (Z plane of bottom CRP 1), etc.
Then we have the following channel ranges that will be on interest:

  		First Ch	Last Ch
CRPB1		0	3071
	CRPB1U	0	951
	CRPB1V	952	1903
	CRPB1Z	1904	3071
CRPB2		3072	6143
	CRPB2U	3072	4023
	CRPB2V	4024	4975
	CRPB2Z	4976	6143
CRPT1		6144	9215
	CRPT1U	6144	7095
	CRPT1V	7096	8047
	CRPT1Z	8048	9215
CRPT2		9216	12287
	CRPT2U	9216	10167
	CRPT2V	10168	11119
	CRPT2Z	11120	12287

For CNR one might want to have some default configuration where channels in readout plane are grouped in some way such that we subdivide the ranges based on how much the strip length (relevant for induction U/V) varies. Though for the weighted CNR perhaps this is not critical.

[dladams]

There is a channel range tool for each detector that maps names to channel ranges and to labels. For the vertical-drift detectors, the class that defines these tools is
CrpChannelRanges.
If you run the unit test for this class, you will see the current names and labels:

...
test_CrpChannelRanges: -----------------------------
test_CrpChannelRanges: Fetching tool pdvd2022.
CrpChannelRanges::ctor:      LogLevel: 1
CrpChannelRanges::ctor:      Detector: pdvd2022
test_CrpChannelRanges: checkChannelRanges: -----------------------------
test_CrpChannelRanges: checkChannelRanges: Check detector.
crdet: [0, 12288) CRDET
crb: [0, 6144) CRB
crt: [6144, 12288) CRT
crbA: [0, 3072) CRB-A
crbB: [3072, 6144) CRB-B
crtA: [6144, 9216) CRT-A
crtB: [9216, 12288) CRT-B
crbAu: [0, 952) CRB-AU
crbAv: [952, 1904) CRB-AV
crbAz: [1904, 3072) CRB-AZ
crbBu: [3072, 4024) CRB-BU
crbBv: [4024, 4976) CRB-BV
crbBz: [4976, 6144) CRB-BZ
crtAu: [6144, 7096) CRT-AU
crtAv: [7096, 8048) CRT-AV
crtAz: [8048, 9216) CRT-AZ
crtBu: [9216, 10168) CRT-BU
crtBv: [10168, 11120) CRT-BV
crtBz: [11120, 12288) CRT-BZ
...

The first column is the name for each range, the second is the channel range the last is the label that appears in plots.

The names can be used to specify

• which channels to process in dataprep modules,
• which to include in metric vs. channel plots and event displays and
• the grouping for CNR

The tool has the name channelRanges and other tools, services and modules and be written to be configured with channel range names in a similar way.

The labels are available to such tools and are used to create titles and label for plots. It is possible to add alternative labels and the easy to have fcl config so that either or both labels appear in plots.

You will see I have used A and B instead of your 1 and 2 for the two parts of the detector.
Comments in the code indicate we might use 00, 01,0 2, ... for the far detector but this is not yet implemented.
There is an option to configure for the coldbox instead of protoDUNE and there the label C is used.

We can

• change the above names and labels to match your suggestions
• keep the names and labels and add extra labels so users can choose between names with fcl (%LABEL2% instead of %LABEL1%)
• stay with the naming we have now

Naturally, I prefer the latter because I like those names and the distinction they provide with coldbox and FD (a plot labeled CRT-Cz is coldbox, CRT-AZ is protoDUNE and CRT-04Z is far detector).
And the tool code and existing fcl configurations would not require modification.

[vgalymov]

And the tool code and existing fcl configurations would not require modification.
Agreed. To me the existing ch range names used by the tool are also perfectly fine.

[dladams]

As for the CNR, we will presumably want to introduce ranges for each FEMB view, e.g. names like fmtA04v or fmt104v (for top, volume A or 1, 4th FEMB, v orientation). If I count right, there are 2x12x3 = 72 of these.

[vgalymov]

For top part, FEMB is an abstraction. The underlying top readout boards read only 64 channels and the physical strip fanout to the readout channels vie the adapter boards is different from the bottom ones I think. But for what concerns the offline channel numbering one could probably live with the same ranges as for the bottom.

[dladams]

You are right. We don't have FEMBs on top. I should have said fmbA04V or just fmA04v. We probably want a differnt name for the top. What is it? And yes, the mapping will be different.

[vgalymov]

I will have to go back and look up the details of the mapping. If my memory is correct, some AMC/analog-frontend may read only a couple of induction channels, so it made sense to group them with other cards. However, there were some discontinuities in coherent noise pattern between adapter boards so it made sense for top to group on the adapter boards. I called these ranges "ada" (for adapter board) plus some number for CRP and view, but this is purely a name, so if "ada" becomes "fm" it is not an issue. Also it turns out that each adapter board looks at 128 CRP channels, so channel wise this is equivalent to FEMBs.

[dladams]

Here are the CNR ranges we use for the top:

# group channels by adapter board for CNR filter
data.crpcb_tde_adau: ["ADA4_U:0:62",       "ADA5_U:62:126",      "ADA6_U:126:190",    "ADA7_U:190:254",
                      "ADA8_U:254:318",    "ADA9_U:318:380",     "ADA10_U:380:412",   "ADA11_U:412:444",
                      "ADA12_U:444:476",   "ADA24_U:476:508",    "ADA23_U:508:540",   "ADA22_U:540:572",
                      "ADA21_U:572:634",   "ADA20_U:634:698",    "ADA19_U:698:762",   "ADA18_U:762:826",
                      "ADA17_U:826:890",   "ADA16_U:890:952"]

data.crpcb_tde_adav: ["ADA1_V:952:984",    "ADA2_V:984:1016",   "ADA3_V:1016:1048",
                      "ADA4_V:1048:1110",  "ADA5_V:1110:1174",  "ADA6_V:1174:1238",
                      "ADA7_V:1238:1302",  "ADA8_V:1302:1366",  "ADA9_V:1366:1428",
                      "ADA21_V:1428:1490", "ADA20_V:1490:1554", "ADA19_V:1554:1618",
                      "ADA18_V:1618:1682", "ADA17_V:1682:1746", "ADA16_V:1746:1808",
                      "ADA15_V:1808:1840", "ADA14_V:1840:1872", "ADA13_V:1872:1904"]

data.crpcb_tde_adaz: ["ADA3_Z:1904:2004",  "ADA2_Z:2004:2100",  "ADA1_Z:2100:2196",
                      "ADA10_Z:2196:2296", "ADA11_Z:2296:2392", "ADA12_Z:2392:2488",
                      "ADA24_Z:2488:2584", "ADA23_Z:2584:2680", "ADA22_Z:2680:2780",
                      "ADA13_Z:2780:2876", "ADA14_Z:2876:2972", "ADA15_Z:2972:3072"]

from vdcb2_tools.fcl.

Note the alternative here of specifying explicit ranges instead of mapping names to ranges using the channelRanges tool.

Do these ada ranges remain valid for protoDUNE?

I propose names fmbA04v for the bottom and adaA06v for top.

[vgalymov]

Yes, the adapter board are the same, so they should be valid. One needs to add the offsets for crtA and crtB.
So equivalent to "ADA4_U:0:62"

"ADA4_U:0:62" -> 6144:6206 for crtA
"ADA4_U:0:62" -> 9216:9278 for crtB

This would double the arrays, so it would better to map them to names within the tool I think. I had generated them with some script. I will look for it and can add the offsets and make appropriate lists for each crtA and crtB.

[vgalymov]

Or better yet make a cpp function that does it?

[dladams]

Agreed. We should move these CRP2,3, i.e. top readout, definitions into the channel range tool. We also need the same for the bottom readout as noted in #DUNE/dunesw/issues/61. I will work on both of these with higher priority for the second which is needed for coldbox reco.

[dladams]

The protDUNE-VD CRP geometry and readout is describe in @vgalymov's April 21 talk. There I see this figure for the bottom readout:

The channel and TPC numbering in the figure is for CRP4. For CRP5, the channel numbers are offset by 3072 and TPC numbers by 4. The figure shows there 24 FEMBs used to read out a CRP4. What convention should we use to number these: 0-23, 1-24, ...? Which is first?

The decoder tools return data indexed by offline channel number and we know the view mapping (U: 0-951, V; U: 952-1903, Z:1904-3071. Where can I find the mapping from offline channel number to FEMB number?

[dladams]

Here is response from Tom:

The ProtoDUNE-HD channel map service (and decoder!) ended up
being functional for the ProtoDUNE-VD coldbox BDE CRPs.  At some point we may want to rename it since it is more
broadly useful than ProtoDUNE-HD.
 
duneprototypes/Coldbox/vd/fcl/runvdcoldboxdecodercrp45.fcl
duneprototypes/Protodune/hd/RawDecoding/runpdhdtpcdecodermodule.fcl
 
The service is called PD2HDChannelMapService
 
and the columns in the input file are
 
    linestream 
      >> chanInfo.offlchan 
      >> chanInfo.crate 
      >> chanInfo.APAName
      >> chanInfo.wib 
      >> [chanInfo.link](http://chaninfo.link/) 
      >> chanInfo.femb_on_link 
      >> chanInfo.cebchan 
      >> chanInfo.plane 
      >> chanInfo.chan_in_plane 
      >> chanInfo.femb 
      >> chanInfo.asic 
      >> chanInfo.asicchan
      >> chanInfo.wibframechan; 
 
from
 
duneprototypes/Protodune/hd/ChannelMap/PD2HDChannelMapSP.cxx
 
The older VD coldbox had different information (adapter boards) from Nitish's spreadsheets, so I had made
a different map service.  But the new CRP4 and 5 maps look like ProtoDUNE-HD ones.
 
Tom

Scanning https://github.com/DUNE/duneprototypes/blob/develop/duneprototypes/Coldbox/vd/ChannelMap/vdcbce_chanmap_v4.txt by hand, I see the 4th to last column does indeed have values
running from 1-24 and so looks like FEMB indices.

I see that file is installed at $DUNEPROTOTYPES_DIR/config_data/vdcbce_chanmap_v4.txt and will use that location to get the channel-to-FEMB ID mapping.

[dladams]

For CRPs after CRP1, channel ranges are in CrpChannelRanges. The configuration parameter Detector is used as follows:

• cb2022: Coldbox texts with the PDVD geometry, i.e. CPR2, CRP3, CRP4 and CRP5
• pdvd: ProtoDUNE VD using those same CRPs

Channel groups are in CrpChannelGroups. Right now, there are no groups beyond the ranges obtained from tool instance channelRanges but we want to add electronics groups appropriate for noise removal. The plan is to make this generic by adding a parameter holding an array of strings with and entry for each CRP. The strings have format COFF:DRO:LAB where COFF is a channel offset, DRO is the detector readout type (pdfemb or pdada) and LAB is a label (fmbA, ..., adaA, ...). For DRO=pdfemb, we will use FEMB views with FEMB ID obtained from a FEMB ID tool which is a configuration of the TextIndexMapTool described in dunecore issue 59.

[dladams]

A tool configuration to return the FEMB number (1-16) for a relative offline channel (0-3071) for the vertical-drift bottom readout is provided as crpChannelFemb in vdcb2_tools.fcl. It is based on the coldbox channel map test file vdcbe_chanmap_v4.txt and it is easy to change that file or to create tools for other properties such as asic, wib, etc.

A test of the configuration is provided at test_tool_crpChannelFemb.cxx and is run in unit testing. There is also an equivalent test script test_tool_crpChannelFemb that can be run directly from the command line and is not included in unit testing.

Changes are pushed.

[dladams]

I am able to test and fix compilation of the new code by checking out a tag of this package before Jake's changes.

However there are problems running tests because the new tool (TextIndexMapTool) is not present. I try checking out an earlier version of dunecore:

[dladams@jupyter-dladams dunecore]$ git checkout 811df1bd64496799887c152c5b1a6cbf330bfe03
Note: switching to '811df1bd64496799887c152c5b1a6cbf330bfe03'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c 

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 811df1bd minor update

[dladams]

I am able to test and fix compilation of the new code by checking out a tag of this package before Jake's changes.

However there are problems running tests because the new tool (TextIndexMapTool) is not present. I try checking out an earlier version of dunecore:

[dladams@jupyter-dladams dunecore]$ git checkout 811df1bd64496799887c152c5b1a6cbf330bfe03
Note: switching to '811df1bd64496799887c152c5b1a6cbf330bfe03'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c 

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 811df1bd minor update

[dladams]

Last comment was a very old one just posted. Release v09_75_00d00 came out and I moved there and moved to develop for all and am now able to build.

[dladams]

I modified vdcb2_tools.fcl to drop use of the data block. I put everything in the tmp block and erase that at the end of the file.

This was pushed 06jun2023.

[dladams]

I have changed the names in CrpChannelRanges to be fembXXX instead of fmbXXX to be consistent with ProroDUNE-SP.

[dladams]

I am assigning new detector names for VD coldbox. Instead of vdcb2 for CRP2 - CRP5, I introduce four names: cbcrp2, cbcrp3, cbcrp4 and cpcrp5.

• I added channel range and groups for each of these in dunedataprep/DataPrep/fcl
• I added cbcrp[2:5]_tools_dune.fcl to dunesw/fcl/protodune/common
• In those files, we define tools channelRanges and channelGroups with LogLevel=0
• I fixed some logging without checking LogLevel in both tools

Thus:

duneproc> pdChannelRange -d cbcrp5 fembC02v
fembC02v: [1840, 1872) FEMBC02V

[dladams]

I am modifying CrpChannelRanges to return the detector name from fcl as the first label for range name "all" or "crdet". This way the the CrpGroupTool can check that it holds a consistent range tool and know which detector is being described.

I added CrpChannelHelper that can be included in the range and group tool to hold shared code describing the detectors and interpreting the detector name.

[dladams]

There are now CRP FEMB channel groups (i.e. including all 2 or 3 FEMB-views) for coldbox (cb2022:fembs) and ProtoDUNE-VD (pdvd).