Make Matrices Bug?

[pcbend]

After helping Nikita make some gates, we found many of the gamma-gamma matrices generated by the make matrices script are not symmetric. I feel this is a pretty big issue as a non-symmetric matrix requires more specialized analysis than I believe any of us are currently doing. Was this done on purpose or is it really a bug?

Assuming this is a bug; I can go through the script and symmetrize the matrices, however this would imply we should get rid of the files generated with the script so far and recreate them. Perhaps this is also a good time to slim the script down to a smaller number of more use matrices. Thoughts?

sorry for the mass edits. i should learn to proof read.

[r3dunlop]

Which aren’t symmetric? In something like gamma-gamma we are looping from first to last event nested inside a loop from first to last event.

On Apr 23, 2015, at 5:47 PM, pcbend notifications@github.com wrote:

After help make some gates, it has come to my attention that many of the gamma-gamma matrices generated by the make matrices script are not symmetric. I feel this is a pretty big issue as a non-symmetric matrix requires more specialized analysis than I believe an of us are doing. Was this done on purpose or is it really a bug?

Assuming this is a bug, I can go through the script and symmetrize the matrices, however this would imply we should get rid of the files generated with the script so far and recreate them. Perhaps this is also a good time to slim the script down to a smaller number of more use matrices. Thoughts?

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

[SmithJK]

Ryan basically anticipated my comment.

I think it would be helpful to pare down MakeMatrices, but I also think it would be helpful to keep this overflowing version as well.

[r3dunlop]

I've also added an example script that is slimmed down. MakeMatrices is sort of our "debugging" script. I think people should be pointed to the example script and kept away from MakeMatrices.

[pcbend]

We are, however we are only filling (one,two). To symmetrize we also need to fill (two,one).

On Thu, Apr 23, 2015 at 6:11 PM, Ryan Dunlop notifications@github.com wrote:

Which aren’t symmetric? In something like gamma-gamma we are looping from first to last event nested inside a loop from first to last event.

On Apr 23, 2015, at 5:47 PM, pcbend notifications@github.com wrote:

After help make some gates, it has come to my attention that many of the gamma-gamma matrices generated by the make matrices script are not symmetric. I feel this is a pretty big issue as a non-symmetric matrix requires more specialized analysis than I believe an of us are doing. Was this done on purpose or is it really a bug?

Assuming this is a bug, I can go through the script and symmetrize the matrices, however this would imply we should get rid of the files generated with the script so far and recreate them. Perhaps this is also a good time to slim the script down to a smaller number of more use matrices. Thoughts?

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

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

[r3dunlop]

yes but one becomes two. So we are filling it the other way around on the other permutation of the nested loop

[pcbend]

i am editing MakeMatrices2, which is an identical copy but with sym matrices now.

On Thu, Apr 23, 2015 at 6:13 PM, SmithJK notifications@github.com wrote:

Ryan basically anticipated my comment.

I think it would be helpful to pare down MakeMatrices, but I also think it would be helpful to keep this overflowing version as well.

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

[SmithJK]

This is only if the loops are from two=0 -> GetMultiplicity and not from two=one+1 -> GetMultiplicity, which I think they are.

[pcbend]

sym gamma-gamma matrices, that is.

additionally, this may also explain our problem so far with angular distributions.

On Thu, Apr 23, 2015 at 6:14 PM, Peter pcbend@gmail.com wrote:

i am editing MakeMatrices2, which is an identical copy but with sym matrices now.

On Thu, Apr 23, 2015 at 6:13 PM, SmithJK notifications@github.com wrote:

Ryan basically anticipated my comment.

I think it would be helpful to pare down MakeMatrices, but I also think it would be helpful to keep this overflowing version as well.

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

[r3dunlop]

we have

for(gamma1 = first gamma until gamma 1 = last gamma)
  for(gamma2 = first gamma until gamma 2 = last gamma)
    fill(gamma1, gamma2)

This takes into account when gamma1 and gamma2 are each of the gammas

[pcbend]

Projections with an identical gat on the x-axis and y-axis give different numbers of counts. They are not sym.

On Thu, Apr 23, 2015 at 6:14 PM, Ryan Dunlop notifications@github.com wrote:

yes but one becomes two. So we are filling it the other way around on the other permutation of the nested loop

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

[r3dunlop]

There is just no obvious place in the code that I can see this happening.

[r3dunlop]

this line maybe? I don't even know why it's there

if(!gotSceptar && (grif->GetGriffinHit(one)->GetAddress()%16 == 15 || grif->GetGriffinHit(two)->GetAddress()%16 == 15)) {
  continue;
}

[SmithJK]

That should also be symmetric if the loop is good. There are some places where the loop takes "two" from one+1 to multiplicity, but I don't think those fill anything, just add counters.

[SmithJK]

@pcbend, which matrices show non-identical gates? All of them?

[SmithJK]

If there's an absolute value missing in a time difference evaluation, that would make a time-gated matrix anti-symmetric.

[pcbend]

I went back to recheck, because I agree with the loop. attached are to spectrum gated and back ground subtracted using the exact same ranges just changing the axis i picked for the prompt and bg gates. Notice one has a peak at 1129 and the other does not. This can only come from an un-sym matrix

[pcbend]

The matix i used for the above spectrum is addbackMatirx_bgcorr,

the non-sym part my come from the time random subtarcted bg matrix.

[r3dunlop]

It could also be in add-back?

[pcbend]

no, this is a fill issue, either way we loop over a vector of hits. i cannot understand how this could be addback.

[pcbend]

the exact commands i used to make the two spectrum above:

Top TH1D* total = addbackMatrix_bgcorrB->ProjectionX("total") TH1D* gate1129 = addbackMatrix_bgcorr->ProjectionX("gate1129",1125,1133) TH1D* bg1129 = addbackMatrix_bgcorr->ProjectionX("bg1129",1135,1143) TH1D *good1129 = gate1129->Clone("good1129") good1129->Add(bg1129,-1) new GCanvas; good1129->Draw()

Bottom: TH1D* total = addbackMatrix_bgcorr->ProjectionX("total") TH1D gate1129 = addbackMatrix_bgcorr->ProjectionY("gate1129",1125,1333); TH1D bg1129 = addbackMatrix_bgcorr->ProjectionY("bg1129",1135,1343); TH1D *good1129 = gate1129->Clone("good1129") good1129->Add(bg1129,-1) new GCanvas; good1129->Draw()

[pcbend]

oh crap hold on this might be a false alarm i just notice the bottom bg gate is going from 1135 to 1343

one sec. this may have been a large fuss over nothing.

[pcbend]

yeah... so i am going to go ahead and close this and we will all just pretend it never happened. Sorry about this Ryan/Jenna. I didn't mean to make a scare.

[r3dunlop]

Keeping us on our toes is all... Just checking to see if we actually know what is going on.... :P

[pcbend]

yeah, its a good thing you can't actually see how red I am right now.