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.

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.

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.


Telescope time booked for the NIKA Dry run test:

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 (2nd 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.

Problem number (origin)

Description of the problem


How to identify & diagnose the problem

How to investigate and possibly solve the problem

1 (NCS)

Some scans miss part(s) of the antenna traces.

Pandemic during pool 1 (run 8, Feb 2014), but marginal after mrt-lx1 kernel update by GP; to be verified as goal #1 of this dry run.

Monitor time vs sample number of antenna traces.

Monitor network & mrt-lx1 activity.


KID parameter coded in IMBFITS mismatch the data (e.g. numbers of KIDs) - fatal error.

Partially solved: AS's IMBFITS making script should now read the NIKA Kidpar, but we miss a description of the Kidpar by the NIKA team.

Compare at least the number of KIDs in the IMBFITS and of the hardware, e.g. with any FITS viewer.

Need better communication between NIKA team (FXD ?) & IRAM (AS, SL, RZ).

3 (IMBFITS or NCS ?)

Mis-synchronization of subscans in the IMBFITS tables: some subscans are incomplete and partially appear in the following subscan table - fatal error.

This problem appeared first time in IMBFITS of run 6; not solved; it is due to a synchronization problem in NCS and/or IMBFITS creation.

Check subscan length in IMBFITS, e.g. with any FITS viewer.

Check the time used as subscan start and end, delay of NCS messages ...

4 (NIKA)

NIKA FITS do not correspond to the time interval of observation.

Permanent problem since the first try in Oct 2010; not solved.

At least the last subscan missing. Visible with any FITS viewer.

Creation of the NIKA FITS (in IDL ?) not OK.

5 (NIKA)

NIKA tables in IMBFITS empty.

Permanent problem since the first try in Oct 2010; not solved.

Visible with any FITS viewer.

IMBFITS created offline do not show this problem, i.e. NIKA FITS were not available when makeIMBFITS was called in auto mode.

6 (NIKA)

IMBFITS are created many minutes after the observation, e.g. after 2 further pointings !

Permanent problem since the first try in Oct 2010; not solved.

Compare the end time of observations and of creation of IMBFITS; the last takes seconds.

#5 & 6 point to a significant delay in creation of the NIKA FITS.

7 (NIKA)

KIDs flags & types wrong (good/bad KID mis-identified).

Solved after run 8 on NIKA side. Need to be double checked.

Create IMBFITS with updated/correct flags and match KID characteristics with flag & type signification.

Need detailed documentation on the KID params.

Anyone interested in the file sizes of the antenna streams can take a look at the continously updated plot created by PM:

Step by step guide for the Dry Run

Hardware preparation

Data acquisition

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> @ cont_pointing
PAKO> @ cont_focusZ -1.8
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:

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.

s148_rf-pf s160_rf-pf s148_rf_pf_rms

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

Other info from the NIKA team:

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 show 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 !

oscil_azOff1 oscil_azOff2

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.

Continuum/PoolOrganization/DryRunNIKA (last edited 2014-11-18 10:54:14 by NikaBolometer)