Hello Matt,
I couldn't find that line anywhere when I run the code (does it only output
for readout? recon?), but I did put in a print statement in the "
detectorChanged(Detector)" method when I run my analysis. It outputs the
values for "Detector.getFieldMap().getField(*new double*[] { 0, y, 0 })",
where I vary the value of y from y = 0 to y = 1400 in steps of 25. It
gives the following values:
(0, 0, 0) >> ( -0.000, -0.431, -0.159)
(0, 25, 0) >> ( -0.000, -0.431, -0.159)
(0, 50, 0) >> ( -0.000, -0.431, -0.159)
Everything thereafter is entirely 0. I'm not sure what units the argument
vector expects, so I'm not sure whether this is reasonable or not. I can
also check the log you suggested if you can direct me on where to find it.
Thanks,
Kyle
On Tue, Jul 3, 2018 at 9:15 AM, Graham, Mathew Thomas <
[log in to unmask]> wrote:
> Do you know what the value of the B-field is set to in the track finding
> code? There should be a line in the log files from this line of code (only
> By matters):
>
> LOGGER.config("fieldInTracker: Bx = " + fieldInTracker.x() + "; By = " +
> fieldInTracker.y() + "; Bz = " + fieldInTracker.z());
>
>
> On Jul 3, 2018, at 12:39 AM, Kyle McCarty <[log in to unmask]> wrote:
>
> Hello hps-software,
>
> While performing hodoscope studies, Rafo and and I have stumbled on some
> odd output when attempting to obtain track momenta. I'm not sure if this is
> an issue with what I'm doing to obtain it, or if it's something odd
> happening with the momentum calculations. Note that this is done on the
> iss166 branch with the hodoscope detector, so it is also possible that
> something here is causing an issue. To see the issue, consider the
> momentum distribution for the initial MC particles for all events in the
> data set (pure tridents). We see the following:
>
> <MCParticleMomentum.png>
>
> This is reasonable for 2.3 GeV data. Now, consider the momentum of the
> observed tracks (using track state "0"):
>
> <ActualMomentum_X.png> <ActualMomentum_Y.png> <ActualMomentum_Z.png>
>
> We see that virtually all of the momentum is in the x-direction. This is
> reasonable - we expect most of the momentum to be in the direction of the
> beam line. However, we can see that the track momenta are dramatically
> lower than what we would expect, with almost nothing above 500 MeV.
>
> I checked to make sure this wasn't a field map issue, and verified that
> all steps in the process (SLIC, readout, and recon) used the correct field
> map (209acm2_5kg_corrected_unfolded_scaled_1.04545.dat), so this is not
> the issue. Rafo suggested manually calculating the momentum from the track
> parameters using the following method:
>
> final double aa = 3.e-4;
> final double B_PSpec = 0.5242301;
> final double a_Bz = aa*B_PSpec;
>
> double phi = track.getTrackStates().get(0).getPhi();
> double omega = track.getTrackStates().get(0).getOmega();
> double tanLambda = track.getTrackStates().get(0).
> getTanLambda();
>
> double magP = a_Bz / Math.abs(omega);
>
> double px = magP * Math.cos(phi);
> double py = magP * Math.sin(phi);
> double pz = magP * tanLambda;
>
> Using this method, we obtain a more reasonable total momentum distribution.
>
> <ActualMomentum_X_Fixed.png>
>
> This suggests to me that there might be something weird going on with the
> momentum calculation in HPS-Java (or at least this branch of it). Another
> sign that this may be the case can be observed by looking at the track
> state at the calorimeter. I obtain this with the following method suggested
> by Miriam:
>
> TrackUtils.getTrackStateAtECal(Track)
>
> When calling "Track.getMomentum()", I see two classes of outcome. One
> where the momentum is absurdly high, and one where it is absurdly low. Some
> examples from actual data are included below, with the format "EcalState(px,
> py, pz) << >> State0(px, py, pz)":
>
> ( 0.004, 0.001, -0.000) << >> (0.315, 0.007, -0.005)
>
>> ( 0.003, -0.001, -0.000) << >> (0.208, 0.011, -0.006)
> ( 0.004, 0.001, 0.000) << >> (0.285, 0.006, 0.006)
>
>>
>> (458.765, -133.711, 9.243) << >> (0.160, 0.005, 0.003)
>
>> (453.831, 149.604, - 9.234) << >> (0.174, 0.005, -0.003)
>
>> (447.438, 167.760, 11.122) << >> (0.149, 0.003, 0.004)
> (459.146, -132.398, -18.623) << >> (0.165, 0.004, -0.006)
>
> Clearly, something quite odd is going on, since it is completely
> unreasonable for a track to have the greater part of 500 GeV momentum in a
> 2.3 GeV beam. Likewise, I would not really expect us to see tracks with
> nearly no momentum at all. This suggests to me that the track state
> calculations for states other than "track state 0" (the target?) may be
> incorrect.
>
> I'm hoping someone more knowledgeable on the SVT side of things can give
> some insight into what is going on here, and correct me if I'm doing
> something wrong. Also, if there are any tests I can do or files that
> would be useful to have access to, let me know.
>
> Thanks,
>
> Kyle
>
> ------------------------------
>
> Use REPLY-ALL to reply to list
>
> To unsubscribe from the HPS-SOFTWARE list, click the following link:
> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
>
>
>
> ------------------------------
>
> Use REPLY-ALL to reply to list
>
> To unsubscribe from the HPS-SOFTWARE list, click the following link:
> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
>
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the HPS-SOFTWARE list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
