Documentation / Manuel utilisateur en C++ :

The constructors that can be used to get an instance of the TLinearBayesian class are those detailed in Section XI.2.3. As a reminder the prototype available are these ones:

// Constructor with a runner
TLinearBayesian(TDataServer *tds, TRun *runner, Int_t ns=1, Option_t *option="");
// Constructor with a TCode
TLinearBayesian(TDataServer *tds, TCode *code, Int_t ns=1, Option_t *option="");
// Constructor with a function  using Launcher
TLinearBayesian(TDataServer *tds, void (*fcn)(Double_t*,Double_t*), const char *varexpinput, const char *varexpoutput, int ns=1, Option_t *option="");
TLinearBayesian(TDataServer *tds, const char *fcn, const char *varexpinput, const char *varexpoutput, int ns=1, Option_t *option="");

The details about these constructor can be found in Section XI.2.3.1, Section XI.2.3.2 and Section XI.2.3.3 respectively for the TRun, TCode and TLauncherFunction-based constructor. In all cases, the number of samples is set to 1 by default and changing it will not change the results. As for the option, there are no specific options for this class.

The final step here it to construct the TDistanceFunction which is the compulsory step which should always come right after the constructor, but a word of caution about this step:

Once the TLinearBayesian instance is created along with its TDistanceFunction, two methods must be called before getting into the parameters estimation. These methods are compulsory as they will define the heart of the analytical formula to get the Gaussian parameter value of the a posteriori distribution (see [metho]).

The first one (even though there is no particular order between the two) is setRegressor, whose prototype is

void setRegressor(const char *regressorname);

The only argument is the regressorname field, which is the list of regressor names split by ":", using the usual format and this method, then, checks two things. The first one is the fact that the number of regressors must match the number of parameters to be calibrated. On top of this, the code passes through the list of attributes available in the reference observation TDataServer and check that every regressor name provided matches one existing attributes. As stated above, if the observation TDataServer does not contains the regressors (when the input file is loaded) these attributes have to be constructed from scratch either through TAttributeFormula or by using another dedicated assessor (as done in the use-case shown in Section XIV.11.2).

The other method is setObservationCovarianceMatrix whose prototype is

void setObservationCovarianceMatrix(TMatrixD &mat);

The only argument here is a TMatrixD whose content is the covariance matrix of the reference observation data. Once again, this method will check two things:

Given this, estimations can be performed. One can find an example of how to use these methods in the use-case dedicated subsection, more precisely in Section XIV.11.2.

Finally once the computation is done there are three different kinds of results and several ways to interpret but also transform it. This section details some important and specific aspect to it.

XI.4.3.1. Transformation of the results

The idea is that when you want to consider your model as linear, you might have to transform it a bit to have a correct linear behaviour and to express and compute the needed regressors. For this peculiar behaviour, one will rely on our use-case discussed in Section XIV.11.2. In this case, one should linearise the flowrate function as done here by writing:

where the regressor can be expressed as . From there, it is clear that we will be calibrating a newly defined parameter , so we will have to transform that back into our parameter of interest at some point.

This is the the sole reason why the method setParameterTransformationFunction has been implemented: transform the parameters estimated given the linear regressor, the observation covariance matrix and prior distribution. As the transformations, it they do exist which is not compulsory, are expected to be done with simple operations using constant values, they should not affect the covariance matrix of the posterior multidimensional normal distribution, only the mean vector. The prototype of this function is as follows:

void setParameterTransformationFunction(void (*fTransfoParam)(double *in, double *out));

Its only argument is a pointer to the transformation function in the usual C++ prototype. This function provided to get the proper values of the under-investigation parameters take two arguments: the input parameters which are the raw one estimated from the analytical formula detailed in [metho] and the output ones, which should be the ones one wants to have. Both parameters are double-array whose size must be the number of parameters.

The example provided in the use-case is really simple as there is only one parameter to be estimated, which implies that both argument are one-dimension double array which should look like this:

void transf(double *x, double *res)
{
    res[0] = 1050 - x[0];  // simply H_l = \theta - H_u
}

Warning

This is also possible in python but the transformation will still have to be the usual C++ one. To do so, the function has to be put in a C-file, for example called myFunction.C and this file has to be loaded in order to get the handle on the function. Here are the few lines that summarise these two steps in a fictional macro that would define a cal instance of TLinearBayesian:

# Define all the needed material: dataservers, models...
cal=Calibration.TLinearBayesian(...) # Create the instance and distance function
# ...
# Load the file in which Transformation function
ROOT.gROOT.LoadMacro("myFunction.C")
# Provide this function to the TLinearBayesian instance
cal.setParameterTransformationFunction(ROOT.transf)

void drawParameters(TString sTitre, const char *variable = "*", const char *select = "1>0", Option_t * option = "");

void computePredictionVariance(URANIE::DataServer::TDataServer *tdsPred, string outname);