-
Notifications
You must be signed in to change notification settings - Fork 45
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
Conversation
@wdconinc , in your code, FieldMapBrBz.cpp, which I used as the basis for this extension, you had a coordinate transformation here: Line 152 in 19ec3f3
and then a B field transformation (trans) here: Line 182 in 19ec3f3
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. |
Do you mean to undo the little changes to the files compact/fields/beamline_*.xml? |
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. |
Ok, done. |
@ajentsch, would this implementation of the BxByBz field map work for your purposes in the B0? |
At first glance, it should. I will be able to test it tomorrow with my
field map and give you feedback. Sorry for the delay.
…On Wed, Sep 20, 2023, 5:20 PM Dhevan Gangadharan ***@***.***> wrote:
@ajentsch <https://github.com/ajentsch>, would this implementation of the
BxByBz field map work for your purposes in the B0?
—
Reply to this email directly, view it on GitHub
<#527 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADABSF5I3NIWI25BANHUCTLX3NM2VANCNFSM6AAAAAA45HDQVA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Thanks. you can use the dumpBfield program to print the field in your location of interest, and confirm that the mapping implementation worked. |
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 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.
@wdconinc , how often are DD4hep updates propagated to the eic-shell? The new dumpBfield is in their master branch as of yesterday. |
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 |
DumpBField changes backported and merged into eic-shell. Should get to cvmfs in the next 12 hours. |
Attempt to streamline calls to fieldComponents.
Go back to using std::modf, with transient floats.
Co-authored-by: Dmitry Kalinkin <[email protected]>
Implement lumi dipole B maps.
for more information, see https://pre-commit.ci
Attempt to streamline calls to fieldComponents.
for more information, see https://pre-commit.ci
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.
Co-authored-by: Dmitry Kalinkin <[email protected]>
…nsert_LumiPS_B_FieldMap
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. |
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.
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/
@kkauder feel free to remove from queue if you are going to look into this |
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?
Please check if this PR fulfills the following:
Does this PR introduce breaking changes? What changes might users need to make to their code?
Does this PR change default behavior?