Skip to main content

What are the amplitude calibration issues caused by ALMA's normalization strategy? - Knowledgebase / Offline Data Reduction and/or CASA - ALMA Science

What are the amplitude calibration issues caused by ALMA's normalization strategy?

Authors list

Interferometers require data normalization for correct flux scaling. This normalization is performed by using the data from each individual antenna (the autocorrelations) in combination with the data from each antenna baseline pair (the crosscorrelations). The crosscorrelation data of each baseline are divided by the power of the autocorrelation data of each antenna in the pair. The autocorrelation data are commonly averaged over all observed frequencies. However, at ALMA, we instead divide the crosscorrelation data by the channelized autocorrelation data (i.e the autocorrelations as a function of frequency). This enables us to obtain extremely flat amplitude baselines without having to perform fits to the data. However, if an observation targets a very bright, extended source (like carbon-monoxide emission in a star forming region for example) that can be easily detected by a single dish observation, that emission may show up in the autocorrelation data as well. This then leads to an incorrect normalization value in those channels where the emission was detected and therefore an under-scaling of the flux values in those channels.

This can be compensated for by using the observations of the system temperature since these observations will also detect the same line emission ultimately leading to an over-scaling of the emission in those channels where the emission was detected. These combined effects can exactly cancel each other out. However, the past (and current) observation strategy at ALMA has been to perform system temperature measurements off-source in an emission-free region of the sky. This is done in order to avoid possible bright continuum emission from the target source which could complicate the system temperature calibrations. However, this then means that the under-scaling of the data is not properly accounted for. Further complications can arise in the circumstances where line emission is detected in the system temperature observations, as that line emission is inherently from a different part of the sky and is incorrectly scaling the data (possibly in different channels if the line emission is shifted). Additionally, mosaic observations are always observed with a single system temperature position and all observations use a simple one-dimensional "throw" method for the system temperature pointing which means that the sky location of the system temperature pointing can change throughout the course of an observation as the sky rotates.

Therefore, to properly normalize the data one must disentangle the two issues and account for each individually. The first step is to carefully check the system temperature measurements to make sure that there are no emission lines detected. If there are any emission lines, they must be flagged. With the errant emission lines flagged, the crosscorrelation data can be corrected. This is done by dividing the raw autocorrelation data of each science target scan of each antenna by the bandpass autocorrelation data. This removes the instrumental structure of the spectral window. From there, we fit any residual baseline noise until we are left with a Renormalization Correction Spectrum which represents the correction factor per channel that must be applied to properly recover flux to within ALMA's standard.

This renormalization correction is not necessary to apply to all data. Most data taken with ALMA is unaffected by this normalization strategy. As stated above, only highly extended (i.e. filling a large fraction of an ALMA single dish primary beam), very bright sources that can be detected by an ALMA single dish can be affected. It has been decided by ALMA that if a renormalization correction fraction of more than 2% is detected in a newly observed dataset, it will be corrected through this renormalization strategy as part of data processing.

For a more technical description of this issue, please see the following Knowledgebase article: