1 / 20

SVT Run Control Xin Wu

Pisa workshop, Jan. 24-25, 2000. 2. CDF Run Control Scheme . SmartSockets (SS). . . . SmartSockets API. . Messenger. Crate Tasks. . . JDBC Connections. Front-end process. . SmartSockets API. . Resource Manager. . . Resources Manager process. . . . . not yet implemented? necessary?. Pisa workshop, Jan. 24-25, 2000.

albert
Download Presentation

SVT Run Control Xin Wu

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    1. Pisa workshop, Jan. 24-25, 2000 1 SVT Run Control Xin Wu CDF Run Control framework 3 basic parts: Front-End Readout code: C code run on crate CPU Run Control packages: Java code run on DAQ computers Databases: hardware, run, trigger, calibration 3 basic independent processes: Front-end, Run Control, Resource Manager Messaging mechanism between processes SmartSockets Database access mechanism JDBC connections

    2. Pisa workshop, Jan. 24-25, 2000 2 CDF Run Control Scheme

    3. Pisa workshop, Jan. 24-25, 2000 3 Partitions Partition is used to identify a Run Control process for the purpose of detector hardware resource allocation in general a RC process requires a Trigger Supervisor and there are 8 TS available, only 8 partitions can be active at the same time predefined partitions (1-8) stored in Hardware Database software partition is possible when TS is not needed Resource Manager server manages allocation of partitions Static methods are provided for interacting with the server via SS, eg. ResMgr.getAllPartitions: view status of all partitions ResMgr.requestPartition: request a partition ResMgr.requestPartition: close a partition Once a partition is granted, the user name and process ID is registered in the Hardware Database It was proposed that SVT crates should NOT be split in different partitions

    4. Pisa workshop, Jan. 24-25, 2000 4 Resources Resource refers to a detector component primary resources: crates (eg, /frontEnd/svt/tracking/00, /frontEnd/svt/fitter/00) composite resources (components): a set of crates or components (eg, /frontEnd/svt) A primary resource can only be booked (owned) by one partition A partition can only book free primary resources in a composite resource so SVT will be a special case? Resource Manager server manages allocation of resources Static methods are provided for interacting with the server via SS, eg. ResMgr.bookResource: book a resource ResMgr.releaseResource: release a resource ResMgr.getBookedResouces: view booked resources

    5. Pisa workshop, Jan. 24-25, 2000 5 Readout Configuration and Readout List Readout configuration specifies the clients managed by a state manager readoutConfig: stores a list of clients (mostly crates) can be filled by partition configuration files (eg partition<#>.cfg) or by RunConfiguration for specific run type readoutConfig: centrally handles acknowledgments from clients is an AckListener known to the state manager messenger Readout list specifies the readout parameters of a client (crate) When a stateManager performs a cold/warm start, readout lists are send to its clients by the messenger a readout list can come from database or a file the subject of the ss message is /partition-<#>/readoutlist/<cratename> the message type can be general or crate type specific: ReadoutList_MessageType, DiracReadoutList_ MessageType the message body is a ReadoutList object packed by daqmsg

    6. Pisa workshop, Jan. 24-25, 2000 6 Front-End Code 3 pieces of C code implementation code: local run control: FER_imp.c board level tasks: ADMEM_imp.c, TDC_imp.c, ... crate level tasks: QIECALIB_imp.c, COTCALIB_imp.c, ... messenger interface code: interface between local run control and actual messaging mechanism: FER_mess.c messenger implementation code: Smartsockets implementation: FER_smart.c All three pieces are compiled as one library and loaded into crate CPU memory upon crate startup

    7. Pisa workshop, Jan. 24-25, 2000 7 Front-End Messaging Upon startup of a crate, the messenger task, FER_messagener(), is spawn set state into IDLE, partition number into -1 set up local message queues (msgQ) for error, warning, message, ... setup Smartsockets messaging by calling FER_smartInitMS() set server name (b0dau30) and project name (CDF_DAQ) connect to server setup subject callbacks for some subjects /setPartiton/<nodename>, /*/command/<nodename>, /*/readoutlist/<nodename>, ... setup default subject callback go into an infinite loop to process incoming messages send out monitoring, warning and error messages

    8. Pisa workshop, Jan. 24-25, 2000 8 Front-end Process

    9. Pisa workshop, Jan. 24-25, 2000 9 CDF Run Control process User interface is rcGUI has several stateManager’s DaqGUI, QIECalibGUI, ... each with its own transition model Only one stateManager can be active at a time has access to static methods of ResMgr that communicate with the Resource Manager server via SS With rcGUI, one can (de)activate a stateManager select a partition and book resources for an active stateManager control an active stateManager

    10. Pisa workshop, Jan. 24-25, 2000 10 QIECalibGUI and COTClibGUI

    11. Pisa workshop, Jan. 24-25, 2000 11 State Managers A state manager manages state transitions for a Run Control process different types of run have different state managers: DAQ: daqStateManager calibrations: COTCalibStateManager, QIECalibStateManager tests: COTTestStateManager common features provided by abstract classes: StateManagerGUI extends stateManager; abstract public void DrawGUI(); stateManager extends FiniteStateMachine; abstract public void setupStateAndTransitions(); a specific state manager should implement methods setupStateAndTransitions(): specifies state transition model DrawGUI() : draws state transition model on the GUI transitions are handled by method doTransition(Transition T) in the class FiniteStateMachine

    12. Pisa workshop, Jan. 24-25, 2000 12 State Manager Messenger a state manager communicates with its clients via its messenger each stateManager has its own messenger a messenger knows the current partition number: from current RunConfiguration clients list: from current readoutConfig a messenger: provides interface to SmartSockets use publish-subscribe messaging, project: CDF_DAQ uses daqmsg package to pack messages keeps a list of processes that listen to acknowledgments (AckListener) provides a method sendTransitionMessage() for sending commands subject (destination) of transition message within a partition /partition-<partition number>/command/<destination> runs a thread to receive acknowledgments using SS Callback and distribute them to all AckListener’s

    13. Pisa workshop, Jan. 24-25, 2000 13 daqmsg A package providing utilities to simplify messaging DaqMsg: an abstract class using Java reflection to pack and unpack DAQ messages (numbers, strings, objects, structures, ...) in SmartSockets specification provides methods to pack DaqMsg to TipcMsg (ss message) and unpack TipcMsq to DaqMsg creates SS message type (structure, grammar) according to the message message type number: using predefined integer values DaqMsgBase.java, FerMessages.java

    14. Pisa workshop, Jan. 24-25, 2000 14 Run Configuration Run Configuration specifies general run time parameters runNumber, creationTime, processId, userName, partitionId, runSET, ... runSet: stores run parameters for a specific run type, default sets stored in run database runType, nEvents, tsMode, l2Mode, crateSets, ...,

    15. Pisa workshop, Jan. 24-25, 2000 15 High Level Questions Can SVT crates be split in different partitions? No. (P1) Robin or Smartsockets? Smartsockets everywhere. (P3) Do we need a SVT Control middle man? Maybe not. (P2) Do we need to have remote control of SVT during the run? Where to run SVTSPY? Workstation or crate CPU Default on workstation (P5) Can we agree that all crate CPU tasks written in C? Is SVTSPY an independent process? How to pass its results? ...

    16. Pisa workshop, Jan. 24-25, 2000 16 Do we need a SVT Control middle man? Pros: was thought necessary to run SVT without DAQ independent SVT system level tasks (eg. SVTSPY, error handling) possible SVT expert intervention on SVT itself possible to use the same process for debugging parallel development of software with Run control do what we want for implementation state manager, GUI, remote access, SS vs. Robin no need for local run control on crate CPU Cons: SVT is an exception of the CDF DAQ system, danger to be isolated potential confusion: who starts SVT Control? probably need to directly access databases need more software development effort, duplication ...

    17. Pisa workshop, Jan. 24-25, 2000 17 Implications with and without SVT Control Implications with a SVT Control SVT Control is one of the clients of Run Control Only SVT Control can book SVT crates from hardware database SVT Control can access trigger database for maps Run Control does not know the detail configuration of SVT Implication without a SVT Control SVT crates are clients of Run Control some SVT system functions need to be inserted into Run Control SVT message types, database access, tables downloading, table version checking, ... more logical to run SVTSPY on crate CPU’s

    18. Pisa workshop, Jan. 24-25, 2000 18 SVT Front-end code board specific front-end code independent of SVT control or not provided by board experts need local run control in case of no SVT Control template from standard crate 3 implementations: svt_tracking, svt_merger, svt_fitter messenger implementation in case of no SVT Control stand one should be modified for SVT messenger implementation in case of a SVT Control can write our own large maps and tables downloading? version checking mechanism? monitoring and error handling code?

    19. Pisa workshop, Jan. 24-25, 2000 19 SVT front-end implementation What actions should be taken by boards and SVT system upon state transition command? cold_start, warm_start, activate, end, abort, pause, resume, halt, recover, run, shutdown, download reaction to other messages setPartition, readoutList, ... How to implement down-loading only one set of table?

    20. Pisa workshop, Jan. 24-25, 2000 20 Practical Issues How to divide up software writing? eg. in case of no SVT Control: Individual board implementations (C code) local run control + local messenger (C code) insertion of SVT functions into Run Control (Java) Are Run Control framework stable enough to start writing SVT code? Who are interested in writing code? How to proceed?

    21. Pisa workshop, Jan. 24-25, 2000 21 Agenda on run control discussion Morning: brief summary of current CDF Run Control framework Xin present an initial list of issues concerning run control Xin brief discussion of the list All present an initial list of database related questions Xin discussion on the database All presentation of CDF Run Control framework Frank Afternoon discussion on the run control All

More Related