Documentation / Manuel utilisateur en C++ :

These classes reify the TLauncherFunction analytic function.

The ROOT on-the-fly compiler is now compatible with the C++ syntax but there are two ways to access an already written functions:

For the former, whose interface is the TCJitEval class, only usable in C++, there are no problem of thread-safety which is not the case for the latter, whose interface is the TCIntEval class which is not considered thread-safe. Given these consideration the latter shall not be used with a TThreadedRun, while the CJit version deals with the ROOT Just in time compiler, and is considered thread-safe. This is further discussed in Section VIII.4.2.

User supplied function needs to comply with a C prototype. Both version class constructors can use the TLauncherFunction prototype. Three extended prototypes are added for a more advanced usage.

// TLauncherFunction prototype
void standart_prototype(double *in, double *out);
// extension prototypes
int extended_prototype(double *in, double *out);
int extended_prototype(double *in, double *out, void *foo);
int uentry_prototype(std::vector<URANIE::DataServer::UEntry*> *in, std::vector<URANIE::DataServer::UEntry*> *out);

The first extension is used to deal with non-calculable evaluations. It uses the return value, which should be 1 in usual case and 0 if the output values cannot be computed. The second one can be used to pass extra information to the function by casting it as a pointer of void. The last extension prototype is used when evaluation deals with string or std::vector<double> input or output. Its use is tricky so we recommend to contact us if this is the only solution you have.

The class constructor first argument is the function pointer.

The class definition gives information neither about the input or output number nor about parameter order. These information have to be added to link with TDataServer and TMaster definitions. We use the addInput and addOutput method with TAttribute objects as argument to do so. Inputs and outputs have to be added in correct order. Here is an example of how to precise inputs and outputs, from the script in Section VIII.2:

// problem variables 
TAttribute x("x", -3.0, 3.0),
           y("y", -4., 6.),
           ros("rose");

// user evaluation function
TCIntEval eval("rosenbrock");
eval.addInput(&x); // Adding attribute in the correct order
eval.addInput(&y);
eval.addOutput(&ros);

For a more user friendly definition, you can use the setInputs and setOutputs methods. Instead of only requesting a pointer to the attribute under consideration, a first compulsory argument is an integer that equals the number of attributes to come, followed by as many pointers to attribute. Taking the example provided above, one can create a second assessor, using theses methods instead of the addInput and addOutput ones.

// user evaluation function
TCIntEval eval2("rosenbrock");
eval2.setInputs(2,&x,&y); // Adding attributes in the correct order, all at once
eval2.setOutputs(1,&ros);

In order to be used in parallel (MPI or thread), we have to take care of file access conflicts: many processes which modify the same file. To avoid such a thing, Uranie creates for each resource a personal directory named URA with then a set of numbers and letters that is more robust than the older version with just increasing numbers. Everything is done in it: input files are created there, executable is run from it and the output file are supposed to be found here as well. By default, these directories are created in the current folder. You can specify another root directory, using the setWorkingDir method. There are two other methods that can be called to change this:

Input files are often created from template files. These files, if they are not defined with a full path, are search in the current directory. You can specify another one using the setReference method.

The class constructor takes a string (const char*) as argument which is the command line used to launch the executable. %D jocker can be used, and will be replaced by the local directory.

With the introduction of the vectors and strings from version 3.10.0, more complex interaction with files were introduced: how to differ two iterations of a single vector and how to differentiate a double from a string. This depends highly on the nature of the input/output file under consideration, whether it is just a text file used as database (in this case it depends mostly on the way you've written the code that generate/parse it) or whether it corresponds to a more strict kind of file, for instance a piece of code (c++/python/zsh). In the latter case, strings and vectors are not written in the same way. To take this into account, a rule has been defined (commonly to both input and output files, both in the Launcher and Relauncher module). There is a method for any kind of file to define properties of vector and string objects:

Depending on the kind of chosen file, there is a default configuration chosen. This default is precised in the following two sections.

Input file formats supported by TCodeEval objects, include:

TXmlScript is not provided in this version

The addInput method is used to declare parameters for all these file types. For TFlatScript and TLineScript, it takes a single argument: a pointer to a TAttribute object, while in the two other cases, the same first argument is completed by a const char * for the key. The declaration order is only significant when no key is specified (so for the TFlatScript and TLineScript files).

// Input File Flat format case
TFlatScript finp1("input_rosenbrock_with_values_rows.dat");
finp1.addInput(&x); // Adding attributes in the correct order, one-by-one
finp1.addInput(&y);

// Or Input File Key format case
TKeyScript kinp1("input_rosenbrock_with_keys.dat");
kinp1.addInput(&x, "x"); // Adding attributes in the correct order, one-by-one
kinp1.addInput(&y, "y");

A more condensed version of this addInput method exists for all these input types: the setInputs method. Here as well, it takes an extra compulsory argument, an integer which equals the number of attributes to come. The rest of the arguments are either a single pointer to a TAttribute object for the TFlatScript and TLineScript objects, or a pair composed of the same pointer directly followed by the key (for the two other input file types). Starting back from our example written above, one could condensate this into these lines:

// Input File Flat format case
TFlatScript finp2("input_rosenbrock_with_values_rows.dat");
finp2.setInputs(2, &x, &y); // Adding attributes in the correct order, all at once

// Or Input File Key format case
TKeyScript kinp2("input_rosenbrock_with_keys.dat");
kinp2.setInputs(2, &x, "x", &y, "y"); // Adding attributes in the correct order, all at once

Once done, the input files are provided to the TCodeEval object, using the addInputFile method, as shown below:

// Add to the TCodeEval
TCodeEval code("rosenbrock -r"); // put "rosenbrock -k" instead for key
code.addInputFile(&finp1); // put &kinp1 instead for key 

Output file formats supported by TCodeEval include:

TXmlResult is not provided in this version

In a similar way of TInputFile, one should use the addOutput to declare parameters, the argument being the pointer to the attribute under consideration for all these formats, pairing with the corresponding key when dealing with a TKeyResult object. This step can be gathered in a single operation, as for the input file, using the setOutputs method. Here is an example for the ongoing use-case.

// Input File Flat format case
TFlatResult fout("_output_rosenbrock_with_values_rows.dat");
fout.addOutput(&ros); // Or fout.setOutputs(1, &ros); 

// Or Input File Key format case
TKeyResult kout("_output_rosenbrock_with_keys.dat");
kout.addOutput(&ros, "ros"); // Or kout.setOutputs(1, &ros);

Finally, use the addOutputFile method of TCodeEval to declare it:

// Add output file to the TCodeEval
code.addOutputFile(&fout); // put &kout instead for key 

This composer can be seen as an overall new assessor that is, usually provided to the runner (or to a master directly).

The constructor have no argument. The only important method is the addEval one that allows users to add evaluation functions, keeping in mind that they should be called in the correct order, regarding what they expect (the only argument of the function being a pointer to the assessor to be stacked to create the chain). Examples of composition can be found in Section XIV.8.14.

As for the input/output attributes or a regular assessor, one can use the setEvals (mind the "s") that allows to put all the pointers as argument of the function, right after an int parameter that state the number of assessor procided to define the composition.