Skip to content
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

DD4Hep migration (SolidShapes) for TrackerNumberingBuilder (+TkAl & related CondTool/Geometry plugins) #29905

Merged
merged 24 commits into from Jul 16, 2020

Conversation

adewit
Copy link
Contributor

@adewit adewit commented May 19, 2020

PR description:

This changes:

  • DDSolidShapes -> cms::DDSolidShapes in TrackerNumberingBuilder.
  • cms::DDSolidShapes enum to match DDSolidShapes
  • DDCompactView -> cms::DDCompactView in TkAl - TrackerGeometryCompare and tracker-related CondTools/Geometry plugins

PR validation:

Unit tests run successfully; for tracker alignment plugin output was compared before and after these changes

if this PR is a backport please specify the original PR and why you need to backport that PR:

Not a backport

@cmsbuild
Copy link
Contributor

The code-checks are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-29905/15496

  • This PR adds an extra 44KB to repository

@cmsbuild
Copy link
Contributor

A new Pull Request was created by @adewit for master.

It involves the following packages:

Alignment/OfflineValidation
CondTools/Geometry
DetectorDescription/DDCMS
Geometry/MTDNumberingBuilder
Geometry/TrackerNumberingBuilder

@civanch, @Dr15Jones, @makortel, @cvuosalo, @christopheralanwest, @ianna, @mdhildreth, @cmsbuild, @tocheng, @tlampen, @ggovi, @pohsun, @kpedro88 can you please review it and eventually sign? Thanks.
@fabiocos, @vargasa, @makortel, @tocheng, @VinInn, @tlampen, @mschrode, @mmusich, @ebrondol, @slomeo, @venturia this is something you requested to watch as well.
@silviodonato, @dpiparo you are the release manager for this.

cms-bot commands are listed here

@tlampen
Copy link
Contributor

tlampen commented May 19, 2020

please test

@cmsbuild
Copy link
Contributor

cmsbuild commented May 19, 2020

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-run-pr-tests/6421/console Started: 2020/05/19 15:02

@cmsbuild
Copy link
Contributor

+1
Tested at: 7cfc76b
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-cbdd42/6421/summary.html
CMSSW: CMSSW_11_1_X_2020-05-18-2300
SCRAM_ARCH: slc7_amd64_gcc820

@cmsbuild
Copy link
Contributor

Comparison job queued.

Copy link
Contributor

@fabiocos fabiocos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a few questions about this update, which is interesting also for MTD, where I should forward port it

@@ -360,7 +361,7 @@ void TrackerGeometryCompare::createROOTGeometry(const edm::EventSetup& iSetup) {
}

//accessing the initial geometry
edm::ESTransientHandle<DDCompactView> cpv;
edm::ESTransientHandle<cms::DDCompactView> cpv;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adewit @cvuosalo @ianna isn't DDD supposed to coexist for the time being with DDCMS? Here I see a replacement, please correct me in case

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fabio is right. We want both. An example of how to handle both old DD and DD4hep in the same file is here:

https://cmssdt.cern.ch/lxr/source/Geometry/MTDGeometryBuilder/plugins/MTDParametersESModule.cc

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be fixed for the plugins now

@@ -10,11 +10,15 @@
#include "CondFormats/GeometryObjects/interface/PGeometricDet.h"
#include "Geometry/Records/interface/IdealGeometryRecord.h"
#include "Geometry/TrackerNumberingBuilder/interface/GeometricDet.h"
#include "DetectorDescription/Core/interface/DDCompactView.h"
#include "DetectorDescription/DDCMS/interface/DDCompactView.h"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here ase well

@@ -10,7 +10,7 @@
#include "CondFormats/GeometryObjects/interface/PGeometricDetExtra.h"
#include "Geometry/Records/interface/PGeometricDetExtraRcd.h"
#include "Geometry/TrackerNumberingBuilder/interface/GeometricDetExtra.h"
#include "DetectorDescription/Core/interface/DDCompactView.h"
#include "DetectorDescription/DDCMS/interface/DDCompactView.h"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here as well

@@ -5,7 +5,7 @@
#include "FWCore/ServiceRegistry/interface/Service.h"
#include "CondCore/DBOutputService/interface/PoolDBOutputService.h"
#include "CondFormats/GeometryObjects/interface/PTrackerParameters.h"
#include "DetectorDescription/Core/interface/DDCompactView.h"
#include "DetectorDescription/DDCMS/interface/DDCompactView.h"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here as well

@@ -223,5 +223,5 @@ GeometricTimingDet::Rotation GeometricTimingDet::rotationBounds() const {
std::unique_ptr<Bounds> GeometricTimingDet::bounds() const {
const std::vector<double>& par = params_;
TrackerShapeToBounds shapeToBounds;
return std::unique_ptr<Bounds>(shapeToBounds.buildBounds(shape_, par));
return std::unique_ptr<Bounds>(shapeToBounds.buildBounds(cms::DDSolidShape(static_cast<int>(shape_)), par));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adewit @ianna there are two kind of volumes which do not seem to have a correspondent in DD4hep, do we have use of them and is this compatible?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, thinking about it again I think you're right that this would break down if we had a ddpolycone_rrz/ddpolyhedra_rrz (in old dd) - the corresponding int would be 7 or 8 and that doesn't give a corresponding type in cms::DDSolidShape. Think there is a map to the single ddpolycone/ddpolyhedra that can be used to get this correct, need to check.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adewit Sorry, I had forgotten about the DDSolidShape map. It is in ​DetectorDescription/​DDCMS/​interface/​DDSolidShapes.h. @ianna I think we need a new template function for a cms::DDSolidShape to old DDSolidShape mapping. Could you please advise?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cvuosalo and @ianna - I've added the inverse of the value function (called value_reverse to use with the LegacySolidShapeMap to do cms::DDSolidShapeDDSolidShape). That seems to do the job; is that what you had in mind?

@@ -10,7 +10,8 @@

#include "Geometry/Records/interface/IdealGeometryRecord.h"
#include "Geometry/TrackerNumberingBuilder/interface/GeometricDet.h"
#include <DetectorDescription/Core/interface/DDCompactView.h>
//#include <DetectorDescription/Core/interface/DDCompactView.h>
#include <DetectorDescription/DDCMS/interface/DDCompactView.h>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

again this looks a simple replacement

return buildOpen(_par);
break;
case DDSolidShape::ddpolycone_rrz:
case cms::DDSolidShape::ddpolycone:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adewit @ianna ok, is this supposed to handle the old ddpolycone_rrz in a transparent way? Is it mapped into ddpolycone by DD4hep?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code appears to do more than it actually does. It should be simplified for clarity.

case cms::DDSolidShape::ddtubs:
case cms::DDSolidShape::ddpolycone:
case cms::DDSolidShape::ddsubtraction:
  return buildOpen();
  break;

Note that buildOpen() should be changed to take no parameter. If you check the definition of the method, it doesn't use its parameter.

Copy link
Contributor

@vargasa vargasa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello @adewit, you may need to double check with @cvuosalo. It looks to me the changes are made directly and as I understand there should be a way to switch between Core/DDCMS (*) until the migration is completed/validated. If the changes were already validated it should be fine tho (imo) but it is good to double check. Thank you for your work :)

[*] http://cms.cern.ch/iCMS/jsp/openfile.jsp?tp=draft&files=8001_cmsdd4hep.pdf

@@ -10,7 +10,8 @@

#include "Geometry/Records/interface/IdealGeometryRecord.h"
#include "Geometry/TrackerNumberingBuilder/interface/GeometricDet.h"
#include <DetectorDescription/Core/interface/DDCompactView.h>
//#include <DetectorDescription/Core/interface/DDCompactView.h>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If headers are not needed anymore please remove them

@@ -37,7 +38,7 @@ void GeometricDetLoader::beginRun(edm::Run const& /* iEvent */, edm::EventSetup
std::cout << "PoolDBOutputService unavailable" << std::endl;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When possible use LogVerbatim. see #29610

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are a load of couts in all these files - maybe changing them over to LogVerbatim should be decoupled from this PR?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adewit Yes, the cout fix can be done later.

@@ -4,6 +4,7 @@
#include "CondFormats/GeometryObjects/interface/PGeometricDet.h"
#include "DetectorDescription/Core/interface/DDExpandedView.h"
#include "DetectorDescription/Core/interface/DDSolidShapes.h"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Core headers, see my comment above

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Andres is right. There are still problems here. I think line 6 needs to be deleted. I don't see the old DDSolidShape being used here.
Also, migration code has to provided for the old DDExpandedView.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ha - I missed this. L6 can indeed go. As for DDExpandedView - what it provides for this file is two types that are effectively vectors of ints, so I've moved those defs into this file. However, I also see using GeoHistory = std::vector<DDExpandedNode>;, even though GeoHistory is not used in this file. Perhaps that can be removed - then DDExpandedView is not needed in this file at all.

I assume there is a good reason there's no direct dd4hep copy of DDExpandedView / DDExpandedNode (yet) - but if central changes are needed there they could then happen outside of this PR. In any case I don't think I'm the right person to make those changes (I definitely don't know enough about the requirements to be able to do this correctly)

@cmsbuild
Copy link
Contributor

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-cbdd42/6421/summary.html

Comparison Summary:

  • No significant changes to the logs found
  • Reco comparison results: 0 differences found in the comparisons
  • DQMHistoTests: Total files compared: 35
  • DQMHistoTests: Total histograms compared: 2694466
  • DQMHistoTests: Total failures: 48
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 2694369
  • DQMHistoTests: Total skipped: 49
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.0 KiB( 34 files compared)
  • Checked 150 log files, 16 edm output root files, 35 DQM output files

@cmsbuild
Copy link
Contributor

cmsbuild commented Jul 10, 2020

The tests are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

+1
Tested at: 637ae06
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-cbdd42/7872/summary.html
CMSSW: CMSSW_11_2_X_2020-07-10-1100
SCRAM_ARCH: slc7_amd64_gcc820

@cmsbuild
Copy link
Contributor

Comparison job queued.

@cmsbuild
Copy link
Contributor

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-cbdd42/7872/summary.html

Comparison Summary:

  • No significant changes to the logs found
  • Reco comparison results: 0 differences found in the comparisons
  • DQMHistoTests: Total files compared: 37
  • DQMHistoTests: Total histograms compared: 2787429
  • DQMHistoTests: Total failures: 1
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 2787378
  • DQMHistoTests: Total skipped: 50
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.0 KiB( 36 files compared)
  • Checked 154 log files, 17 edm output root files, 37 DQM output files

@christopheralanwest
Copy link
Contributor

+1

I performed tests similar to those in #29905 (comment). For the dumped versions of the tracker reco geometry, the only differences in the content of the <shape> tag correspond to a handful of interchanges between 5 <-> 7. The other interchanges are now absent. I am assured in #29905 (comment) and #29905 (comment) that these are harmless, which seems to be consistent with the results of the comparison tests.

@fabiocos
Copy link
Contributor

I verified that this PR introduces no change in the output of the MTD geometry tests (extended version, where the solid shape is printed as well)

@cvuosalo
Copy link
Contributor

@ggovi Please review this PR.

@ggovi
Copy link
Contributor

ggovi commented Jul 16, 2020

+1

@cmsbuild
Copy link
Contributor

This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @silviodonato, @dpiparo (and backports should be raised in the release meeting by the corresponding L2)

@silviodonato
Copy link
Contributor

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet