pysmurf-controller: Update sodetlib version to v0.6.0

[dpdutcher]

• In this release of sodetlib, bias_to_rfrac(_range) have been merged
• Remove default rfrac value and if/else from pysmurf_controller

Description

This increments the sodetlib version to v0.6.0, which among other changes contains the following:

Use dev cfg for biasing, biassteps, bgmap. Remove fit_tmin kwarg (simonsobs/sodetlib#479)

• Combine bias_to_rfrac and bias_to_rfrac range, with default value 'rfrac' in dev config
• Put bias_step and bg_map parameters in cfg file, similar to take_iv
• Moved dc_voltage param out of take_bgmap and into take_bias_steps
• Make fit_tau optional in bsa.run_analysis
• Deprecate fit_tmin kwarg in bsa.run_analysis, instead determining tmin per-channel from the data
• Edits to doc strings

Motivation and Context

The time constant fitting method needed fixing for UHF detectors, as described on Confluence here

Other changes move parameters from function calls into the device configuration file, to make the interface more similar to sodetlib.operations.take_iv, allowing special values to be passed without requiring custom lines in the scheduler.

To facilitate this, bias_to_rfrac and bias_to_rfrac_range have been merged into one function in sodetlib, and the default value of (0.3, 0.6) is now taken from the device config. The default value in the pysmurf_controller, and the if/else statement deciding which of these functions to call, have been removed.

Resolves #951.

How Has This Been Tested?

I've tested bg_map, biasing, and bias_steps on an LF UFM in the Princeton testbed. I've tested analysis of historical bias step data from MF and UHF lab data, and UHF in-field data with and without a spinning HWP.
All worked as expected.

I've implemented and tested my changes of merging bias_to_rfrac and bias_to_rfrac_range, again in the Princeton testbed, on an MF UFM. It pulls from the dev cfg correctly, and the user can pass confused calls like bias_to_rfrac(S,cfg, rfrac=(0.3, 0.6)) or bias_to_rfrac_range(S, cfg, rfrac=0.5) and those still work, too.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[BrianJKoopman]

Thanks for the PR!

Just one question about how the system behaves now that the default has been removed.

[BrianJKoopman]

Looks good to me. Thanks again for the PR!