Change ADC resolution to 14 bits

[emanuele-villa]

The new default for the FD DAQ is 14 (since quite some time), 12 bits should be dropped everywhere apart from pdsp (there I think it was still 12).

PR #129 features the configuration of a fcl hook to change the resolution when running, but @jrklein and I believe it would be better to have it set to 14 the most upstream we can, and set to 12 only for pdsp or other detectors that need that.

I know that 14 is the standard for all FD modules and prototypes, while I'm not aware of what NDs do. Is there anybody to ask for ICEBERG? I don't see other NDs in DUNEWireCell/.

I can take care of it once the course of action is defined. I see the different zipped files in the folder, for that I need a hint (are they generated in some specific way?).

@HaiwangYu @brettviren

[brettviren]

@emanuele-villa thank you for spear-heading this.

Your understanding matches mine (including uncertainty about ICEBERG) and I think it is reasonable for DUNE to default to 14bit and to specialize the minority of detectors to use12bit.

As for implementing the change, here is some context (maybe you know it already) and then I give some suggestions.

• WCT's https://github.com/WireCell/wire-cell-toolkit/tree/master/cfg/pgrapher/common provides truly global defaults. This tree in WCT proper should NOT be changed for this 14bit issue.
• There is a family of detector-specific configs in https://github.com/WireCell/wire-cell-toolkit/tree/master/cfg/pgrapher/experiment
• Some detectors have forked this area and so the detectors you see there may be incomplete or what is there may not be definitive. I have lost touch with how this forking has gone in DUNE-land and understanding that would be step 1, I think.

What I suggest is that you and @HaiwangYu work together to make a "holistic DUNE WCT config repo" that lives in the DUNE GitHub org. The goal would be to make this the sole, definitive source for all WCT config for DUNE detectors. One stop shopping. I think this would help DUNE and it would certainly help me from the viewpoint of developing WCT.

This repo may start by simply copying all of cfg/*.jsonnet and cfg/pgrapher/ from WCT and merging back any "loose" DUNE cfgs that my be floating around. This copy is then free to remove the non-DUNE experiment/* files and to modify the common/* files at will.

OTOH, starting from total scratch is actually a reasonable option especially if you are dissatisfied with the organization of the current pgrapher/ tree (I know I am and I wrote a lot of it!).

There are other detector commonalities and differences that may be worth including in this grand refactoring:

• electronics response functions (usually in-config)
• field response functions (separate files named in the config)
• noise spectra (files)
• wires / strips (files dumped from larsoft)

I don't mean to make the job harder so all these are just suggestions... 😄

[HaiwangYu]

Hi @emanuele-villa @brettviren
I think Brett's idea changing the base resolution configuration for DUNE is a good idea. I believe we actually have that here:
https://github.com/DUNE/dunereco/blob/develop/dunereco/DUNEWireCell/common/params.jsonnet#L110

The steps to make sure this works would be:

• make sure this number is used by DUNE
• make sure there are no other conflicts in WIRECELL_PATH for DUNE

[emanuele-villa]

Hello, thanks for the replies. To check if I understand @brettviren 's proposal: are you saying to get rid of all dune configs in https://github.com/WireCell/wire-cell-toolkit/tree/master/cfg/pgrapher/experiment and leave them only in dunereco? I would be in favor of this, it's quite unclear where one should look to know what is being used when running.

I don't see wirecelle being imported as submodule or other way of linking dunereco/dunereco/DUNEWireCell to WireCell, that would be another reason to remove all duplicate configurations and code. Maybe I'd add a short README to say where all dune configs can be found. However, I am not a member of wirecell, so I can't push anything there. If necessary, I can fork it and somebody can push through the fork.

About how to reorganize DUNEWireCell, my proposal would be to have a config tree like the following (this includes some renaming, since we're at it):

• common (interfaced to wirecell_dune.fcl?)
• • dune-fd
• • • dune-fd-hd
• • • • dune-fd-hd-1x2x6
• • • • dune-fd-hd-1x2x2
• • • dune-fd-vd
• • • • dune-fd-vd-1x6x6
• • • • dune-fd-vd-1x8x14
• • protodune
• • • protodune-sp
• • • protodune-hd
• • • protodune-vd
• • • protodune-vd-coldbox
• • iceberg

More: are fhicl/ and ui/ needed?

[absolution1]

Hi everyone.

Setting up a new default sounds like a good idea.
However, for any configuration stored at the dune repo-level (e.g. dunereco), I think we should store the parameters in a fcl file that holds all of the DAQ-related values. The wirecell cfgs could then pick up the values from fcl. My reasoning is that we would keep all of the parameters in a single place and in a format that all of the collaboration are familiar with.
We already have this setup for a few of the simulation-level parameters e.g. lifetime and diffusion so this should already be a path well-trodden.

[emanuele-villa]

Alright, in that case I guess that all wirecell configs should look first if a parameter is set in fcl, right?

I read a bit of the code and I don't understand how the connection happens between fcl and jsonnet. I see the parameter structs.resolution in some fcls, but how does jsonnet use that instead of what is in params.jsonnet?

[brettviren]

Yes, values that are needed in both Jsonnet and FCL are indeed best to be defined in FCL and then passed to Jsonnet.

Any attribute of the params FCL table that is given in the FCL config for the WireCellToolkit art module can be retrieved in Jsonnet with a call to std.extVar().

All other values that are only consumed in Jsonnet (no references in FCL) are best defined in Jsonnet, imo. I mean, I would not define stuff in FCL just for the sake of having it in FCL.

Also, with sufficient data structure factoring, it is possible to cover all the different DUNE detectors with largely the same Jsonnet code. Ie, one need not make largely duplicate sub-directories for each detector.

There is some work toward this end. For example, there exists a detectors.jsonnet that maps a canonical detector name to its set of data/config files (responses, wire geometry, etc). This kind of pattern allows the config author to focus on enumerating the types of jobs in a detector-independent way and avoid the O(Ndets x Njobs) complexity like we currently have in the main cfg/pgrapher/ area. The cfg/layers/ area is my attempt to follow this pattern across ALL experiments/detectors but it is not yet production ready. But, we could still use it as guidance in making a more streamlined config for all of DUNE.

In the short term, copy-paste-modify is of course easier/faster. But if there is interest in implementing a more factored/abstracted form, I'd be very in to it.

[emanuele-villa]

Thanks for the explanation, I agree that only parameters that need modifying shall go through fcl. For them, do you agree that in all jsonnets they should be using extVar instead of having values?

So, I found detectors.jsonnet. It seems to me that this is not used in DUNEWireCell, also because there are many more detectors here in dunereco than in wire-cell-toolkit.

Since having the code in two places and also duplicates of almost identical configurations is not maintainable, the course of action I propose:

• Get rid of all dune configurations in wire-cell-toolkit and add a README saying they are in DUNE reco
• Organize dunereco/dunereco/DUNEWireCell with the structure I proposed above or something similar, more factorized and hierarchical
• Have under common/:
  • the base fcl configuration valid for all dune detectors (with resolution: 14) and params.jsonnet reading elecGain and resolution from fcl with extVar
  • the base jsonnet files with some standards for the different variables
• In each subfolder, hierarchically:
  • detector-specific fcl configuration: include the general one in common/ and override the necessary variables for that specific detector.
  • jsonnet configurations importing the base version from common/ and overwriting only what needs it. For example, I see all detectors have sp-filters.jsonnet and there are only one or few parameters that differ.
• change wirecell_dune.fcl (currently 2000 lines) to include all the fcls in the subfolders. In this way it's much easier to modify a specific configuration, and users will still only have to import this one fcl to have all configs available.

Let me know your thoughts on this.

Related note: I was starting to develop in a branch here, but it would be nice if the changes of https://github.com/HaiwangYu/dunereco/tree/hydra2501 (PR #129 ) can be merged before I start shuffling things around, or annoying conflicts could rise.

[absolution1]

Hi.
It's possible that we're already in agreement but I just want to make sure we're on the same page.

I agree with the sentiment that 'I would not define stuff in FCL just for the sake of having it in FCL' but I don't think we are ever in that situation.
I think there's a few reasons to add these parameters to fcl:

• As far as I'm aware, a fcl dump would not dump the jsonnet contents so dumping the job fcl would not reveal what ADC or other DAQ params are being used in the sim.
• Most DUNE collaborators are not familiar with the inner workings of the simulation and do not know to look in the jsonnet files to find this information. More of them do know to look in fcl files.
• These parameters might need to be changed again. This issue was raised out of the need to update the ADC value. Also, there was recently a question recently about changing the gain. Having these parameters in a single fcl means its easier for other collaborators to study variations.
• We do still have a 1D sim workflow (outside of wirecell) that some people are making use of. Syncing the DAQ parameters between the main wirecell workflow and the 1D workflow through a central fcl config makes sure equivalent inputs are being used.
• It's also possible that others might want to access these params in a downstream LArSoft analyser. The way all larsoft analysers are taught to read in params is through fcl.

So I do think it would be best if there was a complete DAQ param config defined through fcl thats read from jsonnet

All of the other restructuring suggestions sound great.

[emanuele-villa]

I think this is a valid point, it's true that it's convenient to have all parameters in fcl as for all the other parts of the simulation/reconstruction, to always have the full picture of the configuration.

However, I believe this would mean having a lot of parameters in a fcl (or collection of fcls), and have all jsonnets pick them up with extVar, meaning a lot of lines to change (and an effort to keep naming consistent between the two config formats). It's also true that this would be a one-time thing and maintaining it should not be too bad...

I am undoubtedly the least expert here, so I'd leave the decision to yous.

[absolution1]

How many tunable DAQ parameters are there in DUNE wirecell? more a question for @brettviren

If its a handful then its probably doable at the same time as the re-organisation and ADC updates. If its looking to be a bigger job then its probably best to factorise out: handle the reorganisation and parameter updates first, with the fcl parsing coming later. FWIW I am very happy to help out with the fcl organisation bit.

[brettviren]

How many tunable DAQ parameters are there in DUNE wirecell?

@absolution1 step one certainly includes making some list. Maybe a couple dozen? And then some "meta" parameters are needed parameterize iterations over AnodePlanes (APA/CRP).