The way of setting transition_range for bias_step

[yaqiongl]

Hello, this is a joint post from princeton and cornell.
The transition_range config setting and kwarg in bias steps is tripping some of us up during testing. So far, the transition_range is a set of parameters set manually in the device config file. And it causes good detectors' Ites (and Pj, Rtes) to be negative when it is set too low or missing because Ites is calculated differently:

if not transition:
            # Assumes dRtes / dIb = 0
            I0 = Ib * dIrat
else:
            # Assumes dPj / dIb = 0
            I0 = Ib * dIrat / (2 * dIrat - 1)

We are thinking: Instead of having a fixed range in the config file, or a default of (1,8) V, would it not make more sense to compute this range from the preceding IV curve?
Another approach is to just use the sign of dIrat as something to tell if detectors are in transition&usable, say if dIrat is positive, we could find a way to flag the detector to be bad ones.

[jlashner]

Hi! Thanks for bringing this up, I think transition_range has always been kind of a kludge, but I never got around to improving it...

I think both of your approaches sound like good options! Using the sign of dIrat definitely sounds the easiest, and that should be relatively accurate as long as your not in the upper part of the transition where loop-gain ~ 1 (but I think that's ok since we'll never get good estimates for those detectors anyway). Do you think you're able to implement and test to see if it improves this? If not we can open an issue and I'll get to it eventually...

[yaqiongl]

We could definitely try it! We will be cold with Mv23 again in the week after next (the current cooldown here is routing wafers only), unless Pton want to test it immediately.

[dpdutcher]

I'm reanalyzing my bias step vs. vbias data, and the solution I've used in my own code is just to always have transition=True and to take the absolute value of the calculated R0. That gives the correct results in the normal branch and most of the transition. It doesn't get good resutls between about 0.8Rn and 1Rn, but transition=False doesn't work there either.

So my recommendation would be to only have the in-transition calculation and just do np.abs(R0).

[jlashner]

I don't really agree with this... I think we need to understand why good detectors are failing. Taking np.abs(R0) may give you a resistance that looks right, but if we don't know why it's failing then I don't think we could trust the resistance or the responsivity from the analysis.

I think we need to take a close look at the bias step analysis file to see exactly why it's coming out incorrect.

[dpdutcher]

Sorry, I was not addressing any issue of failing detectors, but rather just how to handle the in-transition, not-in-transition distinction for analyzing bias steps.
I'm looking at a lot of data where I took bias steps at 0.5 V steps from overbiased to superconducting, and I need a way to analyze that sensibly for different temperatures, UFMs ,and bias lines that all have different voltage ranges for what's "in transition". In that use case, always applying transition=True preserves the most important data, and the np.abs(R0) fixes the R0 values in the normal branch (and gives me Rn).

[yaqiongl]

We tried changing it so it's only using dIrat to tell if it's in transition.

I0=np.zeros(dIrat.shape[0])
I0_nontransition=Ib*dIrat
I0_transition=Ib * dIrat / (2 * dIrat - 1)
I0[np.where(dIrat>0)]=I0_nontransition[np.where(dIrat>0)]
I0[np.where(dIrat<0)]=I0_transition[np.where(dIrat<0)]

and it's still getting resonable taus

and rfrac:

We also use bias voltage (19V at 100mK) to drive detectors normal and do a bias step and this is the rfrac:

[msilvafe]

So do you think this is a good solution and we should just modify the code to use this login on the sign of dIrat?

[jlashner]

I think this looks great, if you post the modification as a PR I'll approve.

[kmharrington]

Chiming in here to comment that I've also run into this issue and have been just re-analyzing with transition=True.

But we really don't want "re-run the analysis" to be our method in the field so I would love to see some changes implemented before then.

[jlashner]

We were also having trouble with this on the LAT. This PR implements the code Yaqiong describes above, which appears to have fixed our problems, so hopefully this is no longer an issue.