Virgo Logbook

AdV-TCS (Wavefront sensing)

bersanetti, lumaca, nardecchia - 23:35 Tuesday 07 March 2023 (59172)

HWS-DET compensation measurement on NI CP w/ automation

Since the activity performed in the afternoon about the realignment of the INJ SLED (59170) needs to be completed, we decided to start the HWS-DET compensation automatic measurement on NI CP.

After some preliminary tests performed by Diego, at 19.35 UTC the automatic HWS-DET compensation measurement started.

We checked the firsts actions performed by the automation:

19.35 UTC all the CO2 actuators were switched OFF to cool down the ITMs before the measurement (Fig. 1)
21.34 UTC (2 h after) the HWS DET acquisition was started (folder 20230307T2234 created; num ref img = 100, num live img = 100, time sleep = 80 sec, num live loops = 200)
21.44 UTC CHs ON (Fig. 1 for the opening of CHs flip mirrors and Fig. 2 for the 1° and the 20th WF, in which NI CH curvature start to appear)

In Fig. 1, the reduction of the power visible in channel “TCS_WI_CO2_POWER_CH_PICKOFF_mean” immediately after the flip mirrors were open, was an action performed manually, to restore the current value of WI CH (= 0.065 W), that was previously raised up to 0.165 mW to ease the HWS-INJ SLED beam re-alignment attempt. It will not affect the HWS-DET compensation measurement since it involves the WI TM.

The automatic HWS-DET compensation measurement will continue during the night. The data will be checked and analyzed in the morning.

Images attached to this report

Comments to this report:

bersanetti - 3:00 Wednesday 08 March 2023 (59173)

Unfortunately, the measurement stopped at 23:42 LT after generating Wavefront 29, at the level of the HWS software called by the hwsAna.py script. The recently introduced logfile shows the error:

Traceback (most recent call last): File "/virgoDev/TCS_HWS/Python/HWS_ANA/v3/hwsAna.py", line 310, in generateCentroid(workDirProbe,1,nRef , workDirProbe, 1, nLive,livePrefix, workOut,co unt); File "/virgoDev/TCS_HWS/Python/VIRGO/HWS/HWS_Run.py", line 131, in generateCentroid hsi_live.read_image() File "/virgoDev/TCS_HWS/Python/VIRGO/HWS/HS_Image.py", line 333, in read_image self.read_and_average_frames() File "/virgoDev/TCS_HWS/Python/VIRGO/HWS/HS_Image.py", line 439, in read_and_average_f rames raise Exception('There are no image files to read: ' + self.location + self.fprefix) Exception: There are no image files to read: /data/tcs/buffer/test/HWS-RC/DET/20230307T2 234//probe/0030clive

It doesn't look like a filesystem space issue, as df -h shows:

nfsvols1:/tcs 8.0T 4.8T 3.3T 60% /data/tcs

A more detailed history of the log content is attached: it seems that the failure happened when trying to generate 0029liveCentroidsPy.dat (lines 132-135); wavefront 29 is generated (incorrectly?), then wavefront 30 fails as the "30"-prefixed images are not present, as reported from the Traceback above.

I left the automation end the measurement anyway. Metatron-wise, the logic is working as in the stripped down tries done earlier in the evening; the full sequence is reported in the Figure: channels of interest are the indexes of the relevant Metatron nodes, the Metatron channels pertaining to the Compensation measurement and the use of the DET HWS, and the status of the flip mirrors for the NI TCS actuators.

The timers shown by the ITF_LOCK GUI are still a bit imprecise, as the node implies them from the TCS_MAIN.ini configuration file without tracking each step of TCS_MAIN; in any case, TCS_MAIN shows the correct ones by definition, and the state transitions are driven by successful state requests, not timers.

An improvement, which takes into account also the timer for the HWS initialization, has been already uploaded.

I left the ITF in LOCKED_ARMS_IR (the flip-down of the CH has been uncommented).

Images attached to this comment

Non-image files attached to this comment

PyHWS.log.txt

ballardin - 14:16 Wednesday 08 March 2023 (59176)

How we can see by the file log of the entry #59173 the problem is linked to the use of "take" application ("Unable to configure ring buffer"). This application is bundle with the libray (ETDpdv) provided by the firm of the phase Camera. It's not easy to know what is the cause of this failure: can be a problem in the cable, or inside the camera(?), or inside the application itself. As I proposed during a dedicated meeting, we can try to replace "take" with a "simple_take" that I modified to generate "raw" file as well as the "take" application does. If this application will fail too, we can try to update the library EDTpdv. But to better understand the problem, should be know if this kind of failure is proper of only a system or it's a common problem to all systems.