Daytime work to attempt to generate new reconstructors for DX KL_v27.

Log

20191030 (Wednesday)

Shane and I attempted to generate the ARGOS DX reconstructors today.

We followed the instructions from https://wiki.lbto.org/ARGOS/HowToPerformArgosCalibrations
We also used as reference the last work on reconstructors from January: https://wiki.lbto.org/ARGOS/DayTime20190115

We were able to generate a combined reconstructor using 10 modes (20191030_184200), which is located in
argos-dx-lgsw:/home/argos/nfs/calib/DX/aarb/aoloop/combined_rec/

This combined reconstructor was generated following the January process, i.e. from LGSW only (not FLAO).

When we tried to close the loop to test it (TT only at first with gain 0.5), we would get right away a very strong tilt in the mirror which moved the LGS and NGS off their nominal positions. The tilt is so strong that the mirror safe skips, and after a while the loop opens, getting the cal lights back to their positions.

Clearly the problem is with the TT part of the Reconstructor, but we don’t know why.

By the way, we also noticed the following in the AArb log window:

2019-10-30 21:32:27.928349005 NOTICE IcePyramidWfs: Setting true modes basis to KL_v27
2019-10-30 21:32:56.997876266 WARNING OperatorLog: Truth sensor loop failed: 'exception ::AODefs::AOException
2019-10-30 21:32:56.997876266 WARNING {
2019-10-30 21:32:56.997876266 WARNING code = -1
2019-10-30 21:32:56.997876266 WARNING what = [AOException] Cannot load matrix for modal basis KL_v27 (code -3028) Error in key management
2019-10-30 21:32:56.997876266 WARNING }'

We assumed that the problem here is that we did not have copied over the new v27 FLAO reconstructors and updated the conf files (table_LUCIFER_ARGOS_TRUTH.txt, table_LUCIFER_ARGOS_TT.txt and truesense.conf) with v27 entries, as per https://wiki.lbto.org/ARGOS/HowToBuildFlaoAndTrueSensRecsForArgos

Comparing with the January notes, we realized that the changes we made were in the /home/argos/confcalib/ directory, and that the Makefile.argos did not work, as the working directories (in /home/argos/aoroot/) did not contain the new files, so we copied them by hand.

We restarted everything and we still get the “Cannot load matrix for modal basis KL_v27” exception.

At this point we are giving up, as we are getting close to handover.

20191031 (Thursday)

Running from argos-dx via X2go on rm507-3 (Remote Observing Room machine), as first try to run the system this way instead of through vnc connection directly to dx-lgsw.

Following instructions from https://wiki.lbto.org/ARGOS/HowToPerformArgosCalibrations

Set the slope offset to zero:

In [32]: argos.lgsw.controller.setSlopeOffsetTag('zero')

Close jitter stabilizer loop and save the current position as "Initial position" in the "Calibration" tab in the LGSW controller GUI: 20191031_210953

Perform InteractionMatrix (IM) measurement.

In [33]: from argos.arbitrator.aoloop import acquire_lgsw_interaction_matrix

In [34]: lgswIM = acquire_lgsw_interaction_matrix

In [38]: imacq = lgswIM.AcquireLgswInteractionMatrix(argos.aarbCalibrationManager, lgsw.calibrationManager, argos.adsec, argos.lgsw.controller, argos.lgsw.controller.getActualSubaperturesDefinitionTag(), argos.lgsw.frameBuffer.isWfsCameraUpsideDown(),'20191030_184100', '20191030_170800', argos._logger, argos)
In [44]: im= imacq.acquire(gain=0)

Operation fails. Several errors related to failed connections. For example:

2019-10-31 21:25:37.606821055 ERROR DX_terminal argos-dx:24984.7f0c3ed2e740 argos /home/argos/apps/lib/python/site-packages/argos/util/executor.py:143 _printStackTraceInCaseOfError [snapshooter: Task '<bound method Snapshooter._snapshotTIPTILTController of <argos.snapshot.snapshooter.Snapshooter object at 0x666ac10>>' failed: ConnectionRefusedException:]
2019-10-31 21:25:37.606821055 ERROR DX_terminal argos-dx:24984.7f0c3ed2e740 argos /home/argos/apps/lib/python/site-packages/argos/util/executor.py:143 _printStackTraceInCaseOfError [Connection refused]

20191101 (Friday)

Restarted from scratch. Attempting DX KL_v27 reconstructors again, from argos-dx via X2go.

Set the slope offset to zero:

In [32]: argos.lgsw.controller.setSlopeOffsetTag('zero')

Close jitter stabilizer loop and save the current position as "Initial position" in the "Calibration" tab in the LGSW controller GUI.

Got the following error:

2019-11-01 19:07:14.2019-11-01 19:07:14.884637998 NOTICE:LGSWCtrl [controller: Got request to save jitter stabilization loop actual position as initial position]
2019-11-01 19:07:14.890103404 NOTICE:LGSWCtrl [controller: Cannot save jitter stabilization loop actual position as initial position in this state]

Jitter stabilizer initial position is still 20191031_210953

Moving forward with instructions.

from argos.arbitrator.aoloop import acquire_lgsw_interaction_matrix

lgswIM = acquire_lgsw_interaction_matrix

imacq = lgswIM.AcquireLgswInteractionMatrix(argos.aarbCalibrationManager, lgsw.calibrationManager, argos.adsec, argos.lgsw.controller, argos.lgsw.controller.getActualSubaperturesDefinitionTag(), argos.lgsw.frameBuffer.isWfsCameraUpsideDown(),'20191030_184100', '20191030_170800', argos._logger, argos)

im imacq.acquire(gain=0)=

No error this time.

Work through from argos-dx via X2go is very slow. Switching to direct vnc into argos-dx-lgsw.

Going again through the previos commands in new ARGOS terminal window. Final result is:

2019-11-01 20:23:47.140478642 NOTICE DX_terminal dx-lgsw:31080.7f4c49359700 argos /home/argos/apps/lib/python/site-packages/argos/arbitrator/aoloop/acquire_lgsw_interaction_matrix.py:163 acquire [argos terminal: Saving LGSs interaction matrix 20191101_202338]

im.displayShift(np.arange(6))
im.generateInteractionMatrix(shift= 3)
im.displayIM()

rec = im.createReconstructorObject(np.arange(10))
argos.aarbCalibrationManager.saveAoLoopLgswReconstructorMatrix(rec, '20191101_202338')

Following now with https://wiki.lbto.org/ARGOS/HowToDoAPerformanceCheckOnNewRec
np.diag(np.linalg.pinv(np.dot(im.getInteractionMatrix().T,im.getInteractionMatrix())))*(1e9)**2

Out[10]:
array([ 369835.8768576 , 279001.8149596 , 137457.80388896,
71736.82038217, 184460.91427667, 80445.43141488,
77260.4091721 , 47467.80673912, 50381.80839678,
44965.44142648, 0. , 0. ,

I don't know how to interpret these numbers.

Next we are supposed to try closing the loop applying disturbances. But there are no AO loop disturbances yet for KL_v27. Last ones for DX are for KL_V22, at least according to this table: https://wiki.lbto.org/ARGOS/AoLoopDisturbances

It is time for handover. Stopping here.

-- GustavoRahmer - 31 Oct 2019
Topic revision: r3 - 12 Oct 2020, GustavoRahmer
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback