Fix Version/s: None
Sprint:TSSW Sprint - Aug 02 - Aug 16
Team:Telescope and Site
The OFC xref currently has 3 options: x00, x0, and 0. I have observed with my test at NCSA that at least x0 does not work as expected. (It worked a couple of weeks ago. So I believe a recent change to the code affected this).
The working version of the test has a permanent link here (cells 54-110)
Here is a description of what should be expected:
when xref=x0, it means we are referencing the current positions of the DOFs for motion penalty. So if I add the same aberration twice, the visitDOF resulted from the first addAberration command should be equal to the visitDOF resulted from the 2nd addAberration command.
So, basically, I do
await aos.cmd_addAberration.set_start(wf = zernikes, config=config_yaml)
then check the event evt_degreeOfFreedom.visitDOF
then repeat the above, the two visitDOFs should be equal. But right now they are not (in the notebook linked above, they are. But not if I re-execute the notebook with the latest version of MTAOS)
when we set xref=x00, they will not be equal. If we compare individual DOFs, I expect the 2nd to be generally smaller than the first.
In case that you want to check xref=0 option as well:
my understanding is that if we have all zeros in dof_state0_filename, which is the default, the behavior should be the same as x00.
Note: This ticket is also used to fix the bug of butler change in the up-stream.
- is triggering
DM-31343 Fix donutStamps type error and pipeline error in latest version of stack
It looks like the change of scientific pipeline had failed the ts_wep already:
1. in develop branch, #52 succeeds:
2. In develop branch, #53 fails:
I discussed with Bryce Kalmbach for the failed ts_wep in upstream, and he is kind to help to try to fix the failed tests.
Please help to review the PR:
After the inspection, I think this bug comes from the ts_MTAOS instead of ts_ofc. The ts_MTAOS does not pass the xref to the ts_ofc.
Supported the xref in ts_MTAOS. However, there is a failed unit test of test_process_comcam from before. It can be reproduced by re-running the Jenkins test in develop branch. Need to investigate this.