Discussion of ds50daq code re-use¶
04-Jan-2013 discussion - Marc, Gennadiy, Steve, Jim, Ron, Kurt
Still working on these...
The slides that were used as a starting point for the discussion are attached to this page.
Synchronous control messages¶
There was a fair bit of discussion about the pros and cons of synchronous and asynchronous control commands (commands from Run Control to individual DAQ processes).
In a synchronous model, Run Control sends a command to a process and waits for the result to be returned (success or failure of the process to perform the requested action). In this case, RC does not send subsequent commands during the time that the first command is executing. This includes no "what state are you in" or "have you finished doing what I asked you to do" queries and no commands to abort execution of the original command.
In an asynchronous model, Run Control can query each process while it is doing the work for an earlier request, and it can send a request for the process to abort an operation.
[Please note that the choice of a synchronous model makes no restrictions on whether RC is communicating with multiple DAQ processes at the same time - it only addresses the communication between RC and a single DAQ process. (It is expected that RC can, and probably should, be talking to multiple DAQ processes at the same time.)]Some useful questions for an experiment that is considering using artdaq might be the following:
- Does the Run Control application need to get two replies from each process in response to each command? The two replies would be A) a simple acknowledgement that the command was received and B) a report on whether the command ultimately succeeded or failed.
- A follow-up question might be "what would Run Control do with a simple acknowledgement?" Is it really needed or is it just for a comfort display? RC will still have to wait for the final report on whether the command succeeded, and processes can send MessageFacility messages to report that commands have been received.
- Does the Run Control application need the ability to abort a requested operation while it is running, or is a timeout for each requested operation sufficient?
[The current plan is to provide a synchronous command model.]Some side-notes from this part of the discussion:
- The consensus was that DAQ processes should not expose internal state information. It is OK to report psuedo-state information that is based on the external commands that are supported, but actual internal states should not be reported.
- Run Control should be the application that knows (and controls) the overall system state. If some subset of the system needs to receive a given command before other parts of the system, it is Run Control's responsibility to handle that.
Conclusions¶I believe the following conclusions were reached:
- We will move the xmlrpc_commander, Commandable, *App, and EventBuilder classes into artdaq. We will update the FragmentGenerator interface in artdaq to take into account the methods that are needed to support the currently supported external commands. We will create a new interface to handle the function of fetching fragments from a FragmentGenerator and act upon the fragment (sending it to an eventbuilder process over MPI or writing it to disk or running art to perform some fragment-specific processing).
- We will move forward with the model of expecting synchronous commands from Run Control. The initial supported protocol will be XMLRPC.
- We will move forward with the idea that there is a set of external commands that is sufficient to meet the needs of all experiments.
- We will move forward with the idea that a single state model can be created to handle all experiments needs. Of course, this means that new use cases will need to be incorporate, and some experiments may not make use of some of the supported external commands.
Document the Supported external commands
important issue is the additional state that Gennadiy brought up of “connect” and “disconnect”. Is this just the “soft init” versus the “full init”?
important issue is the FragmentReciever and how it is used in the generic BoardReaderApp. We identified four types that might be present: MPI writer, file writer, sqlite writer, and analysis performer (from g-2 use case). We talked about pairing one of these “Receivers” to a “Generator” in the BoardReaderApp. This means that data from one channel cannot go to more than one “Receiver”. It also implies managing a list of (Receiver, Generator) pairs in the BoardReaderApp. The Receiver interface currently calls getNext() on the Generator, meaning that multiple destinations are not possible for the same data unless it is replicated in some obscure way. We have no broker between the Generator and the Receiver.
1) break artdaq into two chunks, data handling and specific transport (only if necessary to avoid the no MPI build)
2) move generic pieces from ds50daq into artdaq
Gennadiy asked what the schedule of work is to get this done.