Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: ts_main_telescope
-
Labels:
-
Story Points:1
-
Epic Link:
-
Sprint:TSSW Sprint - Aug 02 - Aug 16
-
Team:Telescope and Site
-
Urgent?:No
Description
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)
await aos.cmd_issueCorrection.set_start()
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.
Attachments
Issue Links
- is triggering
-
DM-31343 Fix donutStamps type error and pipeline error in latest version of stack
- Done
Activity
| Description |
When OFC is finished, the output would be published as {{MTAOS.logevent_degreeOfFreedom}}. These are arrays of 50x1. Then the next step is to convert these into corrections that can be sent to the components. For the mirrors, the {{MTAOS.logevent_XXCorrection}} should be in actuator forces. While for the hexapods, they should be dx,dy,dz,rx,ry in both cases. That is why I expect them to match.
These corrections should correspond to {{aggregatedDOF}} , not {{visitDOF}}. My EFD analysis seems to say it is {{visitDOF. (See below, cells 1-12)}} https://github.com/lsst-ts/ts_notebooks/blob/6aa43c715eefcb1731500f8e7b77d3fec46a092b/bxin/aos2comp/bug_addAberr_twice.ipynb |
The OFC xref current 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) [https://github.com/lsst-ts/ts_notebooks/blob/6aa43c715eefcb1731500f8e7b77d3fec46a092b/bxin/aos2comp/aos2comp.ipynb] 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 from the first addAberration command should be equal to the visitDOF from the 2nd addAberration command. So, basically, I do await aos.cmd_addAberration.set_start(wf = zernikes, config=config_yaml) await aos.cmd_issueCorrection.set_start() 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. |
| End date | 16/Jul/21 | 04/Aug/21 |
| Sprint | TSSW Sprint - Aug 02 - Aug 16 [ 1111 ] | |
| Start date | 13/Jul/21 | 04/Aug/21 |
| Description |
The OFC xref current 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) [https://github.com/lsst-ts/ts_notebooks/blob/6aa43c715eefcb1731500f8e7b77d3fec46a092b/bxin/aos2comp/aos2comp.ipynb] 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 from the first addAberration command should be equal to the visitDOF from the 2nd addAberration command. So, basically, I do await aos.cmd_addAberration.set_start(wf = zernikes, config=config_yaml) await aos.cmd_issueCorrection.set_start() 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. |
When OFC is finished, the output would be published as {{MTAOS.logevent_degreeOfFreedom}}. These are arrays of 50x1. Then the next step is to convert these into corrections that can be sent to the components. For the mirrors, the {{MTAOS.logevent_XXCorrection}} should be in actuator forces. While for the hexapods, they should be dx,dy,dz,rx,ry in both cases. That is why I expect them to match.
These corrections should correspond to {{aggregatedDOF}} , not {{visitDOF}}. My EFD analysis seems to say it is {{visitDOF. (See below, cells 1-12)}} https://github.com/lsst-ts/ts_notebooks/blob/6aa43c715eefcb1731500f8e7b77d3fec46a092b/bxin/aos2comp/bug_addAberr_twice.ipynb |
| Description |
When OFC is finished, the output would be published as {{MTAOS.logevent_degreeOfFreedom}}. These are arrays of 50x1. Then the next step is to convert these into corrections that can be sent to the components. For the mirrors, the {{MTAOS.logevent_XXCorrection}} should be in actuator forces. While for the hexapods, they should be dx,dy,dz,rx,ry in both cases. That is why I expect them to match.
These corrections should correspond to {{aggregatedDOF}} , not {{visitDOF}}. My EFD analysis seems to say it is {{visitDOF. (See below, cells 1-12)}} https://github.com/lsst-ts/ts_notebooks/blob/6aa43c715eefcb1731500f8e7b77d3fec46a092b/bxin/aos2comp/bug_addAberr_twice.ipynb |
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) [https://github.com/lsst-ts/ts_notebooks/blob/6aa43c715eefcb1731500f8e7b77d3fec46a092b/bxin/aos2comp/aos2comp.ipynb] 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 from the first addAberration command should be equal to the visitDOF from the 2nd addAberration command. So, basically, I do await aos.cmd_addAberration.set_start(wf = zernikes, config=config_yaml) await aos.cmd_issueCorrection.set_start() 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. |
| Description |
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) [https://github.com/lsst-ts/ts_notebooks/blob/6aa43c715eefcb1731500f8e7b77d3fec46a092b/bxin/aos2comp/aos2comp.ipynb] 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 from the first addAberration command should be equal to the visitDOF from the 2nd addAberration command. So, basically, I do await aos.cmd_addAberration.set_start(wf = zernikes, config=config_yaml) await aos.cmd_issueCorrection.set_start() 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. |
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) [https://github.com/lsst-ts/ts_notebooks/blob/6aa43c715eefcb1731500f8e7b77d3fec46a092b/bxin/aos2comp/aos2comp.ipynb] 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) await aos.cmd_issueCorrection.set_start() 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. |
| Status | To Do [ 10001 ] | In Progress [ 3 ] |
| Story Points | 0 | 1 |
| Description |
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) [https://github.com/lsst-ts/ts_notebooks/blob/6aa43c715eefcb1731500f8e7b77d3fec46a092b/bxin/aos2comp/aos2comp.ipynb] 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) await aos.cmd_issueCorrection.set_start() 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. |
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) [https://github.com/lsst-ts/ts_notebooks/blob/6aa43c715eefcb1731500f8e7b77d3fec46a092b/bxin/aos2comp/aos2comp.ipynb] 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) await aos.cmd_issueCorrection.set_start() 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. {color:#de350b}Note: This ticket is also used to fix the bug of butler change in the up-stream.{color} |
| Status | In Progress [ 3 ] | In Review [ 10004 ] |
| Status | In Review [ 10004 ] | Reviewed [ 10101 ] |
| Resolution | Done [ 10000 ] | |
| Status | Reviewed [ 10101 ] | Done [ 10002 ] |