New analysis code (from K.C.W. Li PhD thesis). PR193 analysis run through.

[KevinCWLi]

This is an in-depth tutorial/run-through of the new analysis code (with accompanying external codes for cable offsets, lineshape corrections, peak-position mapping and even momentum calibration... basically almost every step) that was used for the analyses in the PhD thesis of K.C.W. Li.

This will not only assist the analysis of PR193 specifically, but will also act as a general instruction for the method. It will additionally serve as a sounding board for improvements to be made in the future.

[KevinCWLi]

The simplified PR193 analysis procedure is described below. This will also serve as a somewhat in-depth tutorial into how things have been done for all the analyses for my theses. This will prove useful for the integration of the improvements into the main analyses.

Note: after speaking to Phil, I just wanted to make clear that the SBR algorithm was only written to improve upon the old algorithm, not replace. You simply don't need that precision for all the wireplanes, that is why it is only implemented for the X1 wireplane.

==================================== NOTE: The flow diagram of the general procedure is attached. In principle, most arrows between blocks are a re-sort of the data (excpet between "Focal plane positions:..." and "Lineshape corrections". Some steps could be combined. In fact, TotalLineshapeCorrection (TLC) has some abilities to do the peak-position mapping straight after without having to re-sort but I've separated the codes to make things clearer and then you are 100% sure that you are doing the peak-position mapping on what you actually get out after the TLC.

DETAILS FOR EACH STEP

============================ STEP 1. PID Calibration This needs to be done (especially for inelastic scattering) since you need a simple gate for the particles of interest for the later codes.

Re-sort (do not define "_SILVERBULLETRAYTRACE" yet. Not yet needed and saves time)

============================ STEP 2. Generate Cable Offsets There is an improved "AutoTrim.C" code for this (the old offsets code works but this should be an improvement for when there are wires with different characteristics "tails" in the drift times... which they often are).

Re-sort

============================ STEP 3. Generate lookup tables (LUTs) Usual method.

Re-sort (the preprocessor variable "_SILVERBULLETRAYTRACE" must now be defined. It did not before.)

============================ STEP 4. Focal-plane positions: X1pos, Y1pos... Ancillary parameters: theta_SCAT, theta_RT (raytrace angle)...

NO RESORT BETWEEN THESE STEPS

============================ STEP 5. Lineshape corrections TotalLineshapeCorrection.cpp code

Re-sort

============================ STEP 6. Peak-position mapping There is a new code for this. For PR193, this should be nice and easy because of the well-defined peaks. (The more I think about it, PR193 is a great test case for the team, in this case Retief, to go through the process)

Re-sort

============================ STEP 7. Momentum calibration Of course, you can simply do the regular momentum calibration, however there is a more advanced code to take into account the tails for target-related energy loss. This is very important for cases where the width of the energy loss tail is of the order of the intrinsic width of the state/resonance.

[KevinCWLi]

I realise now that the instructions I made for these extra codes (take a look in the implementation files) were actually very extensive when I originally wrote them. They shall hopefully help.

PR193AnalysisPackage.zip

[padsley]

If these are separate codes from the K600 analyser then I figure that we make a new repo for "K600AnalysisScripts" or something like that. Then we can keep them separate from the main analyser. That might be organisationally easier.

[pellegri]

Yes I agree with this idea!

L

---

Dr Luna Pellegri University of the Witwatersrand and iThemba LABS iThemba LABS, P.O. Box 722, Somerset West, 7129, South Africa +27 (0)21 8431136 (Work Phone) +27 (0)71 3204629 (SA Mobile)

---

On 27 Mar 2020, at 11:04, Philip Adsley notifications@github.com wrote:

If these are separate codes from the K600 analyser then I figure that we make a new repo for "K600AnalysisScripts" or something like that. Then we can keep them separate from the main analyser. That might be organisationally easier.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/padsley/k600analyser/issues/176#issuecomment-604891776, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACQDVFLV5DEWDX2KSOIFOA3RJRTZJANCNFSM4LU2ME5A.

[padsley]

Also, we need a name for the new raytracing algorithm which will be easy for others to understand. The name at the moment is arbitrary and I would prefer it to be given a name which is, to some extent, self-documenting. This means that "New RT Algorithm" or "Kevin's RT Algorithm" are not good names (see also the "new" vs "old" VDCs which make sense to K600 users now but not to anyone else - we should say "X" and "XU" VDCs). It need to be something which the next but two PhD student will be able to understand easily.

I propose something like "FixWandZEventsRTA" <- i.e. the RT algorithm that fixes W and Z events (also the angle stuff, I guess...)

Anyone have other offiers?

[KevinCWLi]

The separate repo makes sense, I placed them in a comment just for the sake of Retief for now. Everything is still somewhat developmental. Will move to copy now.

The name is currently SilverBulletRaytrace. It could be called ComprehensiveRaytrace, which is what it does since it explores all the permutations and actually keeps a ton of information for every wireplane event.

I propose that we first get everything to work for Retief. Renaming etc. is simple and can be done later, the priority is to get it to work for him so that this analysis can go through otherwise it will take very long and time is an issue.

[padsley]

I'm sold on "Comprehensive". Going, going waves gavel

Dr Philip Adsley MA MSci (Cantab) Claude Leon Postdoctoral Fellow University of the Witwatersrand/iThemba LABS

On Fri, 27 Mar 2020 at 11:20, Kevin Ching Wei Li notifications@github.com wrote:

The separate repo makes sense, I placed them in a comment just for the sake of Retief for now. Everything is still somewhat developmental. Will move to copy now.

The name is currently SilverBulletRaytrace. It could be called ComprehensiveRaytrace, which is what it does since it explores all the permutations and actually keeps a ton of information for every wireplane event.

I propose that we first get everything to work for Retief. Renaming etc. is simple and can be done later, the priority is to get it to work for him so that this analysis can go through otherwise it will take very long and time is an issue.

On 27 Mar 2020, at 11:10 AM, Philip Adsley <notifications@github.com mailto:notifications@github.com> wrote:

CAUTION: This email originated from outside of the University. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Also, we need a name for the new raytracing algorithm which will be easy for others to understand. The name at the moment is arbitrary and I would prefer it to be given a name which is, to some extent, self-documenting. This means that "New RT Algorithm" or "Kevin's RT Algorithm" is not a good name (see also the "new" vs "old" VDCs which make sense to K600 users now but not to anyone else - we should say "X" and "XU" VDCs). It need to be something which the next but two PhD student will be able to understand easily.

I propose something like "FixWandZEventsRTA" <- i.e. the RT algorithm that fixes W and Z events (also the angle stuff, I guess...)

Anyone have other offiers?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub< https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpadsley%2Fk600analyser%2Fissues%2F176%23issuecomment-604894153&data=02%7C01%7C%7C4e3ccc9e5c50445fcf9508d7d22eb42f%7Ca6fa3b030a3c42588433a120dffcd348%7C0%7C0%7C637208970458072004&sdata=3gy7iBda4yrdOSimMH%2FARByYwfpclbEW3kihkicp6j4%3D&reserved=0>, or unsubscribe< https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACNZIYKKRRASUFQFPY4JUO3RJRUQPANCNFSM4LU2ME5A&data=02%7C01%7C%7C4e3ccc9e5c50445fcf9508d7d22eb42f%7Ca6fa3b030a3c42588433a120dffcd348%7C0%7C0%7C637208970458081999&sdata=a76rAa%2FQQ2NB%2F3JH6%2FlVSSXpGRQoiRM6ir8wtT5YPEo%3D&reserved=0>.

[https://cdn.sun.ac.za/100/ProductionFooter.jpg]< https://www.sun.ac.za/english/about-us/strategic-documents>

The integrity and confidentiality of this email are governed by these terms. Disclaimerhttps://www.sun.ac.za/emaildisclaimer Die integriteit en vertroulikheid van hierdie e-pos word deur die volgende bepalings bereël. Vrywaringsklousulehttps://www.sun.ac.za/emaildisclaimer

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/padsley/k600analyser/issues/176#issuecomment-604898255, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB54VOCI444P4PR5RO6HNUTRJRVU3ANCNFSM4LU2ME5A .

[pellegri]

Please I don’t know how to spell it. Can we use a easier work? ahahh

L

---

Dr Luna Pellegri University of the Witwatersrand and iThemba LABS iThemba LABS, P.O. Box 722, Somerset West, 7129, South Africa +27 (0)21 8431136 (Work Phone) +27 (0)71 3204629 (SA Mobile)

---

On 27 Mar 2020, at 11:21, Philip Adsley notifications@github.com wrote:

I'm sold on "Comprehensive". Going, going waves gavel

Dr Philip Adsley MA MSci (Cantab) Claude Leon Postdoctoral Fellow University of the Witwatersrand/iThemba LABS

On Fri, 27 Mar 2020 at 11:20, Kevin Ching Wei Li notifications@github.com wrote:

The separate repo makes sense, I placed them in a comment just for the sake of Retief for now. Everything is still somewhat developmental. Will move to copy now.

The name is currently SilverBulletRaytrace. It could be called ComprehensiveRaytrace, which is what it does since it explores all the permutations and actually keeps a ton of information for every wireplane event.

I propose that we first get everything to work for Retief. Renaming etc. is simple and can be done later, the priority is to get it to work for him so that this analysis can go through otherwise it will take very long and time is an issue.

On 27 Mar 2020, at 11:10 AM, Philip Adsley <notifications@github.com mailto:notifications@github.com> wrote:

CAUTION: This email originated from outside of the University. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Also, we need a name for the new raytracing algorithm which will be easy for others to understand. The name at the moment is arbitrary and I would prefer it to be given a name which is, to some extent, self-documenting. This means that "New RT Algorithm" or "Kevin's RT Algorithm" is not a good name (see also the "new" vs "old" VDCs which make sense to K600 users now but not to anyone else - we should say "X" and "XU" VDCs). It need to be something which the next but two PhD student will be able to understand easily.

I propose something like "FixWandZEventsRTA" <- i.e. the RT algorithm that fixes W and Z events (also the angle stuff, I guess...)

Anyone have other offiers?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub< https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpadsley%2Fk600analyser%2Fissues%2F176%23issuecomment-604894153&data=02%7C01%7C%7C4e3ccc9e5c50445fcf9508d7d22eb42f%7Ca6fa3b030a3c42588433a120dffcd348%7C0%7C0%7C637208970458072004&sdata=3gy7iBda4yrdOSimMH%2FARByYwfpclbEW3kihkicp6j4%3D&reserved=0>, or unsubscribe< https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACNZIYKKRRASUFQFPY4JUO3RJRUQPANCNFSM4LU2ME5A&data=02%7C01%7C%7C4e3ccc9e5c50445fcf9508d7d22eb42f%7Ca6fa3b030a3c42588433a120dffcd348%7C0%7C0%7C637208970458081999&sdata=a76rAa%2FQQ2NB%2F3JH6%2FlVSSXpGRQoiRM6ir8wtT5YPEo%3D&reserved=0>.

[https://cdn.sun.ac.za/100/ProductionFooter.jpg]< https://www.sun.ac.za/english/about-us/strategic-documents>

The integrity and confidentiality of this email are governed by these terms. Disclaimerhttps://www.sun.ac.za/emaildisclaimer Die integriteit en vertroulikheid van hierdie e-pos word deur die volgende bepalings bereël. Vrywaringsklousulehttps://www.sun.ac.za/emaildisclaimer

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/padsley/k600analyser/issues/176#issuecomment-604898255, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB54VOCI444P4PR5RO6HNUTRJRVU3ANCNFSM4LU2ME5A .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/padsley/k600analyser/issues/176#issuecomment-604898952, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACQDVFPQ32YI7HORYRCWMPDRJRV3JANCNFSM4LU2ME5A.

[KevinCWLi]

Uh.... maybe we can use "FullRaytrace"... although "ComprehensiveRaytrace" does describe it more... comprehensively :) GigaRaytrace is also possible. We can have a vote for these things, nothing is final until Retief takes a look through and sees what he likes/dislikes. It is going to be a good test case and he's probably the most appropriate person to do the run through.

[neveling]

You want it to be clear that its not the normal algorithm (it makes too many calculations) and really only something to be done once everything else is fixed. Otherwise someone that comes along may want to use it for all the wireplanes, and then get bogged down in very very slow analysis.

I foresee that one will do all the normal optimizations for lineshape and lut etc etc and only once all of that is good and tested with the basic raytrace algorithm, only then do you spend the time going with only X1 through this comprehensive raytrace code.

So, how to get that into the name?

In essence the thing it does differently is deciding which wires are to be used in the raytracing. So if you want that to go into the name then:

raytrace_test_all_wirepermutations

Its not nice and catchy, but accurate.

[KevinCWLi]

A brief explanation for the output of the TLC and PeakPositionMapping codes. Each code produces a .dat file and this shows the format of the information within.

================================================ TLC

1 0 2 9 -0.0979532 -2.76061 10.2616 5.0384 -17.2524 -2.85395 7.87251 0.490164 -1.08053 9 1.00014 0.0040741 -0.0148134 -0.00703868 0.0247706 0.00398886 -0.0112717 -0.000686274 0.00154422

1: One lineshape correction, 0: theta_SCAT correction 2: Two coefficients, 9: First coefficient has nine polynomial parameters (nine parameters follow), 9: Second coefficient has nine polynomial parameters (nine parameters follow).

Now it should be noted, that for the actual TLC input parameters into the analysis (see branch PR194 as an example), you need to place two run numbers in front of each TLC solution. These run numbers designate the run-number range that this specific TLC correction will be used for. So in the file, you will see something like

1090 1157 1 0 2 9 -0.0979532 -2.76061 10.2616 5.0384 -17.2524 -2.85395 7.87251 0.490164 -1.08053 9 1.00014 0.0040741 -0.0148134 -0.00703868 0.0247706 0.00398886 -0.0112717 -0.000686274 0.00154422 1160 1180 1 0 2 9 -0.0979532 -2.76061 10.2616 5.0384 -17.2524 -2.85395 7.87251 0.490164 -1.08053 9 1.00014 0.0040741 -0.0148134 -0.00703868 0.0247706 0.00398886 -0.0112717 -0.000686274 0.00154422

Where the first corrections are used for runs 1090 to 1157 and the second set (just a copy for an example) is for runs 1160 to 1180. It is implemented this way because the TLC is complex and sometimes requires very different solutions for different runs (if the beam cuts off and must be re-focused etc.)

================================================ PeakPositionMapping

1114 3 16.8236 0.945773 4.3189e-05

1114: run number 3: Number of polynomial parameters to follow (followed by three parameters).

[KevinCWLi]

Hey Retief

I completely agree, I spoke to Phil the other day and mentioned that the intention of SBR was never to replace the existing raytracing, only to improve. You simply don't need the precision for anything else other than the X1 wireplane. Right now, it is already done in parallel and is only implemented for the X1 wireplane. You need an SBR object for each wireplane and there is only one for X1. This is currently done for with a preprocessor directive.

I'm up for a different name, I thought about comprehensive because it's more than just testing all permutations. There is a whole set of vectors that come with each SBR event instead of a single position so you can do everything offline post sort. So for every position, you have your associated raytrace angles, number of wires used/skipped, adjustedRsquared metric etc. Each (X1) wireplane event no longer just produces a X1pos double, but a whole SBR class object. It's kind of like the MMMs... it's basically another detector class in structure.