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] MagneticField Builder Shapes Use Cleanup - Use dd4hep::Solid Directly #31578

Closed

Conversation

ianna
Copy link
Contributor

@ianna ianna commented Sep 25, 2020

PR description:

Addressing #31569

  • Use DD4hep Shapes and their accessors

This is done in preparation of removing the extra classes that duplicate the DD4hep ones:
https://cmssdt.cern.ch/lxr/source/DetectorDescription/DDCMS/interface/DDShapes.h

@namapane - The functionality is unchanged - essentially, it's a one to one copy from DDCMS. The comparison tests pass.
The PseudoTrap workaround is untouched. Please, check the units conversion and the angle restriction.

If it's ok with you, I'd like to integrate this PR asap. It will allow me to proceed with removal of the DDShapes.h and DDShapes.cc. The MF builder is the last one that using it.

There is an inconsistency in getting a half Z (AIDASoft/DD4hep#714). We may need to revisit this code depending on the issue outcome later.

PR validation:

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

Before submitting your pull requests, make sure you followed this checklist:

@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-31578/18623

  • This PR adds an extra 16KB to repository

@cmsbuild
Copy link
Contributor

A new Pull Request was created by @ianna (Ianna Osborne) for master.

It involves the following packages:

MagneticField/GeomBuilder

@perrotta, @jpata, @cmsbuild, @slava77 can you please review it and eventually sign? Thanks.
@namapane this is something you requested to watch as well.
@silviodonato, @dpiparo, @qliphy you are the release manager for this.

cms-bot commands are listed here

@ianna
Copy link
Contributor Author

ianna commented Sep 25, 2020

please test

@cmsbuild
Copy link
Contributor

cmsbuild commented Sep 25, 2020

The tests are being triggered in jenkins.

@namapane
Copy link
Contributor

Uhm. buildBox.icc etc. are also used in the non-DD4Hep version that is still the default. I am a bit uncomfortable with diverging in the two implementations, unless there is a clear timeline on when we will make the DD4Hep version default and drop the non-DD4Hep one.
Also I would have to test all existing geometries built from both DB and xml to check for possible side effects, can you wait for a few days for these checks before merging ?

@namapane
Copy link
Contributor

And actually what is the exact point of moving the content of the .icc files in the cc? From a quick look I did not spot code changes... I would avoid duplicating this code if that is not strictly necessary.

@cmsbuild
Copy link
Contributor

+1
Tested at: 21c69bf
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-d181c9/9573/summary.html
CMSSW: CMSSW_11_2_X_2020-09-24-2300
SCRAM_ARCH: slc7_amd64_gcc820

@cmsbuild
Copy link
Contributor

Comparison job queued.

@ianna
Copy link
Contributor Author

ianna commented Sep 25, 2020

Uhm. buildBox.icc etc. are also used in the non-DD4Hep version that is still the default. I am a bit uncomfortable with diverging in the two implementations, unless there is a clear timeline on when we will make the DD4Hep version default and drop the non-DD4Hep one.
Also I would have to test all existing geometries built from both DB and xml to check for possible side effects, can you wait for a few days for these checks before merging ?

@namapane - Sure, no problem. As far as I understand, the 20th October is a deadline to start full validation. I'd like to restrict the API beforehand.

The differences are the shape APIs. For example, here is a new version:

  DDBox box(solid.solid());
  // Old DD needs mm to cm conversion, but DD4hep needs no conversion.
  // convertUnits should be defined appropriately.
  double halfX = convertUnits(box.x());
  double halfY = convertUnits(box.y());
  double halfZ = convertUnits(box.z());

vs an old version:

  DDBox box(solid);
  // Old DD needs mm to cm conversion, but DD4hep needs no conversion.
  // convertUnits should be defined appropriately.
  double halfX = convertUnits(box.halfX());
  double halfY = convertUnits(box.halfY());
  double halfZ = convertUnits(box.halfZ());

After #31577 and #31571 are merged MF builder remains the only package that is still using the DDShapes wrapper classes.

If you prefer, we can move it under your control :-) https://cmssdt.cern.ch/lxr/source/DetectorDescription/DDCMS/interface/DDShapes.h
https://cmssdt.cern.ch/lxr/source/DetectorDescription/DDCMS/src/DDShapes.cc

In any case, you are welcome to take over this PR.

@namapane
Copy link
Contributor

@ianna I see; I would actually prefer to modify the existing functions to pass the list of parameters for each case (the solution that was eventually adopted for buildPseudoTrap) so that we don't need to duplicate code. It should be rather straightforward but I need to carve out a couple of days for that... What is your target date for restricting the API?

What is your deadline to restrict the API?

@ianna
Copy link
Contributor Author

ianna commented Sep 25, 2020

@ianna I see; I would actually prefer to modify the existing functions to pass the list of parameters for each case (the solution that was eventually adopted for buildPseudoTrap) so that we don't need to duplicate code. It should be rather straightforward but I need to carve out a couple of days for that... What is your target date for restricting the API?

What is your deadline to restrict the API?

@namapane - I was hoping to finish it this week since I need to concentrate on another unrelated project, but it can wait a couple of days, for sure.

@cmsbuild
Copy link
Contributor

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-d181c9/9573/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: 2539438
  • DQMHistoTests: Total failures: 1
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 2539415
  • DQMHistoTests: Total skipped: 22
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.0 KiB( 34 files compared)
  • Checked 149 log files, 22 edm output root files, 35 DQM output files

using DDTrap = dd4hep::Trap;
using DDTubs = dd4hep::Tube;
using DDCons = dd4hep::ConeSegment;
using DDTruncTubs = dd4hep::TruncatedTube;
Copy link
Contributor

Choose a reason for hiding this comment

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

If the above five lines were put into DetectorDescription/DDCMS/interface/DDShapes.h, then this PR wouldn't be needed. Or would there be some problem?

#include "buildTrap.icc"
#include "buildTubs.icc"
#include "buildCons.icc"
/*
Copy link
Contributor

Choose a reason for hiding this comment

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

I think the code duplication below should be avoided. I don't understand why the icc files can't be used as they are.

Copy link
Contributor

Choose a reason for hiding this comment

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

That was my question (see above) but Ianna pointed out to slight changes in interface, eg x() becoming halfX()
My suggestion is to extract the relevant parameters for each shape in *volumeHandle.cc and pass them to the functions in the .icc files, as done already in buildPseudoTrap.icc. This way the actual implementation remains where it is and we just need to adjust the callers.

@slava77
Copy link
Contributor

slava77 commented Sep 26, 2020

assign geometry

since quite a bit of the discussion and possible updates are related to geometry changes, I'd rather have a signature provided explicitly. The reco signature may follow after, assuming @namapane is happy with the changes.

@cmsbuild
Copy link
Contributor

New categories assigned: geometry

@Dr15Jones,@cvuosalo,@mdhildreth,@makortel,@ianna,@civanch you have been requested to review this Pull request/Issue and eventually sign? Thanks

@ianna
Copy link
Contributor Author

ianna commented Oct 1, 2020

@namapane - I was wondering what to do with this PR. I can just move the DDShapes.h/.cc under MagneticField/GeomBuilder/src/ to decouple the other PRs.

@namapane
Copy link
Contributor

namapane commented Oct 1, 2020

@ianna - for what I'm concerned this PR should be recoded (ie closed and replaced by another one) refactoring the code that is being duplicated in this PR so that it does not need to be duplicated. It is a really easy task (just pass float parametes instead of shapes to the functions that are being replicated). As promised I plan to work on that.
I do not see much point in releasing this PR as is by also moving here classes whose dependency was, in any case, introduced because of the migration to DD4Hep itself (and not by me). That it will make subsequent cleanup unnecessarily more complicated.
That is just my opinion and you can of course go on if you prefer, Although I am sure that, on the path of release, others will object to the duplication of code snippets...

@ianna
Copy link
Contributor Author

ianna commented Oct 2, 2020

@ianna - for what I'm concerned this PR should be recoded (ie closed and replaced by another one) refactoring the code that is being duplicated in this PR so that it does not need to be duplicated. It is a really easy task (just pass float parametes instead of shapes to the functions that are being replicated). As promised I plan to work on that.
I do not see much point in releasing this PR as is by also moving here classes whose dependency was, in any case, introduced because of the migration to DD4Hep itself (and not by me). That it will make subsequent cleanup unnecessarily more complicated.
That is just my opinion and you can of course go on if you prefer, Although I am sure that, on the path of release, others will object to the duplication of code snippets...

@namapane - thanks! OK, I'm closing this PR. Would you object moving the DDShapes.h/.cc under MagneticField/GeomBuilder/src/ to decouple the other pending PRs? Thanks.

@ianna ianna closed this Oct 2, 2020
@namapane
Copy link
Contributor

namapane commented Oct 2, 2020

I'm working on this right now

Copy link
Contributor

@namapane namapane left a comment

Choose a reason for hiding this comment

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

Done, #31649.

double rIn = convertUnits(tubs.rMin());
double rOut = convertUnits(tubs.rMax());
double startPhi = convertDegToRad(tubs.startPhi());
double deltaPhi = convertDegToRad(tubs.endPhi()) - startPhi;
Copy link
Contributor

@namapane namapane Oct 2, 2020

Choose a reason for hiding this comment

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

I am looking into this in the context of #31578 and I wonder why you converted to rad here? To me looks like these are in rad already.
[edit: they are in rad indeed. I removed the conversion from the re-implementation in #31649

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.

5 participants