Problems with kinematic fitter in Lambda events?

[sdobbs]

Hao Li reported issues in the MC with the P4+Vertex kinematic fit sculpting his acceptance for certain kinematics for p+Lambda+anti-Lambda events. Mike McCracken also reported that he has seen an effect for Lambda+K+ events.

See the email thread here: https://groups.google.com/d/msg/gluex-software/lBh4R6B0j68/B8P6o_6sCAAJ

Hao has pulled out a couple useful problem events, see, e.g.:

What is shown in the tables above, are the number of combos with certain type of kinfit result. There are three possibilities: converged with final ChiSq calculated; dS not invertible hence failed; Exceeded max number of iterations hence failed. For the MC data generated by mechanism 2 (second table), it seems that more than 60% of the combos failed due to "dS not invertible" , which is much higher than mechanism 1. And I can confirm that by looking at the corresponding pi- Lab polar angle, most of the combos failed kinfit due to "dS not invertible" have pi- Lab polar angle right in the gap as I pointed out in the first email. It seems that those combos with singular matrices have some repeated constraints for some reason, but I am not clear on how to dig deeper..

mechanism1 (lamlambarG1_0001_rest.hddm)
with P4 fit:                          /work/halld/haoli/MC_simulation/lambantilamb/test/log_lamlambarG1_0001__F1_B3_COMBODEBUGLEVEL20_KINFITDEBUGLEVEL20.txt
with VertexandP4 fit:          /work/halld/haoli/MC_simulation/lambantilamb/test/log_lamlambarG1_0001__B3_COMBODEBUGLEVEL20_KINFITDEBUGLEVEL20.txt
mechanism2 (lamlambarG2_0001_rest.hddm)
with P4 fit:                          /work/halld/haoli/MC_simulation/lambantilamb/test/log_lamlambarG2_0001__F1_B3_COMBODEBUGLEVEL20_KINFITDEBUGLEVEL20.txt
with VertexandP4 fit:          /work/halld/haoli/MC_simulation/lambantilamb/test/log_lamlambarG2_0001__B3_COMBODEBUGLEVEL20_KINFITDEBUGLEVEL20.txt

[sdobbs]

I simulated some of Hao's events for "mechanism2" with the latest sim/recon code. /w/halld-scifs17exp/home/sdobbs/lamlambar/hdgeant_smeared.hddm and dana_rest_v2.hddm

A lot of the nan's Beni reported are not there.

What seems to be driving some of the ones that are left is the following: I tracked their source down to DAnalysisUtilities::Calc_PathLength_FineGrained(). Apparently sometimes the given magnetic field is zero. This makes "locA" zero, which screws up the calculation, and yields nan's

One useful event: 234 (I think)

Any thoughts, @staylorjlab ? I could put in a version that handles the zero B-field case, but it's not clear to me if this should even be happening....

[staylorjlab]

What plugin did you use that triggers this behavior?

----- Original Message ----- From: "Sean Dobbs" notifications@github.com To: "JeffersonLab/halld_recon" halld_recon@noreply.github.com Cc: "staylorjlab" staylor@jlab.org, "Mention" mention@noreply.github.com Sent: Sunday, October 21, 2018 10:49:37 PM Subject: Re: [JeffersonLab/halld_recon] Problems with kinematic fitter in Lambda events? (#39)

I simulated some of Hao's events for "mechanism2" with the latest sim/recon code. /w/halld-scifs17exp/home/sdobbs/lamlambar/hdgeant_smeared.hddm and dana_rest_v2.hddm

A lot of the nan's Beni reported are not there.

What seems to be driving some of the ones that are left is the following: I tracked their source down to DAnalysisUtilities::Calc_PathLength_FineGrained(). Apparently sometimes the given magnetic field is zero. This makes "locA" zero, which screws up the calculation, and yields nan's

One useful event: 234 (I think)

Any thoughts, @staylorjlab ? I could put in a version that handles the zero B-field case, but it's not clear to me if this should even be happening....

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_halld-5Frecon_issues_39-23issuecomment-2D431728984&d=DwICaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=RgVWzOo5vEGwTw93BfU_Og&m=UyCLSilu3Uk0hW0rkXmxoQSLpMEFGDvBDz1x8a5ep9c&s=ymsg55kXEbcKLoxVzCFY1hS76cobV05_yBFlb-C-OUI&e=

[sdobbs]

Just ReactionFilter, the command line is below.

hd_root -PPLUGINS=ReactionFilter -PReaction1=1_14__18_26_14 -PCOMBO:DEBUG_LEVEL=20 dana_rest.hddm On Mon, Oct 22, 2018 at 7:06 AM staylorjlab notifications@github.com wrote:

What plugin did you use that triggers this behavior?

----- Original Message ----- From: "Sean Dobbs" notifications@github.com To: "JeffersonLab/halld_recon" halld_recon@noreply.github.com Cc: "staylorjlab" staylor@jlab.org, "Mention" < mention@noreply.github.com> Sent: Sunday, October 21, 2018 10:49:37 PM Subject: Re: [JeffersonLab/halld_recon] Problems with kinematic fitter in Lambda events? (#39)

I simulated some of Hao's events for "mechanism2" with the latest sim/recon code. /w/halld-scifs17exp/home/sdobbs/lamlambar/hdgeant_smeared.hddm and dana_rest_v2.hddm

A lot of the nan's Beni reported are not there.

What seems to be driving some of the ones that are left is the following: I tracked their source down to DAnalysisUtilities::Calc_PathLength_FineGrained(). Apparently sometimes the given magnetic field is zero. This makes "locA" zero, which screws up the calculation, and yields nan's

One useful event: 234 (I think)

Any thoughts, @staylorjlab ? I could put in a version that handles the zero B-field case, but it's not clear to me if this should even be happening....

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub:

https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_halld-5Frecon_issues_39-23issuecomment-2D431728984&d=DwICaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=RgVWzOo5vEGwTw93BfU_Og&m=UyCLSilu3Uk0hW0rkXmxoQSLpMEFGDvBDz1x8a5ep9c&s=ymsg55kXEbcKLoxVzCFY1hS76cobV05_yBFlb-C-OUI&e=

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/JeffersonLab/halld_recon/issues/39#issuecomment-431898952, or mute the thread https://github.com/notifications/unsubscribe-auth/ABIJagZJKAYm2aJ6N1VcxJTVZlfTfkg0ks5unfsJgaJpZM4Xh6DX .

[zihlmann]

Hi Sean, I print out locA when it is very small <10⁻16 where indeed the B field is zero! However it is zero because the location where it is asked  does not make much sense as you can see below:

VERY SMALL locA -0  q=1  B=0 location at x/y/z = -42.1901/39.2123/-188.628

   | This is a REST event stream...ents read)  666.0Hz  (avg.: 450.0Hz)

VERY SMALL locA -0  q=1  B=0 location at x/y/z = 157.733/47.7778/-389.865

  924.0 events processed  (933.0 events read)  496.0Hz  (avg.: 461.5Hz) VERY SMALL locA -0  q=1  B=0 location at x/y/z = 114.25/-301.422/77.6098

VERY SMALL locA -0  q=1  B=0 location at x/y/z = 140.233/-3.23478/-199.278

  1242.0 events processed  (1242.0 events read)  636.0Hz  (avg.: 496.4Hz) VERY SMALL locA -0  q=1  B=0 location at x/y/z = 1301.34/-1318.1/489.655

  1.5k events processed  (1.5k events read)  522.0Hz  (avg.: 500.7Hz) VERY SMALL locA -0  q=1  B=0 location at x/y/z = 343.888/-493.238/819.27

  2.2k events processed  (2.2k events read)  532.0Hz  (avg.: 540.0Hz) VERY SMALL locA -0  q=1  B=0 location at x/y/z = 15.9515/-6.1161/-138.697

  2.5k events processed  (2.5k events read)  620.0Hz  (avg.: 548.9Hz) VERY SMALL locA -0  q=1  B=0 location at x/y/z = -91.4581/22.7542/1480.51

VERY SMALL locA -0  q=1  B=0 location at x/y/z = -39.6391/-125.014/829.975

  2.8k events processed  (2.8k events read)  582.0Hz  (avg.: 552.2Hz) VERY SMALL locA -0  q=1  B=0 location at x/y/z = -262.585/-297.678/706.884

VERY SMALL locA 0  q=-1  B=0 location at x/y/z = -8.44803/-15.8772/-104.823

  3.1k events processed  (3.1k events read)  586.0Hz  (avg.: 555.3Hz) VERY SMALL locA 0  q=-1  B=0 location at x/y/z = -30.5933/-36.3585/-186.413

  4.0k events processed  (4.0k events read)  556.0Hz  (avg.: 572.4Hz) VERY SMALL locA -0  q=1  B=0 location at x/y/z = -14.8499/6.79841/-113.279

  4.3k events processed  (4.3k events read)  568.0Hz  (avg.: 572.1Hz) VERY SMALL locA 0  q=-1  B=0 location at x/y/z = 1940.16/-1021.35/428.896

VERY SMALL locA -0  q=1  B=0 location at x/y/z = 970.082/-510.674/428.896

  4.6k events processed  (4.6k events read)  566.0Hz  (avg.: 571.8Hz) VERY SMALL locA -0  q=1  B=0 location at x/y/z = -19216.8/12462.6/-6057.23

VERY SMALL locA -0  q=1  B=0 location at x/y/z = -19138.3/6523.02/-895.939

VERY SMALL locA 0  q=-1  B=0 location at x/y/z = -19273/6300.49/-1196.39

  4.9k events processed  (4.9k events read)  560.0Hz  (avg.: 571.1Hz) VERY SMALL locA 0  q=-1  B=0 location at x/y/z = 169.35/327.831/1357.93

VERY SMALL locA 0  q=-1  B=0 location at x/y/z = 71.6456/130.79/645.385

  5.2k events processed  (5.2k events read)  620.0Hz  (avg.: 573.8Hz) VERY SMALL locA -0  q=1  B=0 location at x/y/z = 66568.2/21500.7/24968.6

JANA >>events processed  (5.7k events read)  640.0Hz  (avg.: 574.0Hz) JANA >>No more event sources JANA >>Thread 0x7f6765b27700 completed gracefully: Mon Oct 22 14:38:49 2018 JANA >>Merging thread 0 (0x7f6765b27700) ... JANA >>Merging event reader thread ... JANA >> 5808 events processed  (5808 events read) Average rate: 553.0Hz

Closed ROOT file

On 10/22/18 1:20 PM, Sean Dobbs wrote:

Just ReactionFilter, the command line is below.

hd_root -PPLUGINS=ReactionFilter -PReaction1=1_14__18_26_14 -PCOMBO:DEBUG_LEVEL=20 dana_rest.hddm On Mon, Oct 22, 2018 at 7:06 AM staylorjlab notifications@github.com wrote:

What plugin did you use that triggers this behavior?

----- Original Message ----- From: "Sean Dobbs" notifications@github.com To: "JeffersonLab/halld_recon" halld_recon@noreply.github.com Cc: "staylorjlab" staylor@jlab.org, "Mention" < mention@noreply.github.com> Sent: Sunday, October 21, 2018 10:49:37 PM Subject: Re: [JeffersonLab/halld_recon] Problems with kinematic fitter in Lambda events? (#39)

I simulated some of Hao's events for "mechanism2" with the latest sim/recon code. /w/halld-scifs17exp/home/sdobbs/lamlambar/hdgeant_smeared.hddm and dana_rest_v2.hddm

A lot of the nan's Beni reported are not there.

What seems to be driving some of the ones that are left is the following: I tracked their source down to DAnalysisUtilities::Calc_PathLength_FineGrained(). Apparently sometimes the given magnetic field is zero. This makes "locA" zero, which screws up the calculation, and yields nan's

One useful event: 234 (I think)

Any thoughts, @staylorjlab ? I could put in a version that handles the zero B-field case, but it's not clear to me if this should even be happening....

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub:

https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_halld-5Frecon_issues_39-23issuecomment-2D431728984&d=DwICaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=RgVWzOo5vEGwTw93BfU_Og&m=UyCLSilu3Uk0hW0rkXmxoQSLpMEFGDvBDz1x8a5ep9c&s=ymsg55kXEbcKLoxVzCFY1hS76cobV05_yBFlb-C-OUI&e=

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub

https://github.com/JeffersonLab/halld_recon/issues/39#issuecomment-431898952, or mute the thread

https://github.com/notifications/unsubscribe-auth/ABIJagZJKAYm2aJ6N1VcxJTVZlfTfkg0ks5unfsJgaJpZM4Xh6DX .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_halld-5Frecon_issues_39-23issuecomment-2D431903439&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=o4lft6oWsUt3fPjSD1CFMTzi5N-H01oqTJ5vLjRalTE&m=vlFZLeC6hWxxoY7WemXugyCH2xHiDoisO2j070N8kUs&s=zsj8m8qiX1pUuDpHBeH-q_Ae8YTk8bopqxjI0apdgzs&e=, or mute the thread https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AMvwC7Ztup7yGjm9lclVqMlphovNZ3yMks5unf5GgaJpZM4Xh6DX&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=o4lft6oWsUt3fPjSD1CFMTzi5N-H01oqTJ5vLjRalTE&m=vlFZLeC6hWxxoY7WemXugyCH2xHiDoisO2j070N8kUs&s=wVmCTBUB3eOwAiLV2KF4ih-k57mRpbbZprkzsQxReBI&e=.

[sdobbs]

@zihlmann Yeah, I think the problem may be in DAnalysisUtilities::Calc_PathLength_Step()

One example:

Vertex before Calc_PathLength_Step(): (x,y,z,t)=(0.216269,-0.337719,61.601967,0.499354) Vertex after Calc_PathLength_Step(): (x,y,z)=(79.926851,8.955759,0.000000)

[T-Britton]

98% of the time that function is called it returns 0. This means the point is already “close enough” and the while loop never triggers. It turns out that 2/3 of the nans come from crazy initial (and sometimes final) positions. I mean X,Y of thousands. Of course the Bfield isn’t defined and the nans pop up. The other 4 cases seem to be z values of just beyond -100 and thus the Bfield is again not found

[sdobbs]

So who wants to see how often this happens in data as opposed to just simulation :smile: On Tue, Oct 23, 2018 at 12:53 PM T-Britton notifications@github.com wrote:

98% of the time that function is called it returns 0. This means the point is already “close enough” and the while loop never triggers. It turns out that 2/3 of the nans come from crazy initial (and sometimes final) positions. I mean X,Y of thousands. Of course the Bfield isn’t defined and the nans pop up. The other 4 cases seem to be z values of just beyond -100 and thus the Bfield is again not found

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/JeffersonLab/halld_recon/issues/39#issuecomment-432450348, or mute the thread https://github.com/notifications/unsubscribe-auth/ABIJai8qrYD8PV89DXS4DS9jozHfqQkVks5un54EgaJpZM4Xh6DX .

[sdobbs]

More information from Hao, presented at the Oct. 30, 2018 Software Meeting

[sdobbs]

I looked into this some more, and it looks like almost all the existing problems in the DAnalysisUtilities library are either due to (1) track vertices being in some crazy place [e.g. z<0, or somewhere else where the B-Field is not defined; (2) decay vertices in some crazy place - usually these are secondary vertices.

So, there are two obvious ways we could handle this: 1) Make some fiducial cut and reject tracks/vertices outside of the magnetic field region. [clearly these will be rejected at the analysis level anyway] 2) Enhance these track projection functions to handle these far-out positions

Is there some way we can find out over which volume the magnetic field is defined?

[sdobbs]

From discussion at the Offline meeting yesterday: for Hao's tuning, we're waiting on the analysis launch results. I'll spin the other problem off into its own issue.

[markito3]

Thanks Sean. Spinning the NaN into its own issue is the rational thing to do.

[lihaoahil]

Some update from March 27, 2019, Analysis Working Group

[sdobbs]

This is resolved by PR #144