The parameter fPressure is defined in the section TRestDetectorGas inside TRestRun but fDriftField is a member of TRestDetector.
But what I get is -- Warning : TRestDetectorGas::GetDriftVelocity. Warning fElectricField is zero! and in TRestDetectorGasfElectricField and fDriftVelocity are 0.
Hi @ddiez , what it matters is what you get at TRestDetectorSignalToHitsProcess. What are the values you retrieve there?
The TRestDetectorGas properties are changed on the fly, and what it really matters is the gas mixture. The TRestDetectorSignalToHitsProcess should update those values on InitProcess for the TRestDetectorGas, but I bet the TRestDetectorGas is not written again.
void TRestDetectorSignalToHitsProcess::InitProcess() {
// Function to be executed once at the beginning of process
// (before starting the process of the events)
// Start by calling the InitProcess function of the abstract class.
// Comment this if you don't want it.
// TRestEventProcess::InitProcess();
fGas = GetMetadata<TRestDetectorGas>();
if (fGas != NULL) {
#ifndef USE_Garfield
ferr << "A TRestDetectorGas definition was found but REST was not linked to Garfield libraries."
<< endl;
ferr << "Please, remove the TRestDetectorGas definition, and add gas parameters inside the process "
"TRestDetectorSignalToHitsProcess"
<< endl;
exit(-1);
#endif
if (fGasPressure <= 0) fGasPressure = fGas->GetPressure();
if (fElectricField <= 0) fElectricField = fGas->GetElectricField();
fGas->SetPressure(fGasPressure);
fGas->SetElectricField(fElectricField);
...
...
As, you see the values of TRestDetectorGas are only updated if the ones defined at the process are above zero.
Of course, this implementation could have the problem that if you have different processes fixing different pressures at the same processing chain, then, there they would enter in conflict.
Thats why I would recommended to define the pressure parameter at the globals section, so all processes take the same value.
In a second independent processing chain, one could use a different value for the pressure. I.e. if you want to consider electron diffusion at 4bars, but drift velocity later on at 8bar. Just to give a hypothetical example.
So, I guess it’s taking the pressure from the section TRestDetectorGas inside TRestRun and nothing for fDriftField, so it remains 0 and so fElectricField does, which is the product of both.
Here is interesting to read values from TRestDetector because they are taken directly from the .aqs file, so we won’t add any specific value during the processing chain, they remain fixed as settled by TRestDetector.
No, no, this is at the stage of hits and TRestDetector is already fine in rawSignals. Actually I run the processing chain in steps so I have intermediate files with TRestDetector fulfilled.
Ok, not sure now if the capability to use [TRestDetector::fPressure] inside process parameters is allowed right now.
I was having a try to implement that at TRestEventProcess::InitFromConfigFile.
This is my test, apparenty fRunInfo is ready and contains the metadata structures that we find inside the file. Then, we could use fRunInfo->ReplaceMetadataMembers(val).
I am able to recover properly the value zS::fPointThreshold, however, that is not the case for detParam::fPressure.
This is the try when I was investigating this possible implementation
Ok, just posting, and just it came to my mind the solution. The problem is that TRestDetector is being redefined at the RML again, so it is considering the new definition.
If I comment it out at run.xml I get the good values there.
