-
Notifications
You must be signed in to change notification settings - Fork 151
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
correction to check function #1970
correction to check function #1970
Conversation
Hi @knopers8 and @martenole, May you review this PR? |
@@ -102,10 +102,14 @@ Quality TrackletPerTriggerCheck::check(std::map<std::string, std::shared_ptr<Mon | |||
|
|||
// applying check | |||
float MeanTracletPertrigger = h->GetMean(); | |||
if (MeanTracletPertrigger > mDesiredMeanRegion.second && MeanTracletPertrigger < mDesiredMeanRegion.first) { | |||
if (MeanTracletPertrigger < mDesiredMeanRegion.second && MeanTracletPertrigger > mDesiredMeanRegion.first) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to avoid these kind of typos wouldn't it be better to use two variables in your checker class, e.g. mThresholdMeanLow
and mThresholdMeanHigh
or something like that? And then for reading the parameters from json file I'd prefer you use the common getFromConfig
as it is done for example in
QualityControl/Modules/TRD/src/DigitsTask.cxx
Lines 408 to 415 in a0dc3f4
// this is how to get access to custom parameters defined in the config file at qc.tasks.<task_name>.taskParameters | |
mDriftRegion.first = getFromConfig<float>(mCustomParameters, "driftRegionStart", 7.f); | |
mDriftRegion.second = getFromConfig<float>(mCustomParameters, "driftRegionEnd", 20.f); | |
mPulseHeightPeakRegion.first = getFromConfig<float>(mCustomParameters, "peakRegionStart", 0.f); | |
mPulseHeightPeakRegion.second = getFromConfig<float>(mCustomParameters, "peakRegionEnd", 5.f); | |
mPulseHeightThreshold = getFromConfig<unsigned int>(mCustomParameters, "phThreshold", 400u); | |
mChambersToIgnore = getFromConfig<string>(mCustomParameters, "ignoreChambers", "16_3_0"); | |
mLayerLabelsIgnore = getFromConfig<bool>(mCustomParameters, "ignoreLabels", true); |
Common/Utils.h
for this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated this PR with the above suggestions.
ILOG(Debug, Support) << "configure() : using default timestam of now = " << mTimeStamp << ENDM; | ||
} | ||
auto mTimeStamp = getFromConfig<long>(mCustomParameters, "ccdbtimestamp", o2::ccdb::getCurrentTimestamp()); | ||
ILOG(Debug, Support) << "using timestamp = " << mTimeStamp << ENDM; | ||
auto& mgr = o2::ccdb::BasicCCDBManager::instance(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what are you using the BasicCCDBManager for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I try to explain how I understood the concept of BasicCCDBManager. Although I do not fully understand.
- instance() method of class BasicCCDBManager : public CCDBManagerInstance initialise the class with ccdb server.
- Then setTimestamp() method is used for setting timestamp manually if required to be given from config file otherwise current time stamp is used. It set timestamp cache for all queries (line no. 75 of BasicCCDBManager.h).
- I see that BasicCCDBManager class itself by default set current timestamp (line no. 189 of BasicCCDBManager.h), so if we remove it from checker class it run without any problem.
- In lack of knowledge, I kept these line because I did not know its consequences.
I will do how you suggest.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had in my mind that in background of workflow, It set the timestamp of QO object generated by checker class. And if a specific object is needed by any postprocessing in future, It can use that timestamp to query that QO object. Although this thought needs validation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Deependra, I would simply remove the CCDB manager completely from your task, because to me it does not look like you are using it. In some cases people are requesting CCDB objects in their tasks and use the CCDB manager for it, but I don't think you need any calibration objects for your check so I would get rid of it to keep the code as clean as possible. Later we will need some CCDB objects for more advanced checks, but also there not the CCDB manager should be used anymore, but the more modern DPL CCDB fetcher. But we can talk about this when we get there :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Ole, I removed that part.
Hi @knopers8 , May you look at it if any review is required from your side? |
macOS CI errors seem legit:
|
eebfc79
to
3feda19
Compare
Thanks, should be good to merge now |
Correcting check function but still investigating trend problem