analyze_iv() returns an incorrect (often VERY incorrect) v_bias_target. This means, for one example, that every "\<timestamp>_iv.npy" file produced by run_iv() (the standard iv-curve data-taking function) reports incorrect v_bias_target values.
To Reproduce
Steps to reproduce the behavior:
run analyze_iv_from_file(\<filepath to any "\<timestamp>_iv_raw_data.npy" with at least one legitimate IV curve>)
Load the resulting "\<timestamp>_iv.npy" file into a dictionary with ex. iv_analyzed = np.load(filepath, allow_pickle=True).item()
Def iv_leg = iv_analyzed[\<smurf band of legitimate iv curve>][\<smurf channel of legitimate iv curve>]
Observe that iv_leg['v_bias_target'] is incorrect; np.where(iv_leg['v_bias'] == iv_leg['v_bias_target'])[0][0] does not equal np.where(iv_leg['R'] == 0.007)[0][0]
Expected behavior
analyze_iv()'s v_bias_target for a given iv curve is supposed to be the bias voltage at which the TES was the resistance R_op_target (optional argument to analyze_iv_from_file() and analyze_iv(), default=0.007.).
Additional details
Once pysmurf calculates the R_tes values (stored in the local variable R inside analyze_iv()) of an iv curve, it finds the index of the largest value of R_tes less than the R_op_target it receives in the function call to analyze_iv (defaults to 0.007 Ohm). That index is i_R_op.
Then for the various "target" values (v_bias_target, v_tes_target, si_target) it goes through and and assigns them to be \<the array of that data>[i_R_op]. The problem is that it's using the wrong array for bias voltage in that assignment line; v_bias is the original v_bias array, not the binned and cleaned v_bias_bin from which pysmurf's R_tes values are derived. So it's putting an index correct for v_bias_bin into the much larger (and not time-reversed) v_bias array and getting a junk value. (Note that the "v_bias" returned from analyze_iv() is v_bias_bin, not v_bias. This naming confusion is likely the source of the bug).
This problem can thus be fixed by replacing the line "v_bias_target = v_bias[i_R_op]" with "v_bias_target = v_bias_bin[i_R_op]" in the analyze_iv() function in pysmurf/client/debug/smurf_iv.py. A simple find&replace of that text on the whole file will do this, no need to find the actual line.
Describe the bug
analyze_iv() returns an incorrect (often VERY incorrect) v_bias_target. This means, for one example, that every "\<timestamp>_iv.npy" file produced by run_iv() (the standard iv-curve data-taking function) reports incorrect v_bias_target values.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
analyze_iv()'s v_bias_target for a given iv curve is supposed to be the bias voltage at which the TES was the resistance R_op_target (optional argument to analyze_iv_from_file() and analyze_iv(), default=0.007.).
Additional details
Once pysmurf calculates the R_tes values (stored in the local variable R inside analyze_iv()) of an iv curve, it finds the index of the largest value of R_tes less than the R_op_target it receives in the function call to analyze_iv (defaults to 0.007 Ohm). That index is i_R_op.
Then for the various "target" values (v_bias_target, v_tes_target, si_target) it goes through and and assigns them to be \<the array of that data>[i_R_op]. The problem is that it's using the wrong array for bias voltage in that assignment line; v_bias is the original v_bias array, not the binned and cleaned v_bias_bin from which pysmurf's R_tes values are derived. So it's putting an index correct for v_bias_bin into the much larger (and not time-reversed) v_bias array and getting a junk value. (Note that the "v_bias" returned from analyze_iv() is v_bias_bin, not v_bias. This naming confusion is likely the source of the bug).
This problem can thus be fixed by replacing the line "v_bias_target = v_bias[i_R_op]" with "v_bias_target = v_bias_bin[i_R_op]" in the analyze_iv() function in pysmurf/client/debug/smurf_iv.py. A simple find&replace of that text on the whole file will do this, no need to find the actual line.