Kinematics Curves

[rbraid]

I know that GRSISort has the ability to generate and plot/overlay kinematics curves, but I can't find any documentation on how to do it.

@pcbend could you provide me with a quick example on how to do it? If you do I would be willing to write the documentation on the wiki. Otherwise you could do the documentation and I could figure it out from that.

[pcbend]

Hi Ryan,

Sorry I've been doing a bit of traveling the past week or so. I will get you something written up (even if it is just a set of commands I've used) very soon.

On Wed, Feb 11, 2015 at 10:23 AM, Ryan Braid notifications@github.com wrote:

I know that GRSISort has the ability to generate and plot/overlay kinematics curves, but I can't find any documentation on how to do it.

@pcbend https://github.com/pcbend could you provide me with a quick example on how to do it? If you do I would be willing to write the documentation on the wiki. Otherwise you could do the documentation and I could figure it out from that.

— Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199.

[steffencruz]

Hey Ryan, There is a kinematics class in TGRSIAnalysis called TKinematics.

This can be used to define reaction kinematics and calculate a whole slew of properties such as energy in the lab frame, cm frame and also stuff like excitation energies.

The simplest instantiation method is uses const char arguments. TKinematics *mykin = new TKinematics(beam_energy,beam,target,ejectile,recoil)

a specific example, for elastic proton scattering off a Sr95 beam at 5.5 MeV/u (~520 MeV total kinetic energy), is; TKinematics *mykin = new TKinematics(520.0,"Sr95","p","p","Sr95")

The other instantiation methods require you to first define TNucleus objects (another GRSISort class) and then use those. That's why it's easier to get started using just const chars... this way TKinematics will create the TNucleus objects for you.

I think TNucleus can handle a range of input const char nuclei names, so "95sr", "95 SR", "Sr 95" should all work fine. It'll also tell you if it couldn't interpret the nucleus name.

You might want to draw the kinematic curve, which is done using; mykin->Evslab(theta_min,theta_max,theta_step_size,particle) so if I want to look at the elastic scattered protons in my example I'd write; mykin->Evslab(0,89.9,1.0,2) for angular range 0-(~)90 degrees, generating 90 points. I think it screws up if you just put 90 degrees as the maximum angle, because some terms diverge in the calculations at that angle (ie cross section in CM frame). The last argument is 2 for protons and 3 for my strontium recoil.

ALL ENERGIES IN TKINEMATICS ARE DEFINED IN MEV. Also, it's fully relativistic and so planck units are used (the speed of light scaled to one and is unit-less). This means that velocities are also beta values, eg 3e7 m/s = 0.1

[pcbend]

Thanks Steffen!

On Wed, Feb 18, 2015 at 11:27 AM, steffencruz notifications@github.com wrote:

Hey Ryan, There is a kinematics class in TGRSIAnalysis called TKinematics.

This can be used to define reaction kinematics and calculate a whole slew of properties such as energy in the lab frame, cm frame and also stuff like excitation energies.

The simplest instantiation method is uses const char arguments. TKinematics *mykin = new TKinematics(beam_energy,beam,target,ejectile,recoil)

a specific example, for elastic proton scattering off a Sr95 beam at 5.5 MeV/u (~520 MeV total kinetic energy), is; TKinematics *mykin = new TKinematics(520.0,"Sr95","p","p","Sr95")

The other instantiation methods require you to first define TNucleus objects (another GRSISort class) and then use those. That's why it's easier to get started using just const chars... this way TKinematics will create the TNucleus objects for you.

I think TNucleus can handle a range of input const char nuclei names, so "95sr", "95 SR", "Sr 95" should all work fine. It'll also tell you if it couldn't interpret the nucleus name.

You might want to draw the kinematic curve, which is done using; mykin->Evslab(theta_min,theta_max,theta_step_size,particle) so if I want to look at the elastic scattered protons in my example I'd write; mykin->Evslab(0,89.9,1.0,2) for angular range 0-(~)90 degrees, generating 90 points. I think it screws up if you just put 90 degrees as the maximum angle, because some terms diverge in the calculations at that angle (ie cross section in CM frame). The last argument is 2 for protons and 3 for my strontium recoil.

ALL ENERGIES IN TKINEMATICS ARE DEFINED IN MEV. Also, it's fully relativistic and so planck units are used (the speed of light scaled to one and is unit-less). This means that velocities are also beta values, eg 3e7 m/s = 0.1

— Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199#issuecomment-74930361.

[r3dunlop]

Awesome. Someone throw this up on the wiki!

On Feb 18, 2015, at 2:34 PM, pcbend notifications@github.com wrote:

Thanks Steffen!

On Wed, Feb 18, 2015 at 11:27 AM, steffencruz notifications@github.com wrote:

Hey Ryan, There is a kinematics class in TGRSIAnalysis called TKinematics.

This can be used to define reaction kinematics and calculate a whole slew of properties such as energy in the lab frame, cm frame and also stuff like excitation energies.

The simplest instantiation method is uses const char arguments. TKinematics *mykin = new TKinematics(beam_energy,beam,target,ejectile,recoil)

a specific example, for elastic proton scattering off a Sr95 beam at 5.5 MeV/u (~520 MeV total kinetic energy), is; TKinematics *mykin = new TKinematics(520.0,"Sr95","p","p","Sr95")

The other instantiation methods require you to first define TNucleus objects (another GRSISort class) and then use those. That's why it's easier to get started using just const chars... this way TKinematics will create the TNucleus objects for you.

I think TNucleus can handle a range of input const char nuclei names, so "95sr", "95 SR", "Sr 95" should all work fine. It'll also tell you if it couldn't interpret the nucleus name.

You might want to draw the kinematic curve, which is done using; mykin->Evslab(theta_min,theta_max,theta_step_size,particle) so if I want to look at the elastic scattered protons in my example I'd write; mykin->Evslab(0,89.9,1.0,2) for angular range 0-(~)90 degrees, generating 90 points. I think it screws up if you just put 90 degrees as the maximum angle, because some terms diverge in the calculations at that angle (ie cross section in CM frame). The last argument is 2 for protons and 3 for my strontium recoil.

ALL ENERGIES IN TKINEMATICS ARE DEFINED IN MEV. Also, it's fully relativistic and so planck units are used (the speed of light scaled to one and is unit-less). This means that velocities are also beta values, eg 3e7 m/s = 0.1

— Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199#issuecomment-74930361.

— Reply to this email directly or view it on GitHub.

[rbraid]

I will hold up my end of the bargain and put it on the wiki, one I get things working.

Give me a few days to wrap my head around it.

[rbraid]

@steffencruz I am having a hard time getting this started. I thought that this information was only applicable to the latest release so I waited to try this until I was done with what I was working on, but it doesn't seem to have changed.

At a basic level, TKinematics doesn't seem to be recognized by grsisort the same way it recognizes other classes. TChannel, for example tab-completes and has coloring.

You were fairly explicit on what to type for an example, but it doesn't work:

GRSI [0]  TKinematics *mykin = new TKinematics(520.0,"Sr95","p","p","Sr95")
Error: Symbol TKinematics is not defined in current scope  (tmpfile):1:
Error: Symbol TKinematics is not defined in current scope  (tmpfile):1:
Error: type TKinematics not defined FILE:(tmpfile) LINE:1
Warning: Automatic variable TKinematics*mykin is allocated (tmpfile):1:
Error: Undeclared variable TKinematics*mykin (tmpfile):1:
*** Interpreter error recovered ***

Could you send me whatever commands you issue to plot it?

[pcbend]

Hi Ryan,

I am not getting the same results as you. Typing the copied command I get:

[14:18 tiguser@grsmid01 ~] > grsisort -l GRSI [0] TKinematics *mykin = new TKinematics(520.0,"Sr95","p","p","Sr95") GRSI [1]

which tells me everything worked fine. Did you have an issues during compilation?

Peter

On Tue, Mar 3, 2015 at 5:07 PM, Ryan Braid notifications@github.com wrote:

@steffencruz https://github.com/steffencruz I am having a hard time getting this started. I thought that this information was only applicable to the latest release so I waited to try this until I was done with what I was working on, but it doesn't seem to have changed.

At a basic level, TKinematics doesn't seem to be recognized by grsisort the same way it recognizes other classes. TChannel, for example tab-completes and has coloring.

You were fairly explicit on what to type for an example, but it doesn't work:

GRSI [0] TKinematics _mykin = new TKinematics(520.0,"Sr95","p","p","Sr95") Error: Symbol TKinematics is not defined in current scope (tmpfile):1: Error: Symbol TKinematics is not defined in current scope (tmpfile):1: Error: type TKinematics not defined FILE:(tmpfile) LINE:1 Warning: Automatic variable TKinematics_mykin is allocated (tmpfile):1: Error: Undeclared variable TKinematicsmykin (tmpfile):1: ** Interpreter error recovered ***

Could you send me whatever commands you issue to plot it?

— Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199#issuecomment-77046999.

[SmithJK]

I get similar results to Ryan.

When I list the libraries (gSystem->ListLibraries()) on startup of GRSISort, I don't see libKinematics.so loaded.

I tried to load the library and I get the following error message:

dlopen error: /home/jenna/TRIUMF/packages/GRSISort/libraries/libKinematics.so: undefined symbol: _ZTI8TNucleus Load Error: Failed to load Dynamic link library /home/jenna/TRIUMF/packages/GRSISort/libraries/libKinematics.so

Also, I just re-complied and all the kinematics libraries compiled [OK].

[pcbend]

I see it in the grifuser, tiguser, and my home directory accounts. What version of the code are you guys using? Or did you notice something failed or gave a warning when you compiles?

On Tue, Mar 3, 2015 at 5:25 PM, SmithJK notifications@github.com wrote:

I get similar results to Ryan.

When I list the libraries (gSystem->ListLibraries()) on startup of GRSISort, I don't see libKinematics.so loaded.

— Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199#issuecomment-77050155.

[SmithJK]

I just forked off the main branch.

Warnings come at compile time for TAnalysisTreeBuilder.o and TCalManager.o.

TAnalysisTreeBuilder error: TAnalysisTreeBuilder.cxx: In member function ‘void TAnalysisTreeBuilder::Status()’: TAnalysisTreeBuilder.cxx:873:206: warning: unknown conversion type character ‘,’ in format -Wformat=/fEntries, fAnalysisIn, fAnalysisOut, (100._fAnalysisOut)/fAnalysisIn, fAnalysisOut/w.RealTime(), w.RealTime(), ((double)(fAnalysisIn-fAnalysisOut))/fAnalysisOut_w.RealTime()); ^ TAnalysisTreeBuilder.cxx:873:206: warning: unknown conversion type character ‘,’ in format [-Wformat=] TAnalysisTreeBuilder.cxx:877:142: warning: unknown conversion type character ‘,’ in format -Wformat=/fEntries, fAnalysisIn, fAnalysisOut, (100.*fAnalysisOut)/fAnalysisIn, fAnalysisOut/w.RealTime(), w.RealTime()); ^ TAnalysisTreeBuilder.cxx:877:142: warning: unknown conversion type character ‘,’ in format [-Wformat=]

TCalManager error: TCalManager.cxx: In member function ‘virtual void TCalManager::Print(Optiont) const’: TCalManager.cxx:174:39: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 2 has type ‘std::map<unsigned int, TCal_>::size_type {aka long unsigned int}’ [-Wformat=] printf("Size: %u\n", fcalmap.size()); ^

[rbraid]

I see no compilation errors or warnings. This is with the latest commit, 7e565567c9afa45e454800a4f140db09956d4dd0.

Here is the fun part: it works on my data processing machine running Scientific Linux 6.6, but it shows the symptoms above on my laptop running Ubuntu 12.04.

[SmithJK]

Ah. That is the same for me here - fails on Ubuntu 14.04, runs on Scientific Linux. I remember having a discussion about Ubuntu not having the required libraries for part of GRSISort - possibly related?

[pcbend]

It most certainly is related. The difference between debian-like and centos-like is more than enough to be annoying, The good news is, I now have access to a debian machine however still have some set up to do. Hopefully this means I will be able to get it going soon... I will look and keep you guys posted.

On Tue, Mar 3, 2015 at 5:37 PM, SmithJK notifications@github.com wrote:

Ah. That is the same for me here - fails on Ubuntu 14.04, runs on Scientific Linux. I remember having a discussion about Ubuntu not having the required libraries for part of GRSISort - possibly related?

— Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199#issuecomment-77052837.

[r3dunlop]

@SmithJK, are there any other libraries missing that you can easily see? It might help to identify the problem.

On Mar 3, 2015, at 5:40 PM, pcbend notifications@github.com wrote:

It most certainly is related. The difference between debian-like and centos-like is more than enough to be annoying, The good news is, I now have access to a debian machine however still have some set up to do. Hopefully this means I will be able to get it going soon... I will look and keep you guys posted.

On Tue, Mar 3, 2015 at 5:37 PM, SmithJK notifications@github.com wrote:

Ah. That is the same for me here - fails on Ubuntu 14.04, runs on Scientific Linux. I remember having a discussion about Ubuntu not having the required libraries for part of GRSISort - possibly related?

— Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199#issuecomment-77052837.

— Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199#issuecomment-77053920.

[SmithJK]

Comparing my Centos and Debian versions, Debian is missing:

• libTGRSIFit.so
• libTCal.so
• libSRIM.so
• libKinematics.so
• libNucleus.so

[r3dunlop]

I think I removed the warnings from TAnalysisTreeBuilder and from TCalManager. I will push later. Starting to look into real issue.

On Mar 3, 2015, at 6:25 PM, SmithJK notifications@github.com wrote:

Comparing my Centos and Debian versions, Debian is missing:

libTGRSIFit.so libTCal.so libSRIM.so libKinematics.so libNucleus.so — Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199#issuecomment-77062122.

[r3dunlop]

Can you do gSystem-Load(“libKinematics”)? Sorry for the questions, I don’t have un-annoying access to a debian machine right now.

On Mar 3, 2015, at 6:25 PM, SmithJK notifications@github.com wrote:

Comparing my Centos and Debian versions, Debian is missing:

libTGRSIFit.so libTCal.so libSRIM.so libKinematics.so libNucleus.so — Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199#issuecomment-77062122.

[r3dunlop]

I found this on a ROOT forum form Phillipe "Ubuntu changed the default behavior of linking to ignore any library that is not needed by whatever is seeing before the library in the link line.”

On Mar 3, 2015, at 6:50 PM, Ryan Dunlop rdunlop@uoguelph.ca wrote:

Can you do gSystem-Load(“libKinematics”)? Sorry for the questions, I don’t have un-annoying access to a debian machine right now.

On Mar 3, 2015, at 6:25 PM, SmithJK <notifications@github.com mailto:notifications@github.com> wrote:

Comparing my Centos and Debian versions, Debian is missing:

libTGRSIFit.so libTCal.so libSRIM.so libKinematics.so libNucleus.so — Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199#issuecomment-77062122.

[SmithJK]

When trying to load the library, I get:

dlopen error: /home/jenna/TRIUMF/packages/GRSISort/libraries/libKinematics.so: undefined symbol: _ZTI8TNucleus
Load Error: Failed to load Dynamic link library /home/jenna/TRIUMF/packages/GRSISort/libraries/libKinematics.so

So it is finding the library, but it can't load it.

[r3dunlop]

This is the linking order in the make file…

LIBS += -lGRSIRootIO
LIBS += -lAnalysisTreeBuilder
LIBS += -lGRSIFormat
LIBS += -lNucleus
LIBS += -lKinematics
LIBS += -lSRIM
LIBS += -lTCal
LIBS += -lTGRSIFit

hmmm.... seems like the last 5 are being dropped. Can you try moving a couple around and seeing what happens?

[r3dunlop]

I noticed a silly problem in these...I'm going to change it and push and someone can tell me if the problem is still there. If it is that's fine the problem still needed to be fixed. The problem is that each of these headers have an #ifndef __HEADER_H__ and the leading double underscore is reserved for other things and results in undefined behaviour.

[r3dunlop]

If someone with Ubuntu can check to see if warnings went away...and potentially the problem...that would be great!

[SmithJK]

Warnings went away, but problem still exists.

[pcbend]

i think we can fix this with the -Wl,no-as-need flag added to the cflag list if built on ubuntu like systems. That flag forces all the libraries to be load instead of trying to define which ones it thinks it needs. I'll take a look and get this up going tomorrow-ish.

On Tue, Mar 3, 2015 at 6:04 PM, SmithJK notifications@github.com wrote:

Warnings went away, but problem still exists.

— Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199#issuecomment-77083586.

[r3dunlop]

Oh I thought we still had that flag in. Can you not use it on Sci Linux? To check for the distribution in the make file you might have to look in the /etc/*release file. As for now, we can test that flag on an ubuntu system to save you the hassle if it won't work anyway

[pcbend]

i am not sure about sci linux.... we should be able to use it. i did not get the name of the flag exactly right in my last post. if someone is will to find the exact right name and add it to the CFLAGS in the makefile in the GRSISYS directory who has ubuntu, that would be awesome.

On Tue, Mar 3, 2015 at 6:19 PM, Ryan Dunlop notifications@github.com wrote:

Oh I thought we still had that flag in. Can you not use it on Sci Linux? To check for the distribution in the make file you might have to look in the /etc/*release file. As for now, we can test that flag on an ubuntu system to save you the hassle if it won't work anyway

— Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199#issuecomment-77085090.

[r3dunlop]

-Wl,--no-as-needed

[pcbend]

thats the one.

On Tue, Mar 3, 2015 at 6:27 PM, Ryan Dunlop notifications@github.com wrote:

-Wl,--no-as-needed

— Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199#issuecomment-77085862.

[SmithJK]

That does it.

On Tue, Mar 3, 2015 at 6:29 PM, pcbend notifications@github.com wrote:

thats the one.

On Tue, Mar 3, 2015 at 6:27 PM, Ryan Dunlop notifications@github.com wrote:

-Wl,--no-as-needed

— Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199#issuecomment-77085862.

— Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199#issuecomment-77086023.

[pcbend]

excellent.

On Tue, Mar 3, 2015 at 6:32 PM, SmithJK notifications@github.com wrote:

That does it.

On Tue, Mar 3, 2015 at 6:29 PM, pcbend notifications@github.com wrote:

thats the one.

On Tue, Mar 3, 2015 at 6:27 PM, Ryan Dunlop notifications@github.com wrote:

-Wl,--no-as-needed

— Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199#issuecomment-77085862.

— Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199#issuecomment-77086023.

— Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199#issuecomment-77086287.

[r3dunlop]

Alright, @rbraid please let us know when the wiki is done so we can close this beast.

[rbraid]

I am still having problems getting this to work properly. When I run the commands

TKinematics *mykin = new TKinematics(520.0,"Sr95","p","p","Sr95")
TSpline3 *sp = mykin->Evslab(0,89.9,1.0,2)
sp->Draw()

I get a seg fault. TSpline3 inherits a Draw command from TSpline, so it should work. The stack trace makes it look like it isn't grsisort's fault it seg faults, either. Here is an excerpt:

===========================================================
#11 0x00007f12748b8948 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#12 0x00007f1278f87415 in TSpline3::Eval(double) const () at /home/ryan/installdir/rootdat/root/hist/hist/src/TSpline.cxx:815
#13 0x00007f1278f83b20 in TSpline::Paint(char const*) () at /home/ryan/installdir/rootdat/root/hist/hist/src/TSpline.cxx:186
#14 0x00007f1278253241 in TPad::PaintModified() () at /home/ryan/installdir/rootdat/root/graf2d/gpad/src/TPad.cxx:3242
#15 0x00007f127822c815 in TCanvas::Update() () at /home/ryan/installdir/rootdat/root/graf2d/gpad/src/TCanvas.cxx:2153
#16 0x00007f127acb291b in TCint::UpdateAllCanvases() () at /home/ryan/installdir/rootdat/root/core/meta/src/TCint.cxx:2210
===========================================================

Could this be a problem with GRootCanvas? Both times right before I get the sementation violation, I see Created a GRootCanvas.

[pcbend]

It is not a GRootCanvas Problem. I'll get back to you shortly, something strange is going on.

On Wed, Mar 4, 2015 at 12:52 PM, Ryan Braid notifications@github.com wrote:

I am still having problems getting this to work properly. When I run the commands

TKinematics mykin = new TKinematics(520.0,"Sr95","p","p","Sr95") TSpline3 sp = mykin->Evslab(0,89.9,1.0,2) sp->Draw()

I get a seg fault. TSpline3 inherits a Draw command from TSpline, so it should work. The stack trace makes it look like it isn't grsisort's fault it seg faults, either. Here is an excerpt:

11 0x00007f12748b8948 in ?? () from /lib/x86_64-linux-gnu/libc.so.6

12 0x00007f1278f87415 in TSpline3::Eval(double) const () at /home/ryan/installdir/rootdat/root/hist/hist/src/TSpline.cxx:815

13 0x00007f1278f83b20 in TSpline::Paint(char const*) () at /home/ryan/installdir/rootdat/root/hist/hist/src/TSpline.cxx:186

14 0x00007f1278253241 in TPad::PaintModified() () at /home/ryan/installdir/rootdat/root/graf2d/gpad/src/TPad.cxx:3242

15 0x00007f127822c815 in TCanvas::Update() () at /home/ryan/installdir/rootdat/root/graf2d/gpad/src/TCanvas.cxx:2153

16 0x00007f127acb291b in TCint::UpdateAllCanvases() () at /home/ryan/installdir/rootdat/root/core/meta/src/TCint.cxx:2210

Could this be a problem with GRootCanvas? Both times right before I get the sementation violation, I see Created a GRootCanvas.

— Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199#issuecomment-77208980.

[steffencruz]

Okay, it's the same problem as the 89.9 degree precautionary measure. I changed the starting angle from 0 to 1 and it worked fine. Again, I suspect it's because it's trying to put your first point at zero degrees and there's probably a 1/0 error or something horrible.

At some point in the not so distant future I'll make this class user friendly..

Cheers, STeffen

[r3dunlop]

@rbraid I will carve you out a spot on the wiki to put this stuff.

[rbraid]

Can someone explain what the last int in mykin->Evslab(1,89.9,1.0,2) does? I thought switching 2 to 1 or 4 would give me the Sr plot judging from the source code, but instead it crashes.

[pcbend]

It should but one is before the reaction. Try three. I think. On Mar 5, 2015 7:09 PM, "Ryan Braid" notifications@github.com wrote:

Can someone explain what the last int in mykin->Evslab(1,89.9,1.0,2) does? I thought switching 2 to 1 or 4 would give me the Sr plot judging from the source code, but instead it crashes.

— Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199#issuecomment-77480734.

[rbraid]

I tried 3 as well! The error I get for 3 and 4 is:

*** glibc detected *** grsisort: free(): corrupted unsorted chunks: 0x0000000001680530 ***

With 1 it works, but the draw fails.

GRSI [2] sp->Draw()
Created a GRootCanvas.
Info in <TCanvas::MakeDefCanvas>:  created default TCanvas with name c1
Error in <TSpline3::Eval>: Binary search failed x(0) = 0.000000 < x= 0.000000 < x(1) = 0.000000

 *** Break *** segmentation violation

Trace excerpt:

===========================================================
#10 0x00007f25b8311948 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#11 0x00007f25bc9e0415 in TSpline3::Eval(double) const () at /home/ryan/installdir/rootdat/root/hist/hist/src/TSpline.cxx:815
#12 0x00007f25bc9dcb20 in TSpline::Paint(char const*) () at /home/ryan/installdir/rootdat/root/hist/hist/src/TSpline.cxx:186
#13 0x00007f25bbcac241 in TPad::PaintModified() () at /home/ryan/installdir/rootdat/root/graf2d/gpad/src/TPad.cxx:3242
#14 0x00007f25bbc85815 in TCanvas::Update() () at /home/ryan/installdir/rootdat/root/graf2d/gpad/src/TCanvas.cxx:2153
#15 0x00007f25be70b91b in TCint::UpdateAllCanvases() () at /home/ryan/installdir/rootdat/root/core/meta/src/TCint.cxx:2210
===========================================================

[pcbend]

K. Unless steffen sees this I'm not going to be able to do anything about this till tomorrow. On Mar 5, 2015 7:16 PM, "Ryan Braid" notifications@github.com wrote:

I tried 3 as well! The error I get for 3 and 4 is:

* glibc detected * grsisort: free(): corrupted unsorted chunks: 0x0000000001680530 ***

With 1 it works, but the draw fails.

GRSI [2] sp->Draw() Created a GRootCanvas. Info in TCanvas::MakeDefCanvas: created default TCanvas with name c1 Error in TSpline3::Eval: Binary search failed x(0) = 0.000000 < x= 0.000000 < x(1) = 0.000000

* Break * segmentation violation

Trace excerpt:

10 0x00007f25b8311948 in ?? () from /lib/x86_64-linux-gnu/libc.so.6

11 0x00007f25bc9e0415 in TSpline3::Eval(double) const () at /home/ryan/installdir/rootdat/root/hist/hist/src/TSpline.cxx:815

12 0x00007f25bc9dcb20 in TSpline::Paint(char const*) () at /home/ryan/installdir/rootdat/root/hist/hist/src/TSpline.cxx:186

13 0x00007f25bbcac241 in TPad::PaintModified() () at /home/ryan/installdir/rootdat/root/graf2d/gpad/src/TPad.cxx:3242

14 0x00007f25bbc85815 in TCanvas::Update() () at /home/ryan/installdir/rootdat/root/graf2d/gpad/src/TCanvas.cxx:2153

15 0x00007f25be70b91b in TCint::UpdateAllCanvases() () at /home/ryan/installdir/rootdat/root/core/meta/src/TCint.cxx:2210

— Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199#issuecomment-77481585.

[rbraid]

I am starting to think putting this on the wiki is a bit premature. It doesn't seem very stable yet.

[r3dunlop]

If you put each command leading up to that point I can try to figure it out.

On Mar 5, 2015, at 7:19 PM, Ryan Braid notifications@github.com wrote:

I am starting to think putting this on the wiki is a bit premature. It doesn't seem very stable yet.

— Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199#issuecomment-77481896.

[r3dunlop]

I copied your commands on the wiki, and it worked fine. Have you done anything different than what is up there?

On Mar 5, 2015, at 7:19 PM, Ryan Braid notifications@github.com wrote:

I am starting to think putting this on the wiki is a bit premature. It doesn't seem very stable yet.

— Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199#issuecomment-77481896.

[r3dunlop]

I can confirm that 2 is the only options that works. The other two fail for different reasons.

On Mar 5, 2015, at 7:09 PM, Ryan Braid notifications@github.com wrote:

mykin->Evslab(1,89.9,1.0,2)

[r3dunlop]

This is a print out of the angles and energies when EvsLab is run

GRSI [2] TSpline3 sp = mykin->Evslab(1,70,1.0,2) ... ... ... Angle: 65 Energy: 3836.53 Angle: 66 Energy: 3553.06 Angle: 67 Energy: 3278.45 Angle: 68 Energy: 3013.02 Angle: 69 Energy: 2757.09 GRSI [2] TSpline3 sp = mykin->Evslab(1,70,1.0,3) Angle: 0.0215836 Energy: 498323 GRSI [3] TSpline3 sp = mykin->Evslab(1,70,1.0,1) Angle: 0 Energy: 0 GRSI [4] TSpline3 sp = mykin->Evslab(1,70,1.0,0) Angle: 0 Energy: 520000

Your plot is dying because there is noting to plot! Is this expected? I'm assuming there is a sneaky break in there or something that doesn't belong....

Adding to this we see *TSpline3 sp = mykin->Evslab(1,70,1.0,0)** Angle: 0 Energy: 520000 Max Angle -1: -0.391639

Our graph gets 0 entries and dies.

[r3dunlop]

This is what I get for part 3 if I turn off all of the break statements in EvsLab. I have exhausted my knowledge of what this is supposed to be doing so I'll leave @steffencruz and @pcbend with this.

[pcbend]

Ok. I have just pushed some changes that should make this a bit more stable. The issues here are three fold.

The first, there where some memory bugs that could happen in certain bad scenarios (angle out of range/energy out of range) which is what was causing the glibc issues.

The second issue is that this function should really only be used for parts 2&3 as parts 0&1 are before the reaction and this function doesn't make any sense.

The third issue is with the way TSpline3 is behaving. A TSpline3 requires things to be a "good function", each value of x must be larger than the value that proceeded it. If this is not the case, it's behavior is not well defined but will most certainly do bad things. This function now prints a warning and returns zero if this happens. I have also wrote a function Evslab_graph which can be used instead. This function does the exact same thing, but returns a tgraph instead of a tspline3. The advantage to this is it is stable against "bad functions" and will allow us to examine Kinematic curves which double back on themselves.

I am only considering this a short term solution. We still need to clean up the neighboring functions a bit and provide a stable way to overlay all kinematic lines on data in a TH2.

On Thu, Mar 5, 2015 at 8:58 PM, Ryan Dunlop notifications@github.com wrote:

[image: screenshot 2015-03-05 20 56 56] https://cloud.githubusercontent.com/assets/5428160/6518862/34c7ba7a-c37a-11e4-9e15-711d8a23a6fd.png

This is what I get for part 3 if I turn off all of the break statements in EvsLab. I have exhausted my knowledge of what this is supposed to be doing so I'll leave @steffencruz https://github.com/steffencruz and @pcbend https://github.com/pcbend with this.

— Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199#issuecomment-77492912.

[r3dunlop]

None of this should affect what Ryan is doing though right? Everything you will be changing is done in the background and accessing the information should be the same, right?

[pcbend]

That is right, as long as Ryan B, is only editing the CSM than we do not need to worry about any conflicts with the rest of the code. Everything should play nice.

On Mon, Mar 9, 2015 at 4:26 PM, Ryan Dunlop notifications@github.com wrote:

None of this should affect what Ryan is doing though right? Everything you will be changing is done in the background and accessing the information should be the same, right?

— Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/199#issuecomment-77934831.

[VinzenzBildstein]

I think this can be closed by now?