Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pulseArea GetS1 Gaussian width #107

Closed
sophiafarrell opened this issue May 18, 2021 · 2 comments
Closed

pulseArea GetS1 Gaussian width #107

sophiafarrell opened this issue May 18, 2021 · 2 comments

Comments

@sophiafarrell
Copy link
Contributor

In the NESTcalc::GetS1 function, there is a basic, no-timing block of code here:

nest/src/NEST.cpp

Lines 886 to 891 in 3322903

Nphe = nHits + BinomFluct(nHits, fdetector->get_P_dphe());
pulseArea = RandomGen::rndm()->rand_gauss(
BinomFluct(Nphe, 1. - (1. - eff) / (1. + fdetector->get_P_dphe())),
fdetector->get_sPEres() * sqrt(Nphe));
//proper truncation not done here because this is meant to be approximation, quick and dirty
spike = (double)nHits;

In these lines, pulseArea is smeared by sPEres * sqrt(Nphe) where the Nphe is defined:

Nphe = nHits + BinomFluct(nHits, fdetector->get_P_dphe());

To my understanding, this slightly (very, very slightly) overestimates the smearing effect, but it should probably not be ignored. My suggestion would be to replace the linked lines above with something like this to make the pulseArea calculation more statistically accurate. But, perhaps I am missing something.

    Nphe = nHits + BinomFluct(nHits, fdetector->get_P_dphe());
    Nphe_det = BinomFluct(Nphe, 1. - (1. - eff) / (1. + fdetector->get_P_dphe()));
    pulseArea = RandomGen::rndm()->rand_gauss(
					      Nphe_det,
					      fdetector->get_sPEres() * sqrt(Nphe_det));

This is in regards to the question I asked @mszydagis and then directed toward @riffard, but I figured that a git issue is more trackable for everyone. (Tagging @robertsjames here because he had the same question as well.)

@mszydagis
Copy link
Collaborator

thank you for catching this mistake. For >90% detection efficiency there is no difference, but who knows if we can maintain (like into G3 in the future) such high efficiencies. Therefore, it is important to do this right. The problem has been corrected

@sophiafarrell
Copy link
Contributor Author

(Referencing 9363b96 so people can track the change). Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants