[daip] VLBA bandpass calibration in AIPS (fwd)
Craig Walker
cwalker at nrao.edu
Fri Jun 27 20:25:59 EDT 2014
In doing the AIPS tests of what happens with various bpassprm
parameters, I ignored (or forgot) the original concern raised by the
MOJAVE project that the amplitude calibration seemed to be matching
external flux density information best if the normalization were over
the inner 75% of the band. That does not conform to my long-standing
understanding of how calibration should be done. However, the data set
used for the tests described in my message involved OQ208, for which
Joan has obtained a JVLA flux density measured close in time and
frequency to our observations. I can now confirm the reported
calibration issue. We get 1.78 Jy total in our VLBA image calibrated in
the normal way (full band normalization) and 2.22 Jy from the VLA, for a
difference of 25%, very close to what the MOJAVE people report.
We need to understand why this offset exists as it represents a
potential very significant error in the VLBA calibration. I don't
believe it was like this in the days of the legacy systems, although it
would be good to have specific confirmation of that. Does anyone have
easy access to flux densities measured on the VLBA and on some other
instrument at nearly the same time, on a source without large scale
structure? If so, can you provide information on how any bandpass
calibration was done, in addition to the observation date and the
hardware used? I am targeting this request to both MOJAVE and NRAO
people. Unfortunately most of my recent data has been at 43 GHz where
amplitude calibration has many other confusing issues.
While the magnitude of the apparent errors is about explained by the
alternative bandpass normalization, there are other possible reasons for
the situation. With stressed manpower in recent years, the measurement
of gains has not not had as much scientific oversight as it had in the
earlier years. Could something have gone wrong there? Are the gains
measured on the legacy system really appropriate to use on the RDBE?
The PFB does have a much softer filter than the BBCs. Is there
something about DiFX that has caused a difference in behavior?
Or some change in AIPS? Assuming the calibration was good in the
pre-DiFX/RDBE days, pinning down a rough date when it went bad would
help isolate where to look. When we started using DiFX, we confirmed
that the amplitudes measured with it very closely matched those measured
with the old correlator, so that probably absolves the original
DiFX.
I noticed that I forgot to add the vlbatests list to my previous email
despite my claim. I have added it here. The NRAO people may need to
read some of the previous messages. For completeness, I have attached
the message from Yuri, via Eric, that started the recent version of this
discussion.
Cheers,
Craig
On 06/26/2014 05:47 PM, Craig Walker wrote:
> I have used some data taken a year ago, but just recently
> post-processed to investigate the amplitude calibration issue.
>
> First, a quick review of the meanings of the bpassprm settings:
>
> bpassprm(5) -2 => Divide by "channel 0" determined as the
> average after time averaging. Used if
> have good phase stability.
> 0 => Divide by "channel 0" determined record by
> record.
> 1 => Do no normalization before determining solutions.
> Can still normalize with bpassprm(10)=3
> bpassprm(10) 2 => Normalize amplitude solution portion of bandpass
> using channels in ICHANSEL.
> 4 => Normalize amplitude solution portion of bandpass
> using all channels (ignored ICHANSEL, I think).
> ichansel Channels for normalization.
> Default is inner 75%
>
> I split off my main calibrator scan to make tests easy, and ran
> with a variety of combinations of these parameters. The results
> are summarized in the following table.
>
> Summary:
> (Scale is calibrated cross correlation amplitude of IF 1 on KP-LA)
> (BP amp is the eyeball amp of the central channels in the BP table.
>
> Ver bpassprm ichansel AmpSlopes PhaseSlopes Scale BP amp
> (5) (10)
> 1 -2 4 1,64 flat flat 1.52 1.12
> 2 -2 4 0 flat flat 1.52 1.12
> 3 0 4 1,64 flat flat 1.52 1.12
> 4 1 4 1,64 sloped flat 1.52 1.12
> 5 1 2 1,64 sloped flat 1.87 1.00
> 6 1 2 0 sloped flat 1.87 1.00
> 7 0 2 0 flat flat 1.87 1.00
> 8 0 2 1,64 flat flat 1.52 1.12
> 9 1 4 0 sloped flat 1.52 1.12
>
> Assuming ICHANSEL=0, Sasha's "new" is bpver 9, "old" is bpver 7, and
> "newold" is bpver 6. So I agree "old" and "newold" should give the
> same results, while "new" should be different at the ~23% (24% close
> enough) level. I think it mainly boils down to whether or not the
> normalization was over all channels, or the inner 75%, the default
> with ICHANSEL=0.
>
> bpassprm(5)= 1 (no pre-solution normalization) doesn't seem to work
> very well. Not sure why, but it ends up with small amplitude slopes.
> Perhaps it is some sort of coherence issue with moving phases? The
> slope is about 3% across the band, so it's not too scary.
>
> Note 1.12**2 =1.25 is about the scale difference reported here and in
> Sasha's note. It is certainly within the eyeball amplitude errors.
>
> Here that the actual eyeball bandpass table values for the central
> channels are either about 1.12 or about 1.00. I think the 1.12 result
> is appropriate when adding all across the band while the 1.00 is
> appropriate for the center. Breaking the channels into far edge,
> inner edge, and center channels and eyeballing a spectrum that has
> 1.12 in the center, I get an average of roughly:
> (16*0.75 + 1.04*8 + 1.12*(64-16-8))/64 = 1.017
> This is probably within the eyeball errors of 1.0 - the expected
> value. So the normalization across all channels is ok when it
> happens. Note 1.12**2 =1.25 is about the scale difference, certainly
> within the eyeball amplitude errors. So I think most of what matters
> here depends on whether the average was over the whole band or the
> inner 75% (the default with ICHANSEL=0 when ICHANSEL is used).
>
> It seems that full band averages are done when bpassprm(10)=4 as
> advertised. When bpassprm(10)=2, ICHANSEL is supposed to be obeyed
> which seems to be the case except in the one instance when no
> pre-solution normalization (bpassprm(5)=1) is done - another case of
> that setting leading to strange results. After seeing these results,
> I cannot recommend bpassprm(5)=1.
>
> I use the parameters of BP 1 (bpassprm(5)=-2 and bpassprm(10)=4) and I
> see no reason to change after this little study.
>
> Note that the Tsys values are measured as an average over the whole
> band, both during the observations and when measuring the Ta/Ts values
> used to determine the gains. So I think it is important to use the
> full band normalization.
>
> Currently the gains are measured using the legacy BBC power detectors.
> Those have different bandpass shapes then the PFB filters. I'm not
> 100% convinced right now, but I think this does not matter if the Ts
> values used for calibration are measured in the same filters as are
> used for the interferometer data. The gain is really a fractional
> increase in power for a given source flux density and I think that
> will be the same regardless of the filter shape when measured over the
> whole filter. The bandpass calibration just allocates the power to
> the right places in the band. The Tsys with the data, at least for
> the more recent data, is measured in the same filters as used for the
> interferometry.
>
> My thinking on this subject changed somewhat from what I have said in
> the past and what I put in some of the earlier emails in this thread.
> I used to think the fact that the gains were measured with different
> filters really mattered. My current thinking is that it does not
> matter.
>
> I have taken the liberty to add the VLBATESTS group to this email as I
> think the results might be of interest to others working on the VLBA.
>
> Cheers,
>
> Craig
>
>
> On 06/25/2014 01:59 PM, apushkar at mpifr-bonn.mpg.de wrote:
>> Dear Colleagues,
>>
>> We studied the effect of different bpass schemes by applying them
>> to the same data (BL193AI session) and then using corresponding
>> imaging results. In particular, we compared flux scales using
>> total flux density values taken as a sum of all cc components
>> for each of 22 sources imaged for three versions described
>> earlier by Yuri (and using his nomenclature)
>> - new (bpassprm(5)=1; bpassprm(10)=4)
>> - old (bpassprm(5)=0; bpassprm(10)=2)
>> - newold (bpassprm(5)=1; bpassprm(10)=2)
>>
>> Median flux scale shift between 'old' and 'new' (see attached plots)
>> is about 24%, while between 'old' and 'newold' is less than 1% (there
>> are two outliers due to additional low-amplitude data flagging before
>> imaging 'newold' version).
>>
>> Cheers,
>> Sasha
>>
>>
>>
>> On 20.06.2014 09:30, Yuri Y. Kovalev wrote:
>>> ---------- Forwarded message ----------
>>> Date: Mon, 16 Jun 2014 16:21:51 -0600
>>> From: Craig Walker <cwalker at aoc.nrao.edu>
>>> To: Yuri Y. Kovalev <yykovalev at gmail.com>
>>> Cc: Eric Greisen <egreisen at nrao.edu>, daip at nrao.edu
>>> Subject: Re: [daip] VLBA bandpass calibration in AIPS
>>>
>>> Yuri,
>>>
>>> Eric showed me your mail about calibration. As the keeper (other
>>> than operations) of the gains, I have some comments.
>>>
>>> The gains are measured with essentially analog signals from the
>>> legacy BBCs. They have no way of selecting partial bandpasses. The
>>> Tsys values that you are using depend a bit on when in our transition
>>> to the RDBE the data were taken. But for the recent data, the
>>> measurements are made in the RDBE. They are also made over the full
>>> bandpass with no selection of a partial bandpass. When everything was
>>> in the legacy system, to use the Tsys and gains to calibrate, you
>>> needed to use the full bandpass which was accomplished by normalizing
>>> over the full bandpass. If you did the calibration with a
>>> normalization over only part of the bandpass, the average goes higher
>>> than for the full bandpass and does not correspond to what was used to
>>> derive the antenna gain.
>>>
>>> With the RDBE, it gets a bit mixed up and is probably not quite as
>>> accurate. We have not made the full transition yet for the calibration
>>> observations. So the gains still come from the legacy BBCs. But the
>>> Tsys and actual data come from the RDBE. With the PFB personality,
>>> the bandpasses have significantly softer edges than with the BBCs.
>>> This might cause there to be an offset in the calibration, even with
>>> what was thought to be proper normalization. My concern is that,
>>> getting a 20% effect from this seems to me to be a bit large. You
>>> might try some experiments on the magnitude of the differences with
>>> full band vs center band normalizations with the legacy system (older
>>> data sets) and with the RDBE_PFB.
>>>
>>> The DDC personality has sharper filters and so will likely be more
>>> like the old system. But the filters are not the same as the BBCs so
>>> even that is likely to have some offsets.
>>>
>>> Of course, if trying to understand the absolute calibration, we would
>>> also need to understand the calibration of the OVRO data.
>>>
>>> We are close to having the tools to make the gain measurements with
>>> the new systems, but we are still having some rough edges and have not
>>> started to do it systematically. Those measurements, as currently
>>> configured are made using the DDC. We have not really thought
>>> carefully about what to do with DDC vs PFB data.
>>>
>>> Cheers,
>>>
>>> Craig
>>>
>>>
>>> On 06/16/2014 03:10 PM, Eric Greisen wrote:
>>>> either BPASSPRM(5) = 0 or BPASSPRM(5) = 1
>
--
---------------------------------------------------------------------
R. Craig Walker Array Operations Center
cwalker at nrao.edu National Radio Astronomy Observatory
Phone 575 835 7247 P. O. Box O
Fax 575 835 7027 Socorro NM 87801 USA
---------------------------------------------------------------------
-------------- next part --------------
An embedded message was scrubbed...
From: Eric Greisen <egreisen at nrao.edu>
Subject: Re: [daip] VLBA bandpass calibration in AIPS
Date: Mon, 16 Jun 2014 15:10:42 -0600
Size: 4161
URL: <http://listmgr.nrao.edu/pipermail/daip/attachments/20140627/4a04ce9f/attachment.mht>
More information about the Daip
mailing list