[Halld-online] DAQ config

[Curtis Meyer]

I do not believe that we will arrive at a solution for the December 2017 Run, but I concur with Matt that this appears to be an area where unknown changes could creep into our data taking. Clearly, we can see this after the fact, but given the very fundamental nature of the control files to the quality of our physics data, we should be discussing ways to better guarantee that things are consistent.

Curtis
---------
Curtis A. Meyer MCS Associate Dean for Research
Phone:    (412) 268-2745 Professor of Physics
Cell:        (412) 260-6290 Carnegie Mellon University
Fax:         (412) 681-0648 Pittsburgh, PA 15213
cmeyer at cmu.edu<mailto:cmeyer at cmu.edu> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.curtismeyer.com_&d=DwIFAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=eBpArVoZXbImRjIxkcDVau4kHkRpv5-4OWoB11AiqTc&m=IaJscmxnd4lC6xRZxKwz629mFfVAV_vf5aQRMjjF0Lc&s=Bf7jvz_j2-VadEW5PG-eeVtOOJRQljrKVW-M4hWSVnA&e= 

On Dec 6, 2017, at 9:45 AM, Shepherd, Matthew <mashephe at indiana.edu<mailto:mashephe at indiana.edu>> wrote:


There was some discussion today at the run meeting about handling potential errors in configuring the DAQ.

I wanted to follow up on this to explain what I was trying to say....

My understanding is that DAQ config files, while well-preserved with production run data, are potentially editable by anyone that has access.  This means that it is possible for undesirable changes to creep in through (e.g., a short production test, debugging, etc.. ) any event that results in editing of the file and the author forgetting to roll back all the changes.

The only way to avoid this is to ensure that the DAQ is initialized from some specific version of a "write only" master source, e.g., database or svn would work.

Let's say you maintain the various DAQ files for subsystems in svn, then you could have a single database constant that fully specifies the version of the DAQ.  Call this constant DAQ_config, it maps system to version, e.g.:

DAQ_config  (version 1)
BCAL --> 6
FDC --> 13
CDC --> 2
...

The startup process then begins by saying that for a given run, we are going to use version 1 of DAQ_config.  This then results in pulling (from svn) the BCAL config file revision 6, FDC revision 13, CDC revision 2, ..... and then starting up the system.

If you want a different configuration of the DAQ, then write a new version of this constant with different version numbers in the fields.

Then, no matter what, if you take data with the same version of DAQ_config, there is absolutely no way to get a different configuration of the DAQ.  And, as a bonus, when comparing runs taken by two different version of DAQ_config, you can easily see which subsystems have potentially changed configuration.

(This is arguably better done without svn and having the configurations for the subsystems be their own database tables, but it sounds like svn is already in use and would work.)

Again, my concern is *not* that we don't know what the configuration of the DAQ is, it is that we have the potential to make undesirable inadvertent changes.  We may not realize we've changed something until well after the data are acquired.  In that case, the existing tracking of configuration will, as has been demonstrated, help us figure out where we screwed up, but won't fix the fact that we didn't configure the DAQ the way we wanted to.

Perhaps I'm misunderstanding something or practically implementing the scheme above is challenging, but configuring the DAQ for precious production running for the experiment using (many!) freely editable text files seems .....

Matt

---------------------------------------------------------------------
Matthew Shepherd, Professor
Department of Physics, Indiana University, Swain West 117
727 East Third Street, Bloomington, IN 47405

Office Phone:  +1 812 856 5808

_______________________________________________
Halld-online mailing list
Halld-online at jlab.org<mailto:Halld-online at jlab.org>
https://mailman.jlab.org/mailman/listinfo/halld-online

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-online/attachments/20171206/a5faf62f/attachment.html>