TPC QC: Add skeleton for GPUErrorQA task

[ariedel-cern]

Add skeleton for GPUErrorQA task in O2.

In this draft, only the number of errors for a given error code is counted and put into a 1D histogram.

In principle the error is reporting 4 values, the error code +3 parameters (like SectorRow, Sector, Value, Max ...). However, the meaning of the parameters depends on the error code itself (defined in GPUErrorCodes.h). There was a suggestion in the past to display the errors in a 2D histogram.

In principle, we could implement 3 2D histograms, putting the error code on the x-axis and the different parameter values on the y-axis.

Tagging @wiechula and @davidrohr for their opinion.

[github-actions]

REQUEST FOR PRODUCTION RELEASES:
To request your PR to be included in production software, please add the corresponding labels called "async-" to your PR. Add the labels directly (if you have the permissions) or add a comment of the form (note that labels are separated by a ",")

+async-label <label1>, <label2>, !<label3> ...

This will add <label1> and <label2> and removes <label3>.

The following labels are available
async-2023-pbpb-apass4
async-2023-pp-apass4
async-2024-pp-apass1
async-2022-pp-apass7
async-2024-pp-cpass0
async-2024-PbPb-apass1
async-2024-ppRef-apass1

[davidrohr]

I think a 2D histogram might make sense, at least as an overview, since you would see al error types.
Perhaps even a 1D, just with the counts for the error codes could give a good first overview?
Ideally, could we put the error code names as ticks on the x-axis.

Then we might want additional 3D histograms on top, for single error codes, with multiple parameters?
I guess adding the histograms is simple? We could also just start with something and then extend?

And to be honest, I am not so familiar with other QC tasks, so I don't know what is the normal strategy.

[ariedel-cern]

Thanks for the comments, David.
For now I put only 1 histogram which counts the occurring errors. Then I can also finish up the implementation in QC itself.
I think memory consumption is always a bit of a concern for QC. If you can tell which errors are of special importance we can discuss if we can have dedicated higher dimensional histograms for these.

[wiechula]

Suggested change

	namespace o2
	{
	namespace tpc
	{
	namespace qc
	{
	namespace o2::tpc::qc
	{

[wiechula]

Suggested change

	} // namespace qc
	} // namespace tpc
	} // namespace o2
	} // namespace o2::tpc::qc

[wiechula]

use forward declaration for TH1

Suggested change

	// root includes
	#include "TH1.h"
	// o2 includes
	// #include "DataFormatsTPC/Defs.h"
	class TH1;

[wiechula]

If the histograms don't need to be filled outside, this can be const

Suggested change

	std::unordered_map<std::string, std::unique_ptr<TH1>>& getMapHist() { return mMapHist; };
	std::unordered_map<std::string, std::unique_ptr<TH1>>& getMapHist() const { return mMapHist; };

[wiechula]

Suggested change

	#include <memory>
	#include <string>
	#include <memory>

[wiechula]

Suggested change

	#include <TH1.h>
	#include "TH1.h"

[wiechula]

It's already defined in the header

Suggested change

	#include <memory>
	#include <unordered_map>

[wiechula]

Why is this a histogram of floats? If it is a simple counter, it could also be TH1I, unless one would like to normalize at some point.

[wiechula]

To me it does not make sense to put each histogram in a separate array.

Suggested change

	for (const auto& [name, hist] : mMapHist) {
	TObjArray arr;
	arr.SetName(name.data());
	arr.Add(hist.get());
	arr.Write(arr.GetName(), TObject::kSingleKey);
	}
	TObjArray arr;
	arr.SetName("GPUError_Hists");
	for (const auto& [name, hist] : mMapHist) {
	arr.Add(hist.get());
	}
	arr.Write(arr.GetName(), TObject::kSingleKey);

[github-actions]

This PR did not have any update in the last 30 days. Is it still needed? Unless further action in will be closed in 5 days.