-
Notifications
You must be signed in to change notification settings - Fork 0
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
Sistrip calib tree devel2018 backplane #14
base: sitripCalibTreeDevel2018
Are you sure you want to change the base?
Sistrip calib tree devel2018 backplane #14
Conversation
@@ -57,7 +57,7 @@ void LorentzAngleRunInfo::beginRun(const edm::Run & irun, const edm::EventSetup | |||
run = irun.run(); | |||
edm::ESHandle<TrackerGeometry> theTrackerGeometry; iSetup.get<TrackerDigiGeometryRecord>().get( theTrackerGeometry ); | |||
edm::ESHandle<MagneticField> magfield; iSetup.get<IdealMagneticFieldRecord>().get(magfield); | |||
edm::ESHandle<SiStripLorentzAngle> SiStripLorentzAngle; iSetup.get<SiStripLorentzAngleDepRcd>().get(SiStripLorentzAngle); | |||
edm::ESHandle<SiStripLorentzAngle> SiStripLorentzAngle; iSetup.get<SiStripLorentzAngleRcd>().get("deconvolution",SiStripLorentzAngle); |
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 @robervalwalsh Not sure why we need to hard-code "deco" here. Isn't it OK to consume the dependent record and let it deal with the latency switches?
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 @mmusich, I thought so, but the numbers coming out were different.
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.
Btw, the values from the dependent record were also different from the ones in the payload inspector.
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 thought so, but the numbers coming out were different.
Because you were using some runs in peak?
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.
Btw, the values from the dependent record were also different from the ones in the payload inspector.
what run number did you check?
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 am pretty sure I was using a run in deco. I have to go through my notes to find it. May take a while
@robervalwalsh I am positively puzzled by your claims. diff --git a/CalibTracker/SiStripLorentzAngle/plugins/LorentzAngleRunInfo.cc b/CalibTracker/SiStripLorentzAngle/plugins/LorentzAngleRunInfo.cc
index 49f1cae39c4..f021d66d76e 100644
--- a/CalibTracker/SiStripLorentzAngle/plugins/LorentzAngleRunInfo.cc
+++ b/CalibTracker/SiStripLorentzAngle/plugins/LorentzAngleRunInfo.cc
@@ -22,6 +22,8 @@
#include "Geometry/CommonDetUnit/interface/TrackingGeometry.h"
#include "CalibTracker/SiStripLorentzAngle/interface/LorentzAngleRunInfo.h"
+#include "DataFormats/TrackerCommon/interface/TrackerTopology.h"
+#include "Geometry/Records/interface/TrackerTopologyRcd.h"
using namespace edm;
using namespace reco;
@@ -58,6 +60,13 @@ void LorentzAngleRunInfo::beginRun(const edm::Run & irun, const edm::EventSetup
edm::ESHandle<TrackerGeometry> theTrackerGeometry; iSetup.get<TrackerDigiGeometryRecord>().get( theTrackerGeometry );
edm::ESHandle<MagneticField> magfield; iSetup.get<IdealMagneticFieldRecord>().get(magfield);
edm::ESHandle<SiStripLorentzAngle> SiStripLorentzAngle; iSetup.get<SiStripLorentzAngleDepRcd>().get(SiStripLorentzAngle);
+ edm::ESHandle<TrackerTopology> tTopoHandle; iSetup.get<TrackerTopologyRcd>().get(tTopoHandle);
+ const TrackerTopology* const tTopo = tTopoHandle.product();
+
+ std::stringstream ss;
+ SiStripLorentzAngle->printSummary(ss,tTopo);
+
+ std::cout << ss.str() << std::endl;
auto dets = theTrackerGeometry -> detsTIB();
dets.insert(dets.end(),(theTrackerGeometry -> detsTOB()).begin(),(theTrackerGeometry -> detsTOB()).end());
diff --git a/CondCore/SiStripPlugins/plugins/SiStripLorentzAngle_PayloadInspector.cc b/CondCore/SiStripPlugins/plugins/SiStripLorentzAngle_PayloadInspector.cc
index 14d2fa6f7bd..883080f49ea 100644
--- a/CondCore/SiStripPlugins/plugins/SiStripLorentzAngle_PayloadInspector.cc
+++ b/CondCore/SiStripPlugins/plugins/SiStripLorentzAngle_PayloadInspector.cc
@@ -42,7 +42,9 @@ namespace {
public:
SiStripLorentzAngleValue() : cond::payloadInspector::Histogram1D<SiStripLorentzAngle>("SiStrip LorentzAngle values",
- "SiStrip LorentzAngle values", 100,0.0,0.05){
+ "SiStrip LorentzAngle values", 100,0.0,0.05),
+ m_trackerTopo{StandaloneTrackerTopology::fromTrackerParametersXMLFile(edm::FileInPath("Geometry/TrackerCommonData/data/trackerParameters.xml").fullPath())}
+ {
Base::setSingleIov( true );
}
@@ -51,6 +53,11 @@ namespace {
std::shared_ptr<SiStripLorentzAngle> payload = Base::fetchPayload( std::get<1>(iov) );
if( payload.get() ){
+ std::stringstream ss;
+ payload->printSummary(ss,&m_trackerTopo);
+
+ std::cout << ss.str() << std::endl;
+
std::map<uint32_t,float> LAMap_ = payload->getLorentzAngles();
for(const auto &element : LAMap_){
@@ -60,6 +67,8 @@ namespace {
}// iovs
return true;
}// fill
+ private:
+ TrackerTopology m_trackerTopo;
};
/************************************************ and then tried to:
and I get:
and I get:
I am not able to reproduce the issue, at least in MC. |
For the record, I also forced the calibTree production to be run as if the MC was run was in Peak mode, by doing: conddb_import -c sqlite_file:LatencyPeak.db -f frontier://FrontierProd/CMS_CONDITIONS -i SiStripLatency_GR10_v1_hlt -t SiStripLatency_MC_peak -b 108449 -e 108449 #this is a peak mode run
cmsRun testProduceCalibrationTree_cfg.py conditionOverwrite="SiStripLatency_MC_peak,SiStripLatencyRcd,sqlite_file:LatencyPeak.db,,2020-09-29 12:42:42" and as expected this fails with:
as there is no |
Hi @mmusich, Thanks a lot for the checks! I think I found the source of my mistake. On data, when reading the payload with a private EDAnlayzer that reads out such information, I may have used IOV = 1 when calling EmptyIOVSource. The result for IOV = 1 is below. When using a meaningful IOV, the results for both columns are exactly the same as you also obtained. I will bring back the line iSetup.get<SiStripLorentzAngleDepRcd>().get(SiStripLorentzAngle); Test results for IOV=1 on data GT
|
This reverts commit 4bfd9c1.
So, I checked this branch for changes in size of the calibTree, by running the following command:
(665 input events) And I observe the following increase of the gainCalibration tree: That's an almost 25% increase of the tree size, which is not negligible. |
Thanks @robervalwalsh ! |
Hi @mmusich, thanks! The original idea is to have the code to produce those variables when running on cosmics only. How exactly this will be implemented is to be discussed with the calibtree expert. |
Additional variables for backplane correction studies
Fix reading LA values from database
Additional command line option for cosmic triggers