NIKA dry run organization

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

The following figure shows the sky at the beginning of the first slot of the NIKA Dry Run.

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 (Minor 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 documentation. <CK>"

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. Telescope reboot. One hour delay.
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!