Online CHANGELOG 2.2.13_dev to maintain during development

There is a new development branch named v2.2.13_dev. It is highly encouraged to switch and work in that branch.

The following post has been created to keep an up-to-date summary of developments as soon as they are integrated in the development branch v2.2.13_dev. Then, it will be used to summarise the changes on the corresponding future release/tag v2.2.14.

Please, add here any relevant/important changes everybody should be aware of! Including them as a reply to this post.

  • Added new REST_ListMacros.C to list all the REST macros available. It also prints documentation that should be introduced using //*** . Check REST_PrintTrees.C for a documented example.
  • Added a new sub-dir in the process code directory, util. The util processes are the ones who have nothing to do with data analysis. We moved three processes into the folder: TRestDaqChannelSwitchingProcess, TRestRawSignalViewerProcess, TRestSignalViewerProcess.
  • Fixed bug on initialisation of observables when constructed manually using <observable name="obsName" .../>
  • Added new util process: TRestBenchMarkProcess. It monitors system load and the performance of REST, then saves the result as observables. The input and output event type is arbitary, so we can insert it anywhere in the process chain.

The example shows the CPU usage(in %) with time(in sec), under a 2 thread processing chain. The lowered gaps are when TTree is flusing data to disk

Added a new validateProcesses.py to identify problems in the construction of processes. For example to identify the problem reported in the following post automatically in the pipeline.

Updated TRestHitsEvent to save fType object. For concatenated MicroMegas readout it is not purely 2D. We should still have X information in YZ hits, and Y information in XZ hits. The new TRestHitsEvent saves all the information.

Need verification

revised TRestAnalysisPlot.

fixed observable leak for TRestTrackAnalysisProcess and TRestTriggerAnalysisProcess. Fixed a bug in TRestTriggerAnalysisProcess

TRestG4Hits contains a new member that stores the remaining kinetic energy of the particle.

I have increased the version of TRestG4Hits I wonder if that is enough or we need to increase also the class version of related classes as TRestG4Event.

TRestG4Hits::GetTime() now returns the global timestamp (in seconds) when the hit was recorded in the stepping action. Previously this method always returned 0.

Added new <panel definition inside TRestAnalysisPlot.

As described in the following post

http://rest-forum.unizar.es/t/new-feature-idea-on-trestanalysisplot/270