VD-coldbox wires file

[brettviren]

We need a "wires file" for the VD coldbox being tested at CERN.

A diagram for what LArSoft supplies is here:

https://cdcvs.fnal.gov/redmine/attachments/65632/chanmap_offline_numbers_detector_strips.pdf

The wires file should exclude any of the "ghost" channels given in red in the diagram. Instead, these strips should be given as having segment number "1" (counting from 0) and be given the offline channel ID of the "real" channel to which it contributes via its jumpered segment=0 neighbor.

[wenqiang-gu]

@brettviren The proposal sounds good to me. By "ghost" channels, I assume you are talking about the jumpered wires that span the two half CRUs. While in Tom J.'s description, a "ghost" channel means an unused ASIC readout channel.

[brettviren]

Yes, it seems I misused the term "ghost". I'll stick to using it to mean "real but disconnected" channels.

I relate here what Tom clarified to us in email:

The red numbers below TPC 3U are labeling "channels" that do not exist at all. (These are what I misnamed "ghost"). Giving IDs to these nonexistent channels will produce a gap in the channel IDs that WCT will see. WCT will never see nor produce a channel number in [2592,2719], inclusive (and similar range from TDE).

Tom puts the "ghost" (real but disconnected ASIC readout channels) starting at 3456. I think there is no reason for WCT to ever want to input or output data on these channels. It seems Tom is hesitant to add them to RawDigit vectors so maybe nothing need be done. But, if they are to be put in RawDigit then we may need something changed in larwirecell so these "ghost" channels do not go into WCT-proper.

In any case, I think no channels in either of these two categories should be in the "wires file".

[nitish-nayak]

@brettviren @wenqiang-gu sounds good! I'll work on this

[brettviren]

Upstream updates from Tom,

https://cdcvs.fnal.gov/redmine/attachments/65665/vdcb_try2_offline_numbers_detector_strips.pdf

(note the disconnected channel numbers are now in purple.)

https://cdcvs.fnal.gov/redmine/attachments/65660/vdcoldbox1_try2_wiredump.txt

Also for easy reference here is the vd-coldbox channel docdb entry:

https://docs.dunescience.org/cgi-bin/private/ShowDocument?docid=23684

[nitish-nayak]

Hi @brettviren Do I have write access to this repo? I have the wires file but pushing it gives me

ERROR: Permission to WireCell/wire-cell-data.git denied to nitish-nayak.

Maybe I'm doing something stupid. My remote-url is

origin  [email protected]:WireCell/wire-cell-data.git 

[brettviren]

Hi @nitish-nayak You should have write access now. Your remote-url looks good.

[nitish-nayak]

Okay, I committed the wires file. There's somethings that I wanted to clarify but. So the Wires objects in the schema come with Tom's offline channel numbers + segment numbers for the jumpered wires like we discussed, and this is reflected in the file. But for the Planes objects in this, I see :

"planes": [                                          
      {                                                                     
        "Plane": {                                                  
          "ident": 0,                                                      
          "wires": [                                 
            0,                                                               
            1,                                                             
            2,                                                                 
            3,                                                        
            4,                                                           
            5,                                                               
            6,                                                               
            7,                                           
            8,       
            9,                                     
            10,                                                    
            11,                                          
            12,                                                             
            13,                                             

and these wire numbers aren't channel numbers but seem like an internal wct index corresponding to the lines read from a wire dump file, for eg here : https://github.com/WireCell/wire-cell-python/blob/master/wirecell/util/wires/dunevd.py#L55

In particular, the wire number here corresponding to say, offline channel 255 that is jumpered using two segments are 255 and 1855.

Am I interpreting this correctly? If so, is this an issue? Does the sigproc stage assume the wire numbers here inside "Planes" correspond exactly to channel numbers?

[brettviren]

Right, these are indices in to the array found in the Store.wires array. One element there is like:

bzcat dunevdcb1-3view-wires-v1.json.bz2 |jq '.Store.wires[0]'

{
  "Wire": {
    "ident": 0,
    "channel": 0,
    "segment": 0,
    "tail": 0,
    "head": 1
  }
}

This JSON file is like a little database so has a few indirections that are not very human-friendly.

For something slightly more human friendly, you can run:

wirecell-util plot-wires  dunevdcb1-3view-wires-v1.json.bz2 wires.pdf

To generate many pages of diagnostic plots. These plots may not make immediate sense but they display many of the salient features. Feel free to add yet more plots to that command if you feel like it. (just do so in a way that is general to all detectors). Or, if you come up with your own plots, even if they are detector specific, feel free to add them to a wire-cell-python command.

[nitish-nayak]

thank you! yeah, it makes sense now. So I think everything seems as expected then.