[Halld-online] DAQ config

[Shepherd, Matthew]

And, of course, experts are immune from making such mistakes!

Matt

> On Dec 6, 2017, at 10:46 AM, Alexander Somov <somov at jlab.org> wrote:
> 
> 
> I will change file permission of production config files to 'hdsys',
> i.e., only experts will be able to edit them.
> 
> Any changes in the config files have to be checked by experts before
> taking data.
> 
> Cheers,
>       Alex
> 
> 
> 
> On Wed, 6 Dec 2017, Shepherd, Matthew 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
>> 
>>