Distinguish between North and South detectors by AGET ID

[DavidDiezIb]

New process added to distinguish events from North and South sides using only the AGET ID. Not readout needed.

[jgalan]

Why would you need to add side identification at the raw processing stage? Would not be better to use the readout to generate an observable identifying the readout plane?

This process is highly specific. If there is a reason to do this at raw processing stage, then I would do something that allows you to define through metadata the range ids that correspond to South and the daq-ids that correspond to North.

For example, you could create a process that defines:

<TRestRawDaqIdTaggingProcess ...>
      <tag name="South" ids="(0,72*8-1)" />
      <tag name="North" ids="(72*8,72*16)" />
</TRestRawDaqIdTaggingProcess>

Then, if the process identifies that all daq-ids belong to the same group, it creates an observable that contains "South" or even an id number, or both.

[jgalan]

That makes the process less specific, and you define how to use it at the RML.

[DavidDiezIb]

The purpose of this is precisely to avoid the use of the readout, as a way of testing other processes that make use of itto extract the same information (could be done with zMean observable from TRestDetectorHitsAnalysisProcess).

I agree it could be generalized with the ID ranges, I'll change it. At first thought, I prefered to set just one number but now I see it is easier to read the code (mainly in the rml) if we use ranges.

[nkx111]

Why no East and West :P?

The process name also looks specific. We shall not include experiment names in it.

[jgalan]

Why no East and West :P?

The process name also looks specific. We shall not include experiment names in it.

Right, the day that TREX-DM is moved to a new hall and placed in west-east direction you will need to change the parameter names.

[DavidDiezIb]

You are right, I'll remove all references to TREX experiment. And I'll try to implement as you suggested @jgalan

<TRestRawDaqIdTaggingProcess ...>
      <tag name="South" ids="(0,72*8-1)" />
      <tag name="North" ids="(72*8,72*16)" />
</TRestRawDaqIdTaggingProcess>

But how should I define these "tag" sections? I don't know how write that in order to the rml understands the parameters, do we have any process that use something similar?

[jgalan]

You may have a look to the following example: https://github.com/rest-for-physics/geant4lib/blob/master/src/TRestGeant4Metadata.cxx where it is extracted activeVolume, having a look it should be something as follows in the implementation of InitFromConfigFile.

You do a for loop to extract every line found. It would be something similar to this:

void ... InitFromConfigFile() ...


     // This line is to exploit the retrieval of parameter as it is done at any process
     TRestEventProcess::InitFromConfigFile();

    // This is the additional code required by the process to read tags
    TiXmlElement* tagDefinition = GetElement("tag");
    while (tagDefinition) {
        fTagNames.push_back( GetFieldValue("name", tagDefinition)) );

        fIdRanges.push_back( Get2DVectorParameterWithUnits( "ids", tagDefinition );

        }
        tagDefinition = GetNextElement(tagDefinition);
    }

Then you have all you need inside std::vector<std::string> fTagNames and std::vector <TVector2> fIdRanges.

Then, just iterate over each tagName, both lists will have the same number of elements.

So you iterate over and fill a temporal string inside ProcessEvent,

I would try the following strategy. If all channels fall inside your tag range, then you define the tag with the user given tag, if not I would keep a default tag, for example std::string tag = "notUnique". Only if all channels belong to the tag I would assign the tag name corresponding to the tag. Then, you do SetObservableValue("tag", tag);.

Then you may have another observable, which is an integer. And you define bit to bit if there are any channels inside that range definition.

Lets imagine we have 4 tag definitions, south, north, east and west.

You do the loop (I write in pseudo code):

Int_t tagCode = 0;
for ( n in fTagNames)
   if( any signal inside fIdRanges )
         tagCode += 1 << n;

That way you will create a number that identifies the ranges where we found active channels.

For example, if you define "north - south - west - east" ranges.

The first tag is identified with the lowest significative bit, then

4 = West 
5 = West+North 
2 = South
6 = South + West
...

[jgalan]

I find the above tagCode the best way, but you need then to look into the metadata and understand what it means each code. It takes a bit of additional effort, but then you may see the number of events that gave something only in South (tagCode=1), the number of events that gave something in North (tagCode=2), and the number of events that gave something in both (tagCode=3).

[DavidDiezIb]

Thaks for the help @jgalan. Now the process should be completely generic, it admits any number of daq Id ranges that can be named as we wish. Basically I implemented your proposed strategy and it worked really well.