[daip] forwarded message from Eric Greisen

[Eric Greisen]

------- start of forwarded message (RFC 934 encapsulation) -------
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <egreisen at aoc.nrao.edu>
Received: from polaris.cv.nrao.edu (polaris.cv.nrao.edu [192.33.115.101])
	by dropbox.aoc.nrao.edu (8.13.1/8.13.1/smtp-gateway) with ESMTP id l1CKQ6mn015602
	for <egreisen at aoc.nrao.edu>; Mon, 12 Feb 2007 13:26:06 -0700
Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15])
	by polaris.cv.nrao.edu (8.13.1/8.13.1/smtp-gateway) with ESMTP id l1CKQ58c009145
	for <egreisen at nrao.edu>; Mon, 12 Feb 2007 15:26:05 -0500
Received: from primate.aoc.nrao.edu (primate.aoc.nrao.edu [146.88.3.100])
	by revere.aoc.nrao.edu (8.13.1/8.13.1/cv-ws-8.12) with ESMTP id l1CKPZjc011742;
	Mon, 12 Feb 2007 13:25:35 -0700
Received: (from egreisen at localhost)
	by primate.aoc.nrao.edu (8.13.1/8.13.1/Submit) id l1CKPZZ8003672;
	Mon, 12 Feb 2007 13:25:35 -0700
Message-ID: <17872.52543.615740.899968 at primate.aoc.nrao.edu>
In-Reply-To: <Pine.LNX.4.63.0702121857160.12981 at jop21.nfra.nl>
References: <Pine.LNX.4.63.0702121857160.12981 at jop21.nfra.nl>
X-Mailer: VM 7.00 under Emacs 21.3.1
X-MailScanner-Information: Please contact the postmaster at aoc.nrao.edu for more information
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-101.44,
	required 5, autolearn=disabled, ALL_TRUSTED -1.44,
	USER_IN_WHITELIST -100.00)
X-MailScanner-From: egreisen at aoc.nrao.edu
X-Spam-Status: No
From: Eric Greisen <egreisen at nrao.edu>
To: Cormac Reynolds <reynolds at jive.nl>
Subject: Re: [daip] IMAGR problem
Date: Mon, 12 Feb 2007 13:25:35 -0700

It is odd to see this problem with so few data samples.  I will play
with the data some more to see if I can figure out exactly what is
happening.  What I believe is that the beam has become very odd - note
that the max is 1.8 Jy which must occur somewhere other than at the
center.  This makes a mess of the beam histogram which is used - at
least at the beginning - to try to figure out how many samples to lead
for cleaning.  Since the beam appears to get stronger as one goes away
from the center, this algorithm suffers a melt down.  I have made a
modest fix for this in the 07 version.

Usually this occurs when one has many samples (e.g. many visibilities
and many pseudo-continuum spectral channels).  My understanding of
this is the random walk effect of random computational errors in the
gridding multiplied by a very large correction factor at the corners.
Subtle shifts in the cell size, image size, or grid function would
change this a lot.  Hence your observation that this bug comes and
goes.

As I say, I will look at it some more to see if I can figure out
anything better.

Eric Greisen
------- end -------