LINMOSing submosaics

Is MIRIAD being a pain? Let us know your experience.

Moderator: Mark.Wieringa

Post Reply
and460
Posts: 79
Joined: Thu Sep 01, 2011 12:23 pm

LINMOSing submosaics

Post by and460 »

Hi,

I am trying to knit together some submosaics that I have created into an even bigger mosaic with linmos, but I'm getting errors and failures that I don't understand.

In the first instance, I made my submosaics using the so-called joint approach, by feeding all of my mosaiced pointing data for a particular 12 hour synthesis into invert, deconvolving the resulting mosaic with mossdi, and then restoring. Since I have multiple 12 hour submosaics of a larger region, I want to combine this into a giant mosaic, so I tried to linmos the submosaic from each day together, but I got:

WARNING: Setting RMS to 1.0 for all images.
### Fatal Error: Bad size for mosaic table.

Not sure what this means.

In the second instance, I created my submosaics for each day's synthesis using the individual approach - imaging, then deconvolving with clean, then restoring each pointing separately, then linmosing all the pointings from each day together to create the submosaic for that day. As before, I then want to combine all of my day's worth of submosaics into a big mosaic, but when I run linmos on the submosaics, I get:

WARNING: Setting RMS to 1.0 for all images.

The task seems to complete, but when I look at the resulting image in kvis, it only has the bottom right pointing from each submosaic correctly displayed, while the remainder of the mosaic is blank.

If, using the individual approach, I keep all of my clean images for each pointing for all of the days and then run linmos with a wildcard to input them all, the mosaic is formed without problem. However, I am imaging at 8MHz intervals throughout the entire CABB band in full Stokes parameters, so with ~300 pointings x 4 Stokes params x 64 image channels (+ all the beam files and dirty images and clean model files etc.), the number of files I would need floating around on the computer is a serious problem with this approach.

So am I using linmos incorrectly? Is linmos simply not the right tool to do what I've been trying to do? Is there any other task that I can use, or is it simply not possible at this time to knit together submosaics like I've been trying to?

Thanks for your time and help...

Cheer,

Craig.
Mark.Wieringa
ATCA Expert
Posts: 297
Joined: Mon Feb 08, 2010 1:37 pm

Re: LINMOSing submosaics

Post by Mark.Wieringa »

Hi Craig,

The short answer is that linmos can only cope with single pointing images in the input.

Your second approach, whith the rather large number of files as input is the only way you can do this with linmos.

If you are really running into problems you could create submosaics that overlap by one or two rows of pointings. You could then stitch these together later (using a combination of imsub/imcomb etc). But you may find that the extra bookkeeping required to do this is so tedious that you'll put up with the large number of files instead...

Cheers,

Mark
and460
Posts: 79
Joined: Thu Sep 01, 2011 12:23 pm

Re: LINMOSing submosaics

Post by and460 »

OK - thanks Mark.

On a related note, what does the "WARNING: Setting rms in each image to 1.0" warning result from? I assume it means that the task cannot find or measure the noise in the images that I'm putting into linmos? Will this mean the output from linmos in this case is degraded/rubbish, or just that the final image won't be optimised in terms of sensitivity?

Cheers,

Craig.
Mark.Wieringa
ATCA Expert
Posts: 297
Joined: Mon Feb 08, 2010 1:37 pm

Re: LINMOSing submosaics

Post by Mark.Wieringa »

Hi Craig,

For a single pointing image invert calculates the theoretical noise and stores this in the image header. Linmos reads these and uses them to set the weights for each image in the output. I'm not sure why your images don't have this - you must have done some other operations on them. In any case, it just means all images will have equal weight in the output, so as you said, the final image may have slightly higher than optimal noise levels.

Cheers,

Mark
Post Reply