[daip] DCONV (fwd)

[Anita M. S. Richards]

Dear Eric,

Thanks for your reply, Magda can tell you exactly what she is trying to do 
but it is not interferometer data I don;t think...

The problem is that she is trying to use it in the mode which should only 
want one image i.e. 'UNWT', so the issue of coinciding with a second image 
should not arise, if we understand correctly.

best wishes

Anita

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Dr. A.M.S. Richards, AstroGrid Astronomer, University of Manchester, 
Jodrell Bank Centre for Astrophysics, Turing Building, 
University of Manchester, M13 9PL
+44 (0)161 275 4124
and
MERLIN/VLBI National Facility, Jodrell Bank Observatory, 
Cheshire SK11 9DL, U.K. +44 (0)1477 571321 (tel) 571618 (fax)


On Tue, 30 Oct 2007, Eric Greisen wrote:

> Anita M. S. Richards writes:
>
> > DCONV appears to have a bug in that even with OPCODE     'UNWT', it gives
> > hecate> DCONV2: Task DCONV  (release of 31DEC07) begins
> > hecate> DCONV2: DCONV  : input maps not equivalent - FATAL
> > hecate> DCONV2: Purports to die of UNNATURAL causes
> >
> > in both Dec06 and Dec07 versions
> >
> > Is this known? Is there a way round it? CONVL, opcod 'DCON' seems to do
> > the
> > same thing; if that is so then that is OK.
> >
>
> I need to ask what you are attempting to do.  Brute force
> deconvolutions are not normally very useful in the presence of noise.
> If you are attempting to deconvolve interferometer dirty images, there
> are much better ways to do that (see IMAGR).
>
> The error message from DCONV states the the two images differ in some
> way in the number of pixels, coordinate increment, coordinate
> reference pixel, or coordinate reference value on either the first
> and/or the second axes.  The first 2 must be exactly the same, the
> others are allowed a little leeway.
>
> Eric Greisen
>