The reading of metadata members directly from the RML can be inplemented in TRestMetadata::ReadAllParameters(). After this, all we should do is to write the lines in InitFromConfigFile() like:
Doing this at the level of TRestRun is also possible, except that the process will not run. TRestRun doesn’t run the processes. It just treats the process as a normal metadata.
I don’t understand. For any type of data member it can load the string value once we add the logic. For example, in the last field we find the data member TRestDetectorSignalToHitsProcess::fMethod. It is a TString object. REST has defined string to TString converter. Then the input string “tripleMax” will be automatically assigned to TRestDetectorSignalToHitsProcess::fMethod
The idea is that I want to initialize the parameter with the content of a metadata class that is known to TRestRun.
Lets think for example on the class TRestDetectorElectronDiffusionProcess. This class retrieves from TRestDetectorGas the properties of the gas because it is implemented like that at TRestDetectorElectronDiffusionProcess::InitProcess.
I would like to skip this coding for the case of TRestDetector metadata class, and just write at the RML TRestDetector::fDataMember.
How this can be implemented at ReadAllParameters? TRestMetadata at TRestXXProcess does not now anything about TRestDetector, isn’t?
Perhaps fMethod is not the best example. Lets think about Double_t TRestDetectorSingnalToHitsProcess::fGasPressure, if TRestMetadata finds something like TRestDetector::fPressure inside the parameter value it will not apply the right conversion, right? We must replace by the value found at TRestDetector::fPressure before interpreting the parameter and place it at the class.
I mean, the process has access to TRestRun and it could be used to find the metadata member and replace it, but ReadAllParameters would not be able … right? So, there is a way that I can replace TRestDetector::fPressure before calling ReadAllParameters?
It should replace <<TRestMetadataClass::fDataMember>> by its value found from fRunInfo:
However, it is returning value = -1. So, it means that fRunInfo is not yet ready containing the values from TRestDetector?
configFile 03_hits.rml
driftVelocity 2
electricField <<TRestDetector::fPressure>>*<<TRestDetector::fDriftVoltage>>
gDataBase TRestDataBase
gasPressure <<TRestDetector::fPressure>>
inputFileName /storage/trex-dm/Canfranc/quickAnalysis/data/R01693_00000_Signals_Background_North_usertrex_V2.3.4.root
mainDataPath /storage/trex-dm/Canfranc//quickAnalysis//data/
method tripleMax
name signalToHits
observable all
type TRestDetectorSignalToHitsProcess
value ON
verboseLevel info
------
======
configFile 03_hits.rml
driftVelocity 2
electricField -1*-1
gDataBase TRestDataBase
gasPressure -1
inputFileName /storage/trex-dm/Canfranc/quickAnalysis/data/R01693_00000_Signals_Background_North_usertrex_V2.3.4.root
mainDataPath /storage/trex-dm/Canfranc//quickAnalysis//data/
method tripleMax
name signalToHits
observable all
type TRestDetectorSignalToHitsProcess
value ON
verboseLevel info
------
If you only need to implement this on processes, then it is possible to modify TRestEventProcess::InitFromConfigFile(), as it is done in the testing branch.
I tested on my side and it correctly replaced the value. I think getting -1 is because of fPressure is not set. Do you add “inputFormat” parameter and <TRestDetector section inside <TRestRun section?
By the way, I think defining <<, >> as the field mark to replace its content is not good. Why don’t we use [ and ] mark? Then, it is coherent with “inputFormat” parameter definition, and also compatible with xml syntax.
Ok, one problem was that inside the RML, on the TRestRun definition. I was re-definning an empty <TRestDetector> ... </TRestDetector>. If I remove this, then it considers the one that was stored in the ROOT input file.
So, it is ok right inside TRestEventProcess::InitFromConfigFile. It does the replacement. However, I see that later on it takes again the wrong values.
