Differences between revisions 156 and 205 (spanning 49 versions)
Revision 156 as of 2017-02-05 20:42:59
Size: 8439
Editor: PabloGarcia
Comment:
Revision 205 as of 2017-10-23 09:41:01
Size: 8643
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
#acl hermelo,CarstenKramer,NicolasBillot,SamuelLeclerc:read,write,delete,revert,admin Default #acl PabloGarcia,CarstenKramer,SamuelLeclerc:read,write,delete,revert,admin Default
Line 13: Line 13:
To start the Pako session for rgular obsevations, log into the pool account "t22" (ask the AoD/operator for the login information), To start the !PaKo session for rgular obsevations, log into the pool account "nikas-17" (ask the AoD/operator for the login information),
Line 17: Line 17:
$ ssh -X t22-lx1 $ ssh -X nikas-17-lx1
Line 19: Line 19:
$ pako> @ini
$ pako> show ! v1.2.3 2014-03-31 (to confirm the correct Pako version is being used)
$ pako> set doSubmit YES
}}}

Now you are ready to start observations. An alternative Pako version for scans with more than 100 subscans can be used
by starting the Pako session with the following commands:

{{{
$ source goPaKo300
$ pakodisplay
$ pako
$ pako> @ini
$ pako> show ! v1.2.5 2016-05-18 (to confirm the correct Pako version is being used)
$ pako> set doSubmit YES
}}}
$ PAKO> @ini
$ PAKO> set project XXX
$ PAKO> set doSubmit YES
}}}

Now you are ready to start observations.
Line 54: Line 44:
Open a terminal and type: To have the IDL pipeline continuously processing observations as they are produced, open a terminal and type:
Line 59: Line 49:
IDL> auto_nk_rta
}}}

It is also possible to reduce the scans manually:

{{{
Line 67: Line 51:

where scanID is the corresponding identifier of the observation (as shown in the example) in the format YYYYMMDDsXXX, where
YYYY is the year, MM the month, DD the day, and XXX the scan number.
Line 75: Line 62:
$ ssh -X mrt-lx3
$ xephem &

}}}

Then, click on the tab "View" and open the "Sky View". The "cross hair" shows the coordinates the telescope is pointing at.
$ ssh -X mrt-astro1 xephem
}}}

Note: if for some reason this command doesn't work, do ssh on mrt-lx3 then type useNCS and azElToXephem.py before launching Xephem in order to see the telescope.

Then on the Xephem window
, click on the tab "View" and open the "Sky View". The "cross hair" shows the coordinates the telescope is pointing at.
Line 91: Line 79:
PAKO> source 0133+476 /cat iram-J2000.sou PAKO> source 0133+476 /cat * (or "iram-J2000.sou" or "pointingIRAM30m.sou")
Line 100: Line 88:
where the keyword "mode" can adopt the values '''b''' for bright sources, '''f''' for faint sources or '''l''' for very faint sources that require the Lissajous pattern.

Once the pointing is finished, enter the new pointing corrections in azimuth (PnewX) and in elevation (PnewY) shown in the NIKA2 pipeline:
where the keyword "mode" can adopt the values '''b''' for bright sources and '''f''' for faint sources (the '''l''' option for very faint sources
that require the Lissajous pattern is no longer used). The pointing scans are currently reduced by the IDL pipeline. To obtain the pointing
corrections, process the corresponding scan with the pipeline: "IDL> nk_rta, scanID". Once the pointing scan is processed, enter the new pointing
corrections in azimuth (PnewX) and in elevation (PnewY) shown on the IDL prompt of the NIKA2 pipeline:
Line 111: Line 100:
The focus needs to be monitored and it needs to be corrected online!
This should be done every three hours or so in the Z direction and every 24 hours in the X and Y direction.
To check the quality of the focus along X, Y or Z (i.e., the three axes of the subreflector), type:
The focus needs to be monitored and it needs to be corrected online. This should be done every two hours or so (~3h during very stable night time condition, ~1h or less near sunrise and sunset) in the Z direction. To check the quality of the focus run:
Line 119: Line 106:
Once the focus is finished, enter the new focus value (Fnew) shown in the NIKA2 pipeline:

{{{
PAKO> set focus Fnew /dir axis
}}}
where axis is z (or x,y)

Same thing in x and y directions

{{{
PAKO> @ focusOTF-X fx
}}}

{{{
PAKO> @ focusOTF-Y fy
}}}

 
   
== Beam map (needs to be updated once we have an standard procedure) ==

The beam map consists in 3 ?'x?' maps with ~?" steps between rows and a duration ~?? minutes. Beam maps are designed to ensure the source is moved over all the detectors of the array, in order to characterize and calibrate them (field of view geometry, flat field, stability...). The aim is to calculate the actual pixel offsets in the focal plane (see figure below). To obtain a beam map go to a primary calibrator and launch the '''beammap.pako''' script:

{{{
PAKO> @ beammap
}}}


== Skydips (needs to be updated once we have an standard procedure) ==

To run a skydip with NIKA type in !PaKo:

{{{
PAKO> @ skydip_DYI
}}}
Currently, this script will carry out 5 foci measurements in Z direction within a 1.6 mm range, centered at the fz value. In order to obtain the focus corrections, the corresponding scan number have to be processed by the IDL pipeline:

{{{
IDL> nk_rta, scanID1 (for measurement 1)
IDL> nk_rta, scanID2 (for measurement 2)
IDL> nk_rta, scanID3 (for measurement 3)
IDL> nk_rta, scanID4 (for measurement 4)
IDL> nk_rta, scanID5 (for measurement 5)
}}}

Then, all measured foci need to be processed together by the "nk_focus_otf" routine of the IDL pipeline to perform the best focus fit in terms of the measured Flux, beam FWHM, and beam ellipticity of the KID's. This can be achieved by running the following instruction in the IDL prompt:

{{{
IDL> nk_focus_otf,'YYYYMMDDs'+strtrim(SCANNUMBER+indgen(5),2)
}}}

where the ScanID is in the format YYYYMMDDsSCANNUMBER (e.g. '20151019s132'). Once the "nk_focus_otf" routine has finished, check the focus correction
values displayed in the IDL prompt under "Fluxes" for the three arrays (A1, A2, & A3) and calculate the average value that will be used to correct the focus.
Enter the new focus value (Fnew) as follows:

{{{
PAKO> set focus Fnew
}}}

== Beam map ==

This kind of scan is to be done once a day or every two days. It takes ~25 min, so to avoid accounting the time spent to your project think about changing the project to:
{{{
PAKO> set project nikas-17
}}}

Beam maps are designed to ensure the source is moved over all the detectors of the array, in order to characterize and calibrate them (field of view geometry, flat field, stability, etc). The aim is to calculate the actual pixel offsets in the focal plane (see figure below). To obtain a beam map go to a primary calibrator and launch the '''beammap1scan99sub.pako''' script in the normal !PaKo session:

{{{
PAKO> @ beammap1scan99sub (to produce 99 sub-scans, standard PaKo version)
OPTION = a (ENTER OPTION: a = Az. scan, e = El. scan, l = lower than 60° in El., h = between 60° and 70° in El.)
W-OTFMAP /TOTF, value 12.0 implies /speed 65.0 outside standard range 0.0 to 60.0
W-OTFMAP, WARNING--CONDITION: Elevation must be less than 69.03 [deg]
OTFMAP 780''x 470.4'' (step 4.8)
      > Number of subscans: 99
      > Scanning speed: 65 arcsec/sec
      > Time per subscan: 12 sec
      > Execution time: 23.1 min
}}}

{{attachment:beammap1scan99sub.png | Beammap 99 sub-scans | width=500 }}

Don't forget to set back to your project once the beam map is done!

== Skydips ==

This kind of scan is to be done two to four times a day. It takes ~6 min, so to avoid accounting the time spent to your project think about changing the project to:
{{{
PAKO> set project nikas-17
}}}

To run a skydip with NIKA2 type in !PaKo:

{{{
PAKO> @ skydip
}}}

The script will perform 11 measurements (30 [s] tracks) at different airmasses wrt. the position Az = 180°, El = 55° in the HORIZON coordinate system.
The skydip takes ~6.4 minutes to be finished.

Don't forget to set back to your project once the sky dip is done!
Line 157: Line 175:
Observations of science targets are performed via on-the-fly and/or Lissajous maps.
For example, for a 16'x12' on-the-fly map, with a position angle of 25 degrees, a tilt angle of 0 degrees (both measured '''anticlockwise'''), in equatorial coordinates (radec), just type:

{{{
PAKO> @ nkotf  16 12 25 0 radec
}}}

For a 3'x3' Lissajous type:

{{{
PAK
O> @ nkliss 3
}}}

A sequence of several scans can be loaded using scripts.

For example, the script [[attachment:observe_NGC4449.txt | observe_NGC4449.pako]] combines several 14'x14' on-the-fly maps at different angles in the horizontal coordinate system (azel).
Observations of science targets are performed via on-the-fly (OTF). For example, for a 10'x15' OTF map, with a position angle of 25 degrees, a tilt angle of 0 degrees (both measured '''anticlockwise'''), in equatorial coordinates (radec, for the HORIZON coordinate system set '''azel'''), just type:

{{{
PAKO> @nkotf 10 15 25 0 20 40 radec
}}}

This command will produce a scan pattern as follows:

{{attachment:otf_example.png | OTF scan | width=500 }}

A sequence of several scans can be loaded using a script containing a sequence of '''nkotf''' maps. For example, the script [[attachment:observe2_NGC4449.txt | observe_NGC4449.pako]] combines several 10'x15' OTF maps at different PA and tilt angles in the horizontal coordinate system (azel).

Note that in general it's better to have the longer direction along the subscan to minimize the time loss due to overheads between subscans. Also for baseline subtraction in the data processing it's always better to set a subscan length longer than the usable map you wish to have (typically ~1' more than the usable map; the optimal value depends on the map size and scanning speed).<br>
Scanning in azimuth is better for skynoise subtraction, but the best scnanning strategy depends on you're source shape, and its az-el coverage during integration time.
Line 176: Line 192:
== Pool observations ==

Pool observations are carried from a dedicated pool account (ask the AoD for the login information).
Each project has a folder within the home directory of the pool account with instructions on how to proceed.
Read carefully the README file before to start.
For example, the file [[attachment:README_199-14.txt | ~/199-14/README_199-14.txt ]] explains you how to observe the project 199-14.

=== Choose a project ===

First log into the [[https://pools.iram.es | Pool data base]] (ask the AoD for the login information) and click on the GISMO/NIKA tab.

{{attachment:PoolDatabase.png | Pool data base | width=850 }}

Projects have different priorities from 6 (highest priority) to 1 (lowest priority).
Green color indicates that the project is '''scheduled''', orange that the project is '''on hold''', and red that the project is '''finished'''.
Only green projects should be observed.
To check the visibility of these projects go to the visibility tab:

{{attachment:Visibility.png | Visibility plot | width=850}}

The red vertical line corresponds to the current time (UT).
In this example there are four priority 5 projects.
Project 077-13 is not visible at the current time.
Project 079-13 is close to the low elevation limit so it is a bad option.
Since project 103-13 sets first, it is a good idea to observe this project.
After 2-3 hours change to project 100-13.
In case that none of the priority 5 projects have weather requirements (see the README files) compatible with the current conditions,
go for priority 4 projects and so on.


=== Project setup ===

The standard method to set the project is:

{{{
PAKO> set project XXX-YY
}}}

However, for pooled observations this is often done using a setup script (see for example [[attachment:setup_199-14.txt | setup_199-14.pako ]]). For example, before to start to observe the project 199-14 you should type:

{{{
PAKO> @ ~/199-14/setup_199-14.pako
}}}

It is IMPORTANT to set the project accordingly before each observation in order to identify the scans observed for each project, keep control on the time used to observe each project, and write the data files in the right directory. When you will be doing tests, or if you have to stop by wind, or whatever, just type "set project test". That way, no project will loose time due to technical problems, or bad weather.


=== Catalog of sources ===

Before to start to observe a certain project it is necessary to load its catalog of sources. Usually, this is automatically done within the setup script. If for some reason you need to load the catalog manually, type:

{{{
PAKO> SOURCE CATALOG 199-14.sou
}}}

This command will load the catalog [[attachment:199-14.txt | 199-14.sou ]] with the position of NGC4449:
To select this source, just type:

{{{
PAKO> source NGC4449
}}}

To select a source from the IRAM catalog of pointing sources, just type:

{{{
PAKO> source pointing_source /cat iram-J2000.sou
}}}


----
----

Contact: Pablo García (NIKA2 Pool Manager at the IRAM 30m telescope)

email: pgarcia@iram.es
Contact: Alessia Ritacco ([[http://www.iram.es/IRAMES/mainWiki/Continuum/NIKA2/Main|NIKA2]] Pool Manager of the 1st open pool)

email: ritaccoa@iram.es
Line 255: Line 199:

Last update: 2017.SEP.28, by Alessia Ritacco

Last update: 2017.OCT.23, by Samuel Leclercq

Observing with NIKA2

Go to the NIKA2 main page.


Starting PaKo

To start the PaKo session for rgular obsevations, log into the pool account "nikas-17" (ask the AoD/operator for the login information), open a terminal and type:

$ ssh -X nikas-17-lx1
$ goNIKA
$ PAKO> @ini
$ PAKO> set project XXX
$ PAKO> set doSubmit YES

Now you are ready to start observations.

Observations queue

To check what is currently in the observation's queue, open a terminal and type:

$ ssh -X mrt-lx1
$ observationQueue

This will open a file browser with a list of all the observation's files commanded, which are waiting to be executed by the telescope's system. To remove any observation's file from the queue, right-click on the corresponding xml file and select "delete". The display will be automatically refreshed.

Starting the NIKA2 pipeline

To have the IDL pipeline continuously processing observations as they are produced, open a terminal and type:

$ ssh -X observer@nika2-a (ask the AoD for the password)
$ IDL
IDL> nk_rta, scanID    (e.g. '20151019s132')

where scanID is the corresponding identifier of the observation (as shown in the example) in the format YYYYMMDDsXXX, where YYYY is the year, MM the month, DD the day, and XXX the scan number.

Starting XEphem

XEphem is the software currently used at the IRAM 30m telescope to keep track of the position of astronomical sources on the sky. To start XEphem, open a terminal and type:

$ ssh -X mrt-astro1 xephem

Note: if for some reason this command doesn't work, do ssh on mrt-lx3 then type useNCS and azElToXephem.py before launching Xephem in order to see the telescope.

Then on the Xephem window, click on the tab "View" and open the "Sky View". The "cross hair" shows the coordinates the telescope is pointing at. The filled blue circles are the pointing sources. The size of the circles is proportional to the flux of the target. To load the sources catalog of your project, click on the tab "Data" and go to "Files". In the new window go again to "Files" and select the catalog of the project that you are observing.

XEphem example

Pointing

In order to correct the pointing of the telescope in a given part of the sky choose a nearby pointing source (using e.g. XEphem) and type:

PAKO> source 0133+476 /cat * (or "iram-J2000.sou" or "pointingIRAM30m.sou")

Now launch the nkpoint script:

PAKO> @ nkpoint mode

where the keyword "mode" can adopt the values b for bright sources and f for faint sources (the l option for very faint sources that require the Lissajous pattern is no longer used). The pointing scans are currently reduced by the IDL pipeline. To obtain the pointing corrections, process the corresponding scan with the pipeline: "IDL> nk_rta, scanID". Once the pointing scan is processed, enter the new pointing corrections in azimuth (PnewX) and in elevation (PnewY) shown on the IDL prompt of the NIKA2 pipeline:

PAKO> set pointing PnewX PnewY

Focus

The focus needs to be monitored and it needs to be corrected online. This should be done every two hours or so (~3h during very stable night time condition, ~1h or less near sunrise and sunset) in the Z direction. To check the quality of the focus run:

PAKO> @ focusOTF-Z fz  

Currently, this script will carry out 5 foci measurements in Z direction within a 1.6 mm range, centered at the fz value. In order to obtain the focus corrections, the corresponding scan number have to be processed by the IDL pipeline:

IDL> nk_rta, scanID1    (for measurement 1)
IDL> nk_rta, scanID2    (for measurement 2)
IDL> nk_rta, scanID3    (for measurement 3)
IDL> nk_rta, scanID4    (for measurement 4)
IDL> nk_rta, scanID5    (for measurement 5)

Then, all measured foci need to be processed together by the "nk_focus_otf" routine of the IDL pipeline to perform the best focus fit in terms of the measured Flux, beam FWHM, and beam ellipticity of the KID's. This can be achieved by running the following instruction in the IDL prompt:

IDL> nk_focus_otf,'YYYYMMDDs'+strtrim(SCANNUMBER+indgen(5),2)

where the ScanID is in the format YYYYMMDDsSCANNUMBER (e.g. '20151019s132'). Once the "nk_focus_otf" routine has finished, check the focus correction values displayed in the IDL prompt under "Fluxes" for the three arrays (A1, A2, & A3) and calculate the average value that will be used to correct the focus. Enter the new focus value (Fnew) as follows:

PAKO> set focus Fnew 

Beam map

This kind of scan is to be done once a day or every two days. It takes ~25 min, so to avoid accounting the time spent to your project think about changing the project to:

PAKO> set project nikas-17

Beam maps are designed to ensure the source is moved over all the detectors of the array, in order to characterize and calibrate them (field of view geometry, flat field, stability, etc). The aim is to calculate the actual pixel offsets in the focal plane (see figure below). To obtain a beam map go to a primary calibrator and launch the beammap1scan99sub.pako script in the normal PaKo session:

PAKO> @ beammap1scan99sub  (to produce 99 sub-scans, standard PaKo version)
OPTION = a   (ENTER OPTION: a = Az. scan, e = El. scan, l = lower than 60° in El., h = between 60° and 70° in El.)  
W-OTFMAP       /TOTF,  value 12.0 implies /speed 65.0 outside standard range 0.0 to 60.0
W-OTFMAP,  WARNING--CONDITION: Elevation must be less than 69.03 [deg]
OTFMAP 780''x 470.4'' (step 4.8) 
      > Number of subscans: 99 
      > Scanning speed: 65 arcsec/sec 
      > Time per subscan: 12 sec 
      > Execution time: 23.1 min           

Beammap 99 sub-scans

Don't forget to set back to your project once the beam map is done!

Skydips

This kind of scan is to be done two to four times a day. It takes ~6 min, so to avoid accounting the time spent to your project think about changing the project to:

PAKO> set project nikas-17

To run a skydip with NIKA2 type in PaKo:

PAKO> @ skydip

The script will perform 11 measurements (30 [s] tracks) at different airmasses wrt. the position Az = 180°, El = 55° in the HORIZON coordinate system. The skydip takes ~6.4 minutes to be finished.

Don't forget to set back to your project once the sky dip is done!

Science targets

Observations of science targets are performed via on-the-fly (OTF). For example, for a 10'x15' OTF map, with a position angle of 25 degrees, a tilt angle of 0 degrees (both measured anticlockwise), in equatorial coordinates (radec, for the HORIZON coordinate system set azel), just type:

PAKO> @nkotf 10  15  25  0  20   40  radec

This command will produce a scan pattern as follows:

OTF scan

A sequence of several scans can be loaded using a script containing a sequence of nkotf maps. For example, the script observe_NGC4449.pako combines several 10'x15' OTF maps at different PA and tilt angles in the horizontal coordinate system (azel).

Note that in general it's better to have the longer direction along the subscan to minimize the time loss due to overheads between subscans. Also for baseline subtraction in the data processing it's always better to set a subscan length longer than the usable map you wish to have (typically ~1' more than the usable map; the optimal value depends on the map size and scanning speed).<br> Scanning in azimuth is better for skynoise subtraction, but the best scnanning strategy depends on you're source shape, and its az-el coverage during integration time.


Contact: Alessia Ritacco (NIKA2 Pool Manager of the 1st open pool)

email: ritaccoa@iram.es

Created: 2013.OCT.25, by Isreal Hermelo

Last update: 2017.FEB.05, by Pablo García

Last update: 2017.SEP.28, by Alessia Ritacco

Last update: 2017.OCT.23, by Samuel Leclercq

Continuum/ObservingSession (last edited 2024-03-14 09:07:14 by NikaBolometer)