NIKA dry run: organization, observations and results

Go back to the NIKA main wiki.

Goals of the run

1. Check that gaps in NCS data streams do not occur
2. Debug the IMBFITS formating so that they are at last produced without errors, and finally allow real time processing.
3. Test for the first time operations with only IRAM Granada personnel at the Telescope and NIKA Grenoble team using remote control.

Organization Plan

The dominant components of the goals 1 and 2 do not necessitate sensitive KID, so no cool down of the instrument is necessary. However the full instrumental setup for observations must be operational; this includes the electronic chain and real scans of the telescope commanded via PaKo.

• Remark: We could test the new network cabling installed in the cable spiral room for the future control of the NIKA2 compressors, keeping the electronics at its storage location and making it run to control the detectors acquisition via the network from there. But we have decided to lift it up in the cabin hence mimicking real observations as much as possible with a warm cryostat, since the problems we had may be related to the network setup we used.

We will debug the IMBFITS step by step. People involved in the NIKA data & IMBFITS making & checking (Albrecht, Juan MP, Xavier, Alain, Robert, Samuel, and possibly Walter and Nicolas P) communicate via this wiki page to establish very clearly the main problems and actions to do to solve them (see tables below), and possibly use the data we currently have to start debugging, so that we are as ready as possible for May 7.

• Remark: We need confirmation that the warm KIDs with the observation setup planed for this dry run will produce usable (in math. sense) values, otherwise this might cause somewhere problems.

After this dry run, we will make the status, and determine a date for another short test run (e.g. begin of June ?). Hopefully for this one only the problems that necessitate valid KID data remain (e.g. KID flags). In that case this short run would be cold.

Dates

Telescope time booked for the NIKA Dry run test:

• Wednesday May 7, from 11:00 to 15:00.
• Monday May 12, from 12:00 to 16:00.

They appear in the official telescope schedule under the project name is T21-13.

Table of IMBFITS problems to solve

The NIKA IMBFITS have had problems since their first creation (2^nd test run, Oct 2010). The latest exhaustive list of problems dates from the run 6 (June 2013) processing and has been tabulated on a dedicated wiki page; most of them are still valid. For reading convenience we gather here only the most important problems that need to be solved with the May 7 dry run.

• Remark: Note that problems 4, 5 & 6 are most probably related.

Anyone interested in the file sizes of the antenna streams can take a look at the continously updated plot created by PM: https://mrtweb.iram.es/plotAmd/

Step by step guide for the Dry Run

Hardware preparation

• Installation of the NIKA electronics at the receiver cabin (done).
• Switch on the electronics (done).
• Installation of the computers at the control room?

Data acquisition

• NIKA team

  • Start the software (Tue 6th before the system check)

• IRAM computer group

  • The nikaw-13 computer account will be used for the observations.
  • The NIKA team must inform us about the software that we need to run.
  • Installation of AB's Elvin and NCS monitor software?

Data reduction

In order to mimic as much as possible a typical NIKA session the online pipeline must be running. The instructions to start the online pipeline and to reduce the data can be found here.

Observing session

The observations will be done using the account created for the 1st NIKA pool:

$ ssh -X nikaw-13@mrt-lx1 (ask I. Hermelo for the password)

The operator has to set the project name to nikaw-13. To open the PaKo version for NIKA type:

$ gopako
$ pakodisplay
$ pakoNIKA

Once PaKo is open, you can run the following script:

PAKO> @ observe_DryRun

The script simulates a typical NIKA session of ~2 hours of duration:

PAKO> SET PROJECT t21
PAKO> SOURCE Uranus
PAKO> @ cont_pointing
PAKO> SET POINTING 5 5
PAKO> @ cont_focusZ -1.8
PAKO> SET FOCUS -1.5
PAKO> SOURCE 3C454 /cat *
PAKO> @ cont_onthefly 10 20 0 -45 
PAKO> @ cont_onthefly 10 20 0 +45 
PAKO> @ cont_lissajous 2 
PAKO> @ cont_onthefly 10 20 45 -45
PAKO> @ cont_onthefly 10 20 45 +45 
PAKO> @ cont_lissajous 4  
PAKO> @ cont_onthefly 10 20 90 -45  
PAKO> @ cont_onthefly 10 20 90 +45  
PAKO> @ cont_lissajous 6
PAKO> @ cont_onthefly 10 20 135 -45  
PAKO> @ cont_onthefly 10 20 135 +45
PAKO> @ cont_lissajous 8

Debriefing of the run

Wed 7th May

1. NIKA electronics was plugged few days beforehand. Data were obtained a day before the run without problems
2. Usual setups at the start took 2 hours to work (ssh keys are changed, data place on computer, acquisition computer X33, imbfits generator with nika_filing)
3. Telescope got stuck for a computer reason for half an hour
4. Nothing significant in data delays. Some singular errors : a few holes in the mjd from the antenna. Typically 5-6 errors during the 4 hours.

5. Standard series of scans logged on Tapas (Issue: Tapas does not list the on-the-fly scans)

6. After that trial period, the last 1h30 went smoothly
7. Running acquisition software at 60 Hz (instead of 29) without pointing errors (although the nika files are full of 0). Daemon on mrt-lx1 to acquire antenna pointing is running smoothly.
8. Plan for Monday second dry run is to do the whole thing again to check against accumulating errors if any and have another statistics on holes in the antenna data.

9. Who are the contacts at Neel ? Do we miss documentation on how to set-up the software by IRAM staff ? <CK> It is not foreseen that NIKA software can be started by IRAM staff. For NIKA2, we'll try to make an automatic start system for IRAM staff to operate. For NIKA, remote operations by Neel team are required. I'd suggest to start writing instructions for IRAM staff already for NIKA, as it allows to gradually increase knowledge, awareness, and also some responsibility. It also allows to eventually create a good useful NIKA2 documentation. <CK>

10. Was the NIKA pipeline running during the observations (point 1.5.3) ?

Mon 12th May

1. The run was prepared and tuning was done at the beginning. Having zeros in the data was corrected by resetting the NIKEL boxes at scan 130.
2. Antenna got stuck. Fixed after reboot of vac1 and go_kill. One hour lost.
3. Really useful data acquired at scan 138. See Tapas
4. Data acquisition set at 79.5 Hz to stress the new Mac computer! Errors appear only in the ethernet input buffer if interactive use of Mac (by changing the window size with the mouse for example scan 147).
5. No antenna datastream error after scan 139!
6. First glance at IMBFITS: They are created with readable data (no apparent corruption, real values in the tables). But data is missing at the end of the Lissajous scans (0.1sec to 1min missing). There's only 1 (track) focus and 1 (cross) pointing; they are readable but we miss 1/3rd of the 1st subscan. 3 apparent problems: noise increase with resonance frequency (explained), delay between subscans too short, instabilities in one data parameter; more explanations on these problems will be given in the coming days, after a deeper analysis.

7. Was the NIKA pipeline running during the observations (point 1.5.3) ? IH Yes, it was running on the mrt-lx8 computer

Some conclusions from the imbFITS analysis (RZ, SL)

Data availability:

• TAPAS still shows only the Lissajous. It's about time to correct this problem and display the other type of scans (zig-zag OTF, (track) focus, (cross) pointing, etc.) !

• Available as imbFITS are just 3 maps, 1 pointing and 1 focus, 0 skydips, all the rest (41!) are Lissajous; i.e. the current data allow statistically relevant investigation only for Lissajous. However, there is only 1 (!!) imbFITS which does not show errors => still problems in the transfer of NIKA data into IMBFITS.

• Scans missing: 20140507s151: corrupted because NIKA frequency changed; 20140512s124: aborted because of a system restart, 20140512s130 to 20140512s135: reseting NIKEL boxes, and then telescope got stuck.

• NONE of the 3 Zig-Zag OTF maps (May 7, May 12 - no maps) is OK ! Scans 144 and 145 have empty NIKA data tables, scan 142 has empty NIKA data table for the 10 last subscans; why ? See "Other info from the NIKA team" below

• The focus scan (20140512s168) has 47% of NIKA data missing in the first subscan, all Lissajous show missing data at the beginning and/or the end of the subscan; the number of missing records vary from a few to thousands, i.e. from a fraction of a second to a minute; why ? Answer from FXD: At about 29 Hz, a 10 second subscan should have about 300 samples which is the case for most subscans except the first and the last ones. For the first subscan, it was decided at the beginning of the open pool to have a final tuning at the beginning of the 1st subscan. That explains that we loose 3 seconds of the first subscan. Nothing we can do or want to do about that. For the last subscan, we trig the subscan valid data on the subscan status = 5 (ie subscan done). But this does not exist for some reason on the last subscan, hence we throw the last subscan away... This could be investigated on your side ? Complement from AB: if the resonances have moved a lot, several tones sweeps are necessary, one sweep takes up to 3 seconds, up to 5 sweeps may be necessary, in general only 1 is enough, and if the tones are already on resonance we may have no data loss on the 1st subscan.

• The pointing scan (20140512s167) is the only file readable by MOPSIC without error messages !
• For comparison: 167 EMIR imbFITS with freq. of slow loop = 8Hz do not show any such problem ! Unfortunately this sample is also Lissajous dominated: 0 maps, 19 pointings, 6 foci, 2 skydips, 4 tracks AND 124 (!!) Lissajous; the rest are calibs.

Look at the signals obtained with the warm system (NIKA specific):

Few plots to demonstrate the difference between RF & PF. RF is always shown in white, PF in green.

Although the relation between RF and PF does change, it can be said that:

• RF is much noisier and more unstable than PF, why ? See "Other info from the NIKA team" below

• The noise increase towards large pixel numbers is much more moderate in PF than in RF; for the pixels with small numbers RF & PF agree very well, why ? Answer (NIKA team): This is normal that the noise is high and increase with the pixel number because the instrument is warm and the losses in the cables increase with the tone frequency, so the signal on the high number pixels is lower than on the low number pixels. Normally this effect is reduced when the temperature is low and in addition the NIKEL electronics is set to send more power at higher frequency to compensate for the remaining loss. For the dry run the electronics was set with identical power for all the tones.

• Unfortunately PF WAS OFTEN NOT CALCULATED, i.e. is 0 for all pixels, why ? See "Other info from the NIKA team" below. Further, for such comparison it would be of course better if PF was calculated for all pixels, not just for those defined as "good".

Other info from the NIKA team:

• There is some losses in the NIKA raw data due to the warm setup which increase the work of the auto-tunning script plus the high load on the acquisition computer. Apparently there's no holes due to antenna problems. Not clear yet what is the dominant cause of the data losses you mentioned, this require a more careful analysis of the NIKA raw and monitoring scripts run for this test.
• Also the creation of the IMBFITS for a 60 seconds scan acquired at 30Hz takes 20 seconds after the end of the scan. Clearly longer than we would like, but probably sufficient to envisage on line processing.
• The NIKA team doesn't think much analysis can be done with the warm data; several tests were done during the acquisition to check effects of loading the acquisition computers and network. The holes in raw or pre-computed data (RF, PF) may have happened during these tests, RF might be noisier with warm data due to division by zero in its calculation, and so on.

Look at the tracking behaviour (Telescope specific):

The plot below shows the velocity in azimuth in white. Small oscillations demonstrate the telescope tries to reach the commanded coordinates, the big oscillating change of level is the transition trajectory phase between subscans. The red line shows the beginning of a subscan, i.e. backOnTrack=DATE-OBS, the green line marks the end of a subscan, i.e. DATE-END in the imbFITS. The small red dots among the white dots of vAzim show the points which are synchronous with a slow loop coordinate (e.i. 8 Hz red dots among 128 Hz white dots from the fast loop coordinates). Note that BOTH DATE-END AND DATE-OBS ARE SOMETIMES CORRECTED BACKWARDS FOR THE TIME DELAYS IN THE SYSTEM (problem known since 2007).

Very problematic: The time between the subscans is very often below 1sec and never even 2sec. This means that antMD "requires" not even 1sec to change the scanning direction in azim when scanning with 40arcsec/sec. No wonder that the consequences of this, i.e. the oscillations, are within the map. The amplitude of these oscillations may reach even negative values for required positive vAzim and vice versa, i.e. the coordinate offsets in the scanning direction may go BACKWARDS, thus the actual offsets may not be monotonically increasing/decreasing with time ! This has of course severe consequences for the data processing. Note further that these oscillations do not have the frequency of the slow loop, i.e. of the calculated source position.

This problem is known for a couple of years already, i.e. is not specific to the slow loop with frequency >1Hz.

In coordinate space the amplitude of these oscillations may reach values >HPBW, with max. values even above 30 arcsec ! Two example are shown below. These figures shows further that at the start of a subscan the tracking deviation given by antMD (in blue) DOES NOT CORRESPOND to the tracking deviation calculated using the encoder azimuth (in white). It means that for ~2sec the tracking values do not refer to the source position !

In an interval of ~scanningVelocity*2sec after the backOnTrack the coordinates are therefore incorrect. This is visualized in the example below.

This problem is probably due to a programming error in antMD: the examples above show that at least 2 seconds are necessary between subscans before the telescope can follow the commanded coordinates (in NO WIND conditions !). The program must have been written considering that the slow loop would always be at 1 Hz and thus used simply min. 2 slow loops to define the transition trajectory. But with the 8Hz using 2 slow loops is not sufficient.