The Go4 Analysis Framework
Introduction V4.4

The Go4 (GSI Object Oriented On-line-Offline) Analysis Framework has been developed at GSI. It is based on the ROOT system of CERN. Therefore all functionality of ROOT can be used.

2.1.1 Go4 tasks with all communications

Go4 has two parts: the analysis framework itself and a Qt based GUI. Both can be used independently, or together. The separation of the analysis and GUI in two tasks is especially useful for on-line monitoring. The analysis runs asynchronously to the GUI which is (almost) never blocked. The same analysis can be run in batch/interactive mode or in remote GUI controlled mode. The GUI can be used stand alone as ROOT file browser and as histogram viewer for GSI standard histogram servers like MBS. Moreover, the analysis task can be run either as a client bound to one GUI (default), or can be started as an analysis server with the possibility to connect several GUIs (one controller and arbitrary number of observers with restricted commands).

gui150

2.1.2 Go4 analysis steps

The Go4 framework handles event structures, event processing, and event IO. The analysis event loop is organized in steps: Text Box:
gui147 Each step has an input event, an output event, and an event processor. The output event calls the event processor to be filled. The event processor has also access to the input event. In the current design the analysis is data driven. A first event object (input1) is filled from some event source (input). An output event object (output1) is filled by an event processor object (process1) which has access to both, input1 and output1. Optionally the output event may be written to a file (file1). In the next step the input event object (input2) can be either the output event object (output1) from the previous step or retrieved from the file. The second output event object (output2) is filled by the second event processor object (process2) and can be optionally written to a second file.

The information needed to create the event and processor objects (which are deleted when the event loop terminates) is stored in step factories which are kept in the analysis.

The processor and output event classes have to be provided by the user. The input classes for standard GSI event sources are provided by Go4 (see chapter 3, page 10). Analysis and step factory classes are provided by Go4 or can be implemented by the user as subclasses.

gui148

For normal operation, the Go4 analysis steps are designed to run subsequently. But in addition, each analysis step has access to the output events of all other previous analysis steps, so it would be possible to let analysis steps logically run “in parallel”, all starting with the output event of the first step, and all delivering their results to the last step that may collect and combine them.

gui149

2.1.3 Other analysis functions

Outside the analysis steps the user functions UserPreLoop(), UserPostLoop(), and UserEventFunc() located in the user analysis class are executed as shown in the figure. In principle, they could be used to implement the full analysis without using the step mechanism. But for setting up a new analysis the use of steps is strongly recommended, because steps can be controlled by the GUI and offer event and IO management.

In the event loop, after processing the steps and UserEventFunc() the Go4 dynamic list processor is executed. This processor can be dynamically configured from the GUI to check conditions and/or fill histograms.

gui146

3 Go4 Analysis

The Go4 concept consists of base classes (interfaces) for event structures, algorithms, and IO, which can be implemented by user subclasses or by framework plug-ins (general service classes) delivered with Go4. Class descriptions and reference guides are available on the Go4 Website http://go4.gsi.de.

3.1 Event base classes

The interface classes provided by Go4 (a detailed description is in the reference manual) are normally not seen by the user. Starting with the examples (see chapter 4, page 20) one can better study derived working classes.

TGo4EventElement: Defines the event structure and methods to clear this structure. Input and output event structures of each step of the analysis are instantiated once at initialization. In the event loop event first cleared (via Clear() method call) and than filled by the source class, where BuildEvent function is defined.

TGo4EventSource: The source of the event data. This can be e.g. a file of a certain format, or a socket connection to an event server. The event source class has a BuildEvent(TGo4EventElement*) method, which fills event structures. In addition, CheckEventClass(TClass*) method can be implemented to check event class during initialization. The class constructor should open (connect) the source; the destructor should close (disconnect) it properly.

TGo4EventStore: An object responsible for storing the event data. This can be e.g. a local file of a certain format, but may as well be a connection to some storage device. The virtual method Store(TGo4EventElement*) is used to store the pointed event object. The class constructor should open the storage; the destructor should close it properly.

TGo4EventProcessor: An object that contains the algorithm to convert an input event object into an output event object (both of class TGo4EventElement). This is a subclass of TGo4EventSource, since it delivers the filling of the output event from the input event. The event processor implementation has to “know” the input and output event classes. Actual code of converting the data (i.e. actually performing the analysis) should be implemented in BuildEvent method.

TGo4EventFactory: Defines the actual implementations of all the above. Go4 uses a factory design pattern to create all event class objects at initialization. The virtual methods:

CreateInputEvent(), CreateOutputEvent(), CreateEventSource(TGo4EventSourceParameter*), CreateEventStore(TGo4EventStoreParameter*), CreateEventProcessor(TGo4EventProcessorParameter*) have to be defined in the user factory. They create the respective objects and return the pointer to it. The default factory provides methods
DefEventSource(classname), DefEventProcessor(objectname, classname), DefInputEvent(objectname, classname) and DefOutputEvent(objectname,classname).

Simple examples of a running Go4 analysis can be found on directories $GO4SYS/Go4ExampleSimple, $GO4SYS/Go4Example1Step, and $GO4SYS/Go4Example2Step.

3.2 Event classes, interface to MBS

Go4 offers predefined implementations of the event base classes, including an interface to the GSI data acquisition Multi Branch System MBS, the GSI list-mode files, and ROOT files.

TGo4EventElement (base class):

TGo4MbsEvent MBS event format 10-1

TGo4MbsSubEvent MBS subevent format 10-1

TGo4CompositeEvent Base class for all composite event structures

TGo4ClonesElement Clonesarray container for composite event

TGo4EventSource (base class):

TGo4MbsFile (read from *.lmd list-mode file with format 10,1)

TGo4MbsEventServer (connect to MBS event server)

TGo4MbsStream (connect to MBS stream server)

TGo4MbsTransport (connect to MBS transport server)

TGo4RevServ (connect to remote event server)

TGo4FileSource (read from *.root file from Go4 tree, i.e. one file containing one TTree per analysis step)

TGo4EventStore (base class):

TGo4FileStore (write to *.root file with Go4 tree, this file can be used as TGo4FileSource later)

TGo4BackStore Use TTree existing only in memory to view and analyze event structures.

These classes can be used directly to write simple analysis.

3.2.1 A simple event loop

Using these implementations, getting MBS event data into ROOT (without Go4 framework) could look like this:

#include "Go4EventServer/Go4EventServer.h"

#include "Go4Event/TGo4EventEndException.h"

int main() {

TGo4EventSource* input = new TGo4MbsFile("file.lmd"); // MBS list-mode file

// TGo4EventSource* input= new TGo4MbsTransport("node"); // MBS transport server

// TGo4EventSource* input= new TGo4MbsStream("node"); // MBS stream server

// TGo4EventSource* input= new TGo4MbsEventServer("node"); // MBS event server

// TGo4EventSource* input= new TGo4RevServ("node"); // Remote event server

TGo4EventStore* output = new TGo4FileStore("output",1,5); // split level, compression

TGo4MbsEvent* event = new TGo4MbsEvent();

event->SetEventSource(input);

event->Init();

Int_t eof = 0, numEvents = 0;

while(eof==0) {

try{

event->Fill(); // read event

numEvents++; // eof throws exception

output->Store(event); // write to file

}

catch(TGo4EventEndException& ex) { eof=1; } // mark end of file

catch(...) { cout << "Error" << endl; eof=2; } // any other error

}

cout << "EOF after " << numEvents << " events" << endl;

}

The events in the ROOT file can be retrieved by program, but not in tree viewers. For the use of tree viewers, a new output event object should be filled and stored.

3.3 Analysis step classes

As mentioned above a Go4 analysis is organized in steps. The information needed to instantiate a step is kept in the step factory.

TGo4EventServerFactory (base class): (contains factory methods that already know the above implementations. User step factories must inherit from this class!)

TGo4StepFactory This TGo4EventServerFactory can be used in most cases as user factory to set up the analysis steps (example 1Step).

TGo4AnalysisStep objects of this class hold the definition of an analysis step.

Each analysis step has at least an input event object, an output event object and an event processor object. Additionally, it can have an event source (e.g. TGo4FileSource) and an event store (TGo4FileStore) instance. An analysis step is set up by a TGo4EventServerFactory subclass, i.e. TGo4StepFactory or a user defined subclass.

3.4 Object management

3.4.1 Go4 objects

Text Box:

gui151 Objects used in Go4 are organized in ROOT folders. The folder structure is sent to the GUI. Objects must be registered in the analysis to be seen in the GUI browser. Registered objects can be located in the processors. The top folders as seen in the GUI are shown on the left side. The methods to register/locate objects are (pointer to the appropriate object, optional subfolder as string, name including subfolder as string):

· AddHistogram(pointer,subfolder), GetHistogram(name)

· AddAnalysisCondition(pointer,subfolder), GetAnalysisCondition(name)

· AddParameter(pointer,subfolder), GetParameter(name)

· AddPicture(pointer,subfolder), GetPicture(name)

These methods are available in TGo4Analysis and TGo4EventProcessor subclasses. Objects created in a TGo4Analysis subclass can be located in all event processors. Objects created in event processors can be located in all subsequent event processors (steps).

Registered objects are stored/retrieved to/from the auto-save file, if enabled. Retrieval is done after creation of the analysis singleton before the creation of the steps. When an object retrieved from the auto-save file is created in a processor the retrieved object is replaced (stored data lost). When an object is created in the analysis singleton it will be replaced by the one retrieved from the auto-save file except histograms which are not retrieved in this case. This means that histograms created in the analysis singleton are always empty after startup.

3.4.2 Go4 parameters

Parameters used in the analysis are implemented by the user in classes derived from TGo4Parameter. Such objects are registered to the framework and can be edited by a generic parameter editor (see chapter 5.11.2, page 64). Parameter objects can be created in the user analysis or the event processor class. Parameter objects are loaded from an optional auto-save file after instantiation of the analysis and before instantiation of the processor objects. When created in the analysis the values set in the constructor are therefore overwritten by auto-save. To use the GUI editor, the UpdateFrom() method must be implemented to update the local (active) parameter object from the modified one delivered by the editor. In this method it is up to the user to ignore certain members or to execute whatever he wants. E.g. one could use parameters to execute commands. Parameters in the auto-save file can be edited. In the editor they can be saved/retrieved to/from files. Several mechanisms can be implemented to handle the parameter member values. The main question is how restricted the methods of modification should be.

Modify values only in the class constructor, then recompile. To prohibit changes by editor, the UpdateFrom() method could be just a no-op to avoid undocumented changes. The parameter object should be created and registered in the processor constructor (after possible auto-save restore). Pro: the parameter values are always strictly defined as coded. Con: the parameter values cannot be changed easily.
Modify values by editor, use auto-save to store. Create parameter object in analysis constructor. Auto-save must be enabled. Pro: parameter can modified by editor (UpdateFrom() method must be implemented) and changes will be restored from auto-save. Con: when the auto-save file must be deleted for some reasons. the latest values are lost.
Use a macro to set values. This macro must be executed in the processor constructor (after auto-save restore). UpdateFrom() could just execute the macro to avoid undocumented changes. Pro: values are kept in a text file and can be modified without recompile. Con: parameter cannot be changed by GUI editor.
Best combination: one can use macro saveparam.C([file],wildcard,prefix) from $GO4SYS/macros creating macros (one per parameter) to set all parameters to their current values,. The names are built from prefix and parameter name. The macro can be executed in CINT (then the parameters are taken from a file), or in the GUI or in the analysis. The parameter is created in the analysis. Values are set from macro in processor constructor. By this method parameter values can be edited by GUI, or macro can be edited. Last version will be used independently of auto-save.
Example:
root[0].x saveparam.C("myfile.root","*","setpar")
would produce macros setpar_par1.C, setpar_par2.C etc. The macros have no arguments,
e.g. setpar_par1().

3.4.3 Go4 conditions

Conditions are objects holding window limits or polygons. One or two values can be checked against the limits or the polygon, respectively. In addition the conditions have test and true counters. They can be set to return always true or false or return the inverted test result. They can be edited by the GUI (see chapter 5.8.2, page 57). They can be used to steer the analysis flow. They are saved/retrieved to/from the auto-save file, if enabled. They can be edited in the auto-save file. In the editor they can be saved/retrieved to/from files. If a mechanism like for the parameters (4) is wanted, one can use macro savecond.C([file],wildcard,prefix) from $GO4SYS/macros creating macros (one per condition) to set all conditions to their current values,. The names are built from prefix and condition name. The macro can be executed in CINT (then the conditions are taken from a file), or in the GUI or in the analysis.

Example:

root[0].x savecond.C("myfile.root","*","setcon")

would produce macros setcon_cond1.C, setcon_cond2.C etc. The macros have three arguments: restore flags, restore counters, reset counters (0=no, 1=yes), e.g. setcon_cond1(1,0,1).

3.5 Analysis base class TGo4Analysis

Once the user has defined his/her event class implementations, the analysis steps can be created and registered to the Go4 analysis framework. The actual framework consists of the TGo4Analysis class, which is a singleton (i.e. there is only one framework object in each process). This class provides all methods the user needs, it keeps and organizes the objects (histograms,...), it initializes and saves the data objects.

The user analysis is set up in a subclass of TGo4Analysis, i.e. TUserAnalysis. Constructor and destructor of this user class, in addition with the overridden virtual methods UserEventFunc(), UserPreLoop(), and UserPostLoop() specify the user analysis. If these functions are not needed, one can also use the TGo4Analysis class directly, as shown in the example Simple.

All analysis steps must be created with initial event parameters (input and output filenames) and auto-save settings. Additionally, some user objects may be created and registered here. Note that histograms created and registered here are saved to but not updated from the Go4 auto-save file. Persistent histograms of the analysis should be created in the UserPreLoop function. Existing conditions and parameters, however, are updated when the auto-save file is loaded. In the constructor of the TUserAnalysis class the analysis step objects are created, each containing instances of its user step factory. The analysis steps are registered at the TGo4Analysis framework, input and output events of subsequent steps are checked for matching. Furthermore, other objects like histograms, conditions or parameters can be created in the constructor and registered, so the framework is responsible for their persistence. Such objects can also be created in the step processors.

In addition to the event processors, the UserEventFunc() allows the user to specify analysis operations that are called once in each analysis cycle, e.g. filling certain histograms from the output events of all analysis steps. The UserEventFunc() makes it even possible to call an external analysis framework event by event without using the Go4 Analysis Steps at all, thus taking advantage of the Go4 object management and remote GUI features.

The UserPreLoop() and UserPostLoop() functions may define actions that are executed before starting, or after stopping the main analysis loop, respectively.

Once the user analysis class is defined, there are two modes of operation: The single-threaded batch mode, and the multi-threaded client mode that connects to the Go4 GUI.

3.5.1 User subclass of TGo4Analysis

Up to Go4 version 4.3 the user subclass of TGo4Analysis has been instantiated in the user main program MainUserAnalysis. In this case the arguments of the constructor could be chosen arbitrarily. With Go4 version v4.4 a standard main program (see next section) can replace the MainUserAnalysis. When using this main program the constructor of a TGo4Analysis derived user class is called with a standard argument list as it is used with main programs. The constructor of a user analysis must therefore be:

TUserAnalysis::TUserAnalysis(int argc, char** argv) : TGo4Analysis(argc, argv)

{

cout << "User analysis " << argv[0] << "created" << endl;

...

}

Note that argc is always > 0 and argv[0] is always the analysis name when called from standard main program.

Example

The user analysis could create one analysis step with input from an MBS file with the following code fragments (note that we use the standard Go4 step factory class and a fixed file name):

TUserAnalysis::TUserAnalysis(int argc, char** argv) : TGo4Analysis(argc, argv)

{

const char* userinput = “data.lmd”;

TGo4StepFactory* factory = new TGo4StepFactory("Factory");

// the objects specified here will be created by the framework later:

factory->DefEventProcessor("Proc","TUserProc");// object name, class name

factory->DefOutputEvent("Event","TUserEvent"); // object name, class name

TGo4MbsFileParameter* input = new TGo4MbsFileParameter(userinput);

TGo4AnalysisStep* step = new TGo4AnalysisStep("Analysis",factory,input,0,0);

step->SetSourceEnabled(kTRUE);

step->SetProcessEnabled(kTRUE);

AddAnalysisStep(step);

}

// Example of using the event loop functions for a trivial counting of events
// fEvents must be defined in TUserAnalysis.h:

Int_t TUserAnalysis::UserPreLoop() {

fEvents=0;

return 0;

}

Int_t TUserAnalysis::UserEventFunc() {

fEvents++;

return 0;

}

Int_t TUserAnalysis::UserPostLoop() {

cout << " Total events: " << fEvents << endl;

return 0;

}

3.6 Main analysis program

3.6.1 The go4analysis main program

Contrary to previous Go4 versions, it is no longer required to provide a user main analysis program (typically called MainUserAnalysis). Instead, the standard go4analysis program instantiates and runs user code compiled into a shared library (typically called libGo4UserAnalysis.so). Most of the functionality previously implemented in MainUserAnalysis is now in the user analysis class (subclass of TGo4Analysis), which is instatiated by go4analysis. Existing analysis codes with explicit MainUserAnalysis program are still fully supported.

3.6.2 Command line mode (batch)

The main aim of batch mode is to process event data from files or other data source without GUI intervention. To run the analysis in batch mode, go4analysis is called from shell with several optional arguments. For instance, the command:

shell> go4analysis –file test.lmd –asf histos.root

will use file test.lmd as input and store all analysis objects (histograms, graphs) in file histos.root. The full description of the argument list is:

go4analysis [RUN] [ANALYSIS] [STEP1] [STEP2] ...[USER]

RUN: configuration, relevant for application run mode

-lib name : user library to load (default: libGo4UserLibrary)

-server [name] : run analysis in server mode, name is optional analysis name

-gui name guihost guiport : run analysis in gui mode, used by GUI launching the analysis

-run : run analysis in server mode (default: run if source specified)

-norun : do not automatically start event loop

-number NUMBER : process NUMBER events in batch mode

-hserver [name [passwd]] : start histogram server with optional name and password

-log [filename] : enable log output into filename (default:go4logfile.txt)

-help : show this help

-v -v0 -v1 -v2 -v3 : log verbosity (0 - maximum, 1 - info, 2 - warn, 3 - errors)"

ANALYSIS: common analysis configurations

-name name : specify analysis instance name

-noprefs : do not use preferences file.

-prefs [file] : use preferences file, default file is Go4AnalysisPrefs.root

-asf filename : set autosave filename and enable it, default <Name>ASF.root

-enable-asf [interval] : enable store of autosave file, optionally interval in seconds

-disable-asf : disable usage of asf

STEP: individual step configurations (steps must have been created in analysis (see below)

-step name|number : select step by it’s name or number (first enabled step is default).

-enable-step : enable step processing

-disable-step : disable step processing

-file filename.lmd : use lmd file as event source

-file filename.lml : use lml meta file as event source

-file @filename : use lml meta file as event source

-transport server : connect to MBS transport server

-stream server : connect to MBS stream server

-evserv server : connect to MBS event server

-revserv server port : connect to port of remote event server

-random : use random generator as source

-user name : create user-defined event source

-source filename : read step input from the root file

-enable-source : enable step source

-disable-source : disable step source

-store filename : write step output into the root file

-enable-store : enable step store

-disable-store : disable step store

-append-store : append step store file

-overwrite-store : overwrite step store file

-backstore name : create backstore for online tree draw

-enable-errstop : enable stop-on-error mode

-disable-errstop : disable stop-on-error mode

USER: argument list passed to the user analysis constructor

-x or –args [userargs] create user analysis with constructor (int argc, char** argv) signature

all following arguments will be provided as array of strings;

first argument is analysis name

A list of valid arguments can be obtained by launching go4analysis without any arguments. Execution of go4analysis can be terminated by pressing Ctrl-C. The analysis will regularly close all event sources, store results of processing in output files and then exit.

3.6.3 Creating the user analysis

On startup go4analysis loads the shared user library and instantiates the user analysis. There is a possibility to pass extra configuration parameters to the user analysis constructor, calling go4analysis with -args or -x followed by a user specific parameter list. This list is passed to the analysis constructor:

Example

shell> go4analysis –name TestAna –args xxx.lmd

TUserAnalysis::TUserAnalysis(int argc, char** argv) : TGo4Analysis(argc, argv)

{

// argc is 2

// argv[0] is "TestAna"

// argv[1] is "xxx.lmd"

const char* userinput = “default.lmd”;

cout << "User analysis " << argv[0] << "created" << endl;

if (argc>1) userinput = argv[1];

TGo4MbsFileParameter* input = new TGo4MbsFileParameter(userinput);

...

}

Similar to the argument list of the main() function argc defines number of parameters and argv contains parameter values. First parameter in the list is always the analysis instance name (either set in the GUI launch panel or by
–name argument, default is Go4Analysis). When go4analysis is started without user-specific arguments, only analysis name will be in the list and argc is 1. The user argument list can also be specified in the Analysis launch panel of the GUI.

3.6.4 Default user analysis

In simple cases (only one step) it is not necessary to implement a user-specific analysis class at all. It is sufficient to implement a processor (and optionally an output event) class. In this case go4analysis will search for such classes in the loaded library and instantiate them, using the default TGo4Analysis instance and creating one default analysis step (named Analysis).

3.6.5 Analysis controlled by Go4 GUI

In the interactive GUI mode go4analysis provides all the infrastructure needed to manage the connection to the GUI. Usually, the Go4 GUI is started first and than user launches the analysis program via Launch analysis. Mainly for debugging purposes one can instead use in the GUI Prepare for client connection menu command and than start the analysis in an independent shell by command (same as it is called by GUI):

shell> go4analysis –gui SomeName guihost 5000

Here SomeName is an arbitrary analysis name, guihost is the host name where the GUI is started and 5000 is the port number (may be different, is printed when GUI starts). Same input/output arguments, as in batch mode, can be specified behind. On startup go4analysis creates the analysis framework and connects the multi-threaded analysis client to the Go4 GUI. After the connection is established, the complete analysis framework can be controlled from the GUI. In section 3.6.10, page 18 we describe in detail what is happening on startup of the analysis client and what effect the GUI control actions have.

3.6.6 Analysis as server for multiple Go4 GUIs

When started from the GUI the analysis connects only this GUI and absolutely depends from it. If something happens with GUI or GUI just closed, analysis execution will be terminated. However, it is possible to run the analysis as a server, which allows to connect many GUIs (one controlling GUI and many observer GUIs).

The analysis is started as server independently from the GUI from a shell like in the batch mode but with argument –server

shell> go4analysis –server –stream mbs-server -norun

As in batch mode, in server mode analysis will start its event loop if input was specified. To prevent this, the -norun argument can be add. To force event loop execution with default analysis parameters, -run argument should be specified. An analysis to run in server mode can also be launched via Launch analysis menu command of the Go4 GUI when selecting the mode as server.

A Go4 GUI is able to connect any such started server. Login of GUI to the analysis server may be with observer, controller, or administrator role, respectively; their passwords can be set in user analysis code with DefineServerPasswords() method. There can be only one controller or administrator, but multiple observer GUIs. Observers may only view existing objects, but may not modify them or change analysis setup and running state. Controller may view and modify objects and analysis configuration, but is not allowed to terminate analysis server. Only Administrator may shutdown the analysis server.

See section 5.3.2, page 36 for more details on connection of the GUI client.

3.6.7 Configuration of analysis

There are several methods to configure the analysis which can be combined in a defined order:

Constructor of user analysis class

In any case the constructor is called first. All steps must be created. One may set up all steps like setting input and output filenames, enable/disable steps. One may excecute a macro for that. One may use user arguments given by go4analysis command (behind –x) or in the Launch analysis panel (Args).

Go4 preferences file

When launched from GUI, or started from shell by go4analysis command with the –server or –gui option, and settings had been saved before, these settings are now loaded from the file overwriting the coded setup. Default file name is Go4AnalysisPrefs.root. With –noprefs or –prefs <file> one can disable this loading or specify a different file, respectively. In the Analysis configuration panel a different file also can be loaded.

Arguments to go4analysis

When started from shell now the arguments of go4analysis are used and overwrite the settings.

Hotstart file

When launched from GUI with hotstart file the complete setting from that file is used and overwrites the settings.

3.6.8 Support of older analysis code

In previous go4 versions up to 4.3 it was required to have a user MainUserAnalysis program which was launched via the AnalysisStart.sh script. In most cases that executable can be used as is. Since version 4.4 the GUI directly calls the MainUserAnalysis executable (or program or script as specified in the Launch Analysis panel, see section 5.3, page 35) with same argument list as before. When AnalysisStart.sh script had been modified and therefore the old launch sequence is required, one should set shell variable GO4OLDLAUNCH=yes before starting the GUI.

In many real cases the go4analysis is able to correctly instantiate the user analysis, compiled into libGo4UserAnalysis.so library even if no (int, char**) constructor signature is implemented. To facilitate new Go4 functionality and flexibility, it is recommended to move user code from MainUserAnalysis to user analysis class, (i.e. TUserAnalysis) and remove MainUserAnalysis.

3.6.9 Setting up ssh keys

For launching the analysis on remote host from the GUI, password-less ssh login on this host must be enabled. It means, when typing “ssh hostname” command in the shell, no any password shall be requested. To configure such password-less login, a private/public key pair must be created and the public key must be copied to remote host:

shell> ssh-keygen –t rsa

answer all questions by RET or yes

shell> ssh-copy-id -i ~/.ssh/id_rsa.pub hostname

Now check with “ssh hostname” again that keys are installed properly. Normally, at first time ssh will ask to add hostname into list of known hosts. Answer “yes” and try login again. Only if ssh works without prompting at all, you can run analysis on that machine via the Go4 GUI.

There is no longer necessary to configure ssh for running analysis on the same machine (localhost), while now Go4 provides possibility to run analysis directly via exec mode. This solves the nasty problem of configuring ssh and DNS on machines which are not connected to a network at all.

From historical reason there is still rudimentary support of rsh for analysis launch. rsh in no longer supported in GSI, therefore it is not so good tested as other launch methods. For use of rsh, make sure that the file .rhosts exists in user home directory and that it contains entries for the machine names you want to run the Go4 analysis client on. The file .rhosts could e.g. look like this:

node01

node02

localhost

3.6.10 Start-up of GUI controlled analysis

When starting the Go4 analysis from GUI, the following actions take place in that order:

1. The Launch Analysis GUI panel started by reads settings from file $GO4SYS/etc/go4.prefs. Based on settings in this file, the launch command is composed and executed. Depending on the analysis mode (client or server) either -server or -gui argument lists are passed to the executable.

2. TGo4Analysis or user subclass (e.g. TUserAnalysis) is instantiated and initializes the analysis framework.

3. The analysis, if in client mode, connects to the Go4 GUI. Optionally, the Go4 histogram/object server is created. Note that the analysis in server mode does not connect automatically to the starting GUI, but waits for a separate connect request with login and password from any GUI. Only after this explicit connection the GUI gets control over the analysis server!

4. The analysis settings are loaded from the default preferences file Go4AnalysisPrefs.root. A message is sent to the GUI (if successful):
“Analysis Client MyClient: Status Loaded from file Go4AnalysisPrefs.root”
Note that all settings specified before in the compiled code (auto-save file name, event sources, etc.) are overwritten if the preferences file exists.

5. The configuration settings are now changed by additional arguments, provided to go4analysis executable.

6. The analysis objects are loaded and updated from the auto-save file. The file name from the loaded analysis settings is used, if existing. Otherwise, the filename specified in the preceding user code by SetAuto-saveFile(const chart* name) is used. If successful, a message is sent to the GUI:
”Analysis Client MyClient: Objects Loaded”.
If auto-saving was disabled completely by calling
SetAutoSave(kFALSE), the auto-save file is not opened here even if it exists, and no objects are loaded! The “overwrite filename” option in the auto-save settings must be disabled to recover objects of a previous auto-save file; otherwise, all objects in an old file of the same name are lost!

7. The analysis settings are displayed on the GUI. At this moment, the analysis configuration window pops up and shows the active settings. Note that a GUI, connected to an analysis server, only in administrator mode can change the analysis configuration.

8. End of analysis start-up. A message is sent to the GUI:
“Analysis Client MyClient has finished initialization”.
Note that now the analysis itself is not yet initialized, i.e. the event and processor objects have not been created, and there are still no connections to event sources, etc.

3.6.11 Submit settings and run analysis

At any time the user may apply new settings to the analysis and start/stop the run. Note that if the GUI runs as client connected to an analysis server, these operations are permitted for controller or administrator login only. The following is happening in the described order:

1. Submit the analysis settings. The settings as displayed in the analysis configuration window are sent to the analysis client.

i. First, an already existing analysis is closed (see below).

ii. The analysis is initialized with the new settings. Objects are loaded from the new auto-save file except auto-save is disabled by