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

Implement lumi dipole B mapping #527

Merged
merged 34 commits into from
Oct 17, 2023
Merged

Implement lumi dipole B mapping #527

merged 34 commits into from
Oct 17, 2023

Conversation

dhevang
Copy link
Contributor

@dhevang dhevang commented Sep 18, 2023

Briefly, what does this PR introduce?

Implement lumi dipole B mapping and modify source code to treat R-Z and X-Y-Z coordinate systems.

What kind of change does this PR introduce?

  • Bug fix (issue #__)
  • [x ] New feature (issue #__)
  • Documentation update
  • Other: __

Please check if this PR fulfills the following:

  • Tests for the changes have been added
  • Documentation has been added / updated
  • Changes have been communicated to collaborators

Does this PR introduce breaking changes? What changes might users need to make to their code?

Does this PR change default behavior?

@dhevang
Copy link
Contributor Author

dhevang commented Sep 18, 2023

@wdconinc , in your code, FieldMapBrBz.cpp, which I used as the basis for this extension, you had a coordinate transformation here:

auto p = trans_inv * ROOT::Math::XYZPoint(pos[0], pos[1], pos[2]);

and then a B field transformation (trans) here:
auto B = trans * ROOT::Math::XYZPoint(Br * sin(phi), Br * cos(phi), Bz);

I'm not sure I understand the latter. To me, only the first one was needed. Anyway, the translation and rotation for the MARCO field were zero, so this had no effect. However, for the lumi dipole field, I have the translation active.

@wdconinc
Copy link
Contributor

Can you rebase so this lists only the changes relevant to this PR under files? Probably just a matter of running git rebase origin/main in your branch, then git push --force (but check first with git log that this has all relevant commits).

@dhevang
Copy link
Contributor Author

dhevang commented Sep 18, 2023

Do you mean to undo the little changes to the files compact/fields/beamline_*.xml?
I meant those to part of this commit but I can undo them if you want. I meant for 19 files to be changed in this PR. All but a few are trivial.

@wdconinc
Copy link
Contributor

Please keep the changes to code and changes to quantities separate. Makes it easier to determine if there are any changes introduced by the change to the code that are not due to the changes to the quantities.

@dhevang
Copy link
Contributor Author

dhevang commented Sep 18, 2023

Ok, done.

@veprbl veprbl self-assigned this Sep 20, 2023
@dhevang
Copy link
Contributor Author

dhevang commented Sep 20, 2023

@ajentsch, would this implementation of the BxByBz field map work for your purposes in the B0?

@ajentsch
Copy link
Contributor

ajentsch commented Sep 20, 2023 via email

@dhevang
Copy link
Contributor Author

dhevang commented Sep 21, 2023

Thanks. you can use the dumpBfield program to print the field in your location of interest, and confirm that the mapping implementation worked.
My PR to extend the functionality of this in DD4hep was merged into their main branch today. Not sure when that propagates to what's in the eic-shell though...

ajentsch
ajentsch previously approved these changes Sep 21, 2023
Copy link
Contributor

@ajentsch ajentsch left a comment

Choose a reason for hiding this comment

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

I was able to upload the B0pf field map and see DD4HEP successfully build it. I will do further tests for the B0 map in a separate PR, but the updates to allow bx, by, bz field maps seems to work nicely.

@dhevang
Copy link
Contributor Author

dhevang commented Sep 21, 2023

@wdconinc , how often are DD4hep updates propagated to the eic-shell? The new dumpBfield is in their master branch as of yesterday.

@wdconinc
Copy link
Contributor

how often are DD4hep updates propagated to the eic-shell?

Normally we update when a new release comes out. I can (and often do) backport patches into eic-shell too (I backported AIDASoft/DD4hep#1161 just yesterday). That often requires that the PR has been merged (so it is stable). Is this about AIDASoft/DD4hep#1170? I can backport that too.

compact/far_backward/lumi/lumi_magnets.xml Outdated Show resolved Hide resolved
src/FieldMapB.cpp Outdated Show resolved Hide resolved
@dhevang
Copy link
Contributor Author

dhevang commented Sep 21, 2023

how often are DD4hep updates propagated to the eic-shell?

Normally we update when a new release comes out. I can (and often do) backport patches into eic-shell too (I backported AIDASoft/DD4hep#1161 just yesterday). That often requires that the PR has been merged (so it is stable). Is this about AIDASoft/DD4hep#1170? I can backport that too.

Yes

@wdconinc
Copy link
Contributor

DumpBField changes backported and merged into eic-shell. Should get to cvmfs in the next 12 hours.

Attempt to streamline calls to fieldComponents.
src/FieldMapB.cpp Outdated Show resolved Hide resolved
dhevang and others added 17 commits October 9, 2023 15:53
Attempt to streamline calls to fieldComponents.
Multiply by tesla units once when the field is loaded.
Remove unnecessary intermediate variable, B_interpolated.
Go back to using std::modf, with transient floats.
@dhevang
Copy link
Contributor Author

dhevang commented Oct 12, 2023

Are there any other optimizations needed for this PR? @ajentsch did some checks using some new field maps in the B0 region, using the new BxByBz option. Things looked good from his perspective.

Copy link
Member

@veprbl veprbl left a comment

Choose a reason for hiding this comment

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

ddsim performance for single electron

main:

        User time (seconds): 8500.01
        System time (seconds): 4.50
        Percent of CPU this job got: 99%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 2:21:45
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 1963884

this branch:

        User time (seconds): 8381.21
        System time (seconds): 4.38
        Percent of CPU this job got: 99%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 2:19:47
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 1952888

capybara report for reco outputs: https://veprbl.github.io/capybara-reports/f9794437ad70f939c89b642899035e99/

@veprbl
Copy link
Member

veprbl commented Oct 17, 2023

@kkauder feel free to remove from queue if you are going to look into this

Merged via the queue into main with commit 737f84f Oct 17, 2023
85 checks passed
@veprbl veprbl deleted the Insert_LumiPS_B_FieldMap branch October 17, 2023 21:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging this pull request may close these issues.

5 participants