S1 efficiency depends on nHits

[sophiafarrell]

At request, turning this question into an issue.
It seems that according to these lines:

nest/src/NEST.cpp

Lines 804 to 808 in 3322903

	double eff = fdetector->get_sPEeff();
	if ( eff < 1. )
	eff += ((1.-eff)/(2.*double(fdetector->get_numPMTs())))*double(nHits);
	if ( eff > 1. ) eff = 1.;
	if ( eff < 0. ) eff = 0.;

There is an "effective" SPE efficiency that depends on the number of hits, nHits. This comes into the S1 Pulse area at this timingless S1 case:

nest/src/NEST.cpp

Lines 887 to 889 in 3322903

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

The question that @robertsjames and I have is whether or not this "effective" efficiency is derived analytically, or fitted (where did it come from in functional form?) and if we can re-parameterize it in terms of something other than nHits. For example, in an ideal case, we would like for eff to be dependent instead on the number of photoelectrons produced or detected, such as this variable:

nest/src/NEST.cpp

Line 886 in 3322903

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

This eff is important because it has a ~few% effect for detectors with an SPE efficiency of <99%, which affects energy reconstruction, simulations, etc. So we want to get this right on our end, but also ensure that NEST has it right, too!

[mszydagis]

This has been changed, to where efficiency depends on Nphe. While that makes it slightly circular, the other issue (#107) alleviates this, by better distinguishing between Nphe and Nphe_det for detected. So, I am closing this too. Should be fully solved. Making the efficiency depend on the pulse area in PHE (or PE, same thing, different collaborations...) is actually better, since the 2-PE effect gives you an efficiency boost, like the LZ and LUX papers on that topic say (low-mass DM). Lastly, I added a comment in the code that justifies the functional form. It's super trivial, just a linear approximation.

[sophiafarrell]

(Just referencing the commit here so anyone searching this can see the change in full form 9363b96)