acts-project
2D r-z Magnetic Field Map Improperly Read
When sPHENIX runs Acts with a constant 1.4 T magnetic field, we get a reasonably good momentum resolution; when trying to run the same thing with our field map, the tracking resolution degrades significantly. We use essentially the same code as GeometryExampleBase lines 31-56 to build our geometry, with the following options:
-n1 -l0 --response-file sphenixResponse.response --mat-input-type file --mat-input-file materialFile --bf-map fieldMap.root --bf-name fieldmap --bf-lscalor 10 --bf-bscalor 9.3333e-05 --bf-rz true
The below plots show some tests of 20 pi+ 20 pi- events.
Running with a constant 1.4T field gives us the nominal momentum/phi/eta resolution seen here: constFieldEtaRes.pdf constFieldPhiRes.pdf constFieldpTRes.pdf
Note that the arguments to run this are as follows:
-n1 -l0 --response-file sphenixResponse.response --mat-input-type file --mat-input-file materialFile -bf-values 0 0 1.5 --bf-bscalor 0.9333333
Running with the same code but with the field map gives the degraded resolution seen here, which seems to be correlated with a phi offset that is charge dependent: fieldMapEtaRes.pdf fieldMapPhiRes.pdf fieldMappTRes.pdf
The phi separation indicates that there must be some charge dependent way the field is being interpreted incorrectly, I suspect. Note that I tried flipping the field sign for Acts (this leads to many failed track fits) and flipping the charge of the tracks going into the fitter (Acts just sees the tracks as the opposite sign but is still able to fit them) so it seems like Acts is interpreting the direction of the field correctly.
The obvious first step to try to do this is to see if it can be reproduced in the Acts only framework, outside of sPHENIX using our response/material/field map files. These are attached here, in addition to the sPHENIX geometry in Root and GDML format:
I will see if I can do that with the default Acts executables.
Thanks @osbornjd - is there any chance you can fill the MagneticField into xyz map? We have done quite some tests with the ATLAS based solenoid, but that's in xyz, so I wonder if the interpolation in r/phi is probably off?
@asalzburger So that this is documented with this issue, here's a summary of my test and current problem so far.
To create the XYZ field, I take our 2D rz field map and use the sPHENIX field converting module (that is used to feed the field into GEANT) to create a new tree in xyz coordinates. The field converting module gets the (Bx,By,Bz) from an arbitrary (x,y,z) space point. I loop over the entries of the rz tree and pick a phi value to determine the xyz points from (r,phi,z). Then I calculate the xyz and Bx,By,Bz values, write them out to a tree, and feed them into Acts. To test that Acts is working properly, I'm using the ActsExampleMagneticField executable.
I have found some behavior that I don't understand. If I pick phi to be anything other than 0, I get a std::out_of_range error here. This occurs because the index number returned by the localToGlobalBin functor is larger than the number of entries in the bField vector. Originally, I tried creating the tree with 10 points in phi to give a more uniform 3D coverage of the map, but this seg fault came up. I then tried creating the tree with 1 point with arbitrary phi, and this comes up. The only case where bField.size()==sPHENIXrzTree.size() is when I make the xyz tree with phi = 0. When I make the tree with e.g. phi==0.1, the created tree still has sPHENIXxyzTree.size()==sPHENIXrzTree.size(), so I guess I don't understand how to interpret the binning scheme given by the localToGlobalBin functor and how to create a tree that obeys that scheme since the only way I can get the bField.size() to be the same as the xyz tree size is if I calculate the xyz BxByBz values at phi=0.
If I change the relevant section in BFieldMapUtils.cpp to the following:
auto binNo = localToGlobalBin({{i-1, j-1, k-1}}, nIndices);
if(binNo >= bField.size()) {
binNo = bField.size() - 1;
}
grid.atLocalBins(indices) = bField.at(binNo) * BFieldUnit;
Then I get a working tracking chain, contrary to the plots which I showed at the beginning of this issue. Although this "hack" is inherently wrong (since it is just setting some arbitrary bins that Acts is grabbing to the last B field value), I can get our code to run and I think this shows that there is some interpolation issue in the rphi mapper. The plots below show the pT, phi, and eta resolution of fully reconstructed tracks in the sPHENIX framework using the XYZ field map after adding in the "hack" shown in the code snippet above. Compare these to the "fieldMapRes" pdf images that were uploaded when this issue was created. One thing worth noting is that the track fitting efficiency drops by a factor of ~2 with this hack, so it isn't something we can just implement freely (probably because the fieldmap that Acts interprets is inherently wrong from the hack, but it is good enough on enough occasions that allows the test to proceed).
etaresXYZFieldMap.pdf phiresXYZFieldMap.pdf ptresXYZFieldMap.pdf
Maybe this is just an off by one error? The field grid uses the (IIRC) lower left bin edge as the grid point, maybe there was some confusion here.
This issue/PR has been automatically marked as stale because it has not had recent activity. The stale label will be removed if any interaction occurs.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
@plariono this might be the issue you see as well.
In my case it's different, I opened another issue for this: https://github.com/acts-project/acts/issues/1070
This issue/PR has been automatically marked as stale because it has not had recent activity. The stale label will be removed if any interaction occurs.
Moving the discussion from PR #1251 here:
This looks like the same issue. We don't see such a bad effect for the ATLAS B-field as sPHENIX do, but they are both binning issues in
fieldMapXYZ.
@paulgessinger commented:
This looks to me like an off-by-one error due to the fact that we're using the lower left corner of the grid cells as the interpolation points.
This looks to me like an off-by-one error due to the fact that we're using the lower left corner of the grid cells as the interpolation points.
Yes, that was my thought. I can try to take a closer (inexpert) look, when I have a moment.
Shouldn't that be relatively easily addressed by an appropriate UnitTest?
This issue/PR has been automatically marked as stale because it has not had recent activity. The stale label will be removed if any interaction occurs.
This issue/PR has been automatically marked as stale because it has not had recent activity. The stale label will be removed if any interaction occurs.
As discussed in the developers meeting: @osbornjd: This issue has probably been solved by the PR above. We We also moved to 3D maps. Let's find reasons to keep it open until next week, otherwise close this issue.
