Problem with response histogram getting filled twice?

[hschellman]

There seems to be something going on that fills both the tuned and untuned responses with the same thing. This leads to there being too many entries in both. May be how pointers to the responses are set up. Basically tuned and untuned may be sharing the same pointer so you fill both.

[hschellman]

I think it is partially because the Fill methods don't know if they are getting a tuned or untuned weight. Fill methods should probably get a isTuned input variable and the loops code should call with and without that set. This goes for all fill methods. So if you are running in both mode, it looks as if Loops puts weights into both responses?

[hschellman]

It appears that the code wasn't filling tuned and untuned responses separately - they had the same content. I'm thinking of adding a scale argument to the various fillers so that one can choose whether or not to use it. First test indicates that, at least, the responses are different when you do this. But the treatment of responses differently from HistWrappers does make this hard to track down. We need a class diagram of all of this stuff.

[hschellman]

Yep, both Fillers.h and the VariablesFromConfig classes were deciding to fill the Response hist, I made the Fillers.h just call the VariablesFromConfig methods which then dealt with the tuned/untuned part. This is now in branch hms-2022-09 and 2D histograms now agree with 1D for ptmu.

[hschellman]

Ways to check for this. Integral of the mcsighist should be close to the integral of the migration matrix. It was off by a factor of 2. Also the tuned and untuned versions need to have different integrals.

[physnerds]

I have been following this thread and now I am wondering how it is different from the method we used to construct the response matrix.

Thanks, Amit Bashyal

On Sun, Sep 18, 2022, 3:44 PM Heidi Schellman @.***> wrote:

Yep, both Fillers.h and the VariablesFromConfig classes were deciding to fill the Response hist, I made the Fillers.h just call the VariablesFromConfig methods which then dealt with the tuned/untuned part. This is now in branch hms-2022-09 and 2D histograms now agree with 1D for ptmu.

— Reply to this email directly, view it on GitHub https://github.com/MinervaExpt/CCQENu/issues/53#issuecomment-1250383563, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD53MYMU4455NXUMLPXPRZDV655KLANCNFSM6AAAAAAQPDNZDU . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[hschellman]

This is specific to the implementation for our MAT. I asked Noah to do it "both ways" and unfortunately, it bother twice. But an interesting feature is that RooUnfold really gets grumpy if the response matrix is not the same normalization as the mc histograms and basically throws in a factor of 2 for the fun of it.

[hschellman]

Did both twice, not bother.

[hschellman]

Ok Noah, I think the solution was to do things right and move the response creation into the VariableFromConfig methods. That actually makes it possible not to have the new constructor (I just put in) for the histwrappermap that had to have both reco and truth binning in it. So will be a major cleanup in the code. Apologies for ever designing it this way.

[nhvaughan]

response-fix has 1D going. 2D in the works, which should go much faster.

[nhvaughan]

2D is done. Would like another test from someone else before merging to main