Hi,
I tried to correct the primary beam for a set of WSRT (Westerbork) 1.4 GHz data using linmos.
However, the correction seems way off -- at the 1.4 GHz of my observations, LINMOS calculates a primary beam FWHM of ~15 arcmin (something which I expect for ~3 GHz observations!)
Note that a few months ago this was working fine (on the exact same data set).
Did LINMOS change in the meanwhile and was perhaps an error introduced?
Thanks,
Bjorn
linmos problem
Moderator: Mark.Wieringa
-
Mark.Wieringa
- ATCA Expert
- Posts: 297
- Joined: Mon Feb 08, 2010 1:37 pm
Re: linmos problem
Hi Bjorn,
linmos was last changed in early June, to add the bandwidth parameter. The beam selection code should be unchanged - it checks for a 'pbtype' or 'telescop' keyword to find out the primary beam to use. You can check this with gethd in=image/telescop (or pbtype).
If the header looks ok, I'm happy to have a look at an image linmos fails on to see what is going on.
Cheers,
Mark
linmos was last changed in early June, to add the bandwidth parameter. The beam selection code should be unchanged - it checks for a 'pbtype' or 'telescop' keyword to find out the primary beam to use. You can check this with gethd in=image/telescop (or pbtype).
If the header looks ok, I'm happy to have a look at an image linmos fails on to see what is going on.
Cheers,
Mark
Re: linmos problem
Hi Mark,
Thanks for your quick reply.
I did narrow the problem down quite a bit:
Apparently linmos does not work properly on the mom0 image (created with 'moment'), but it does work properly on the data-cube that I give as input in 'moment'. So I can circumvent the problem by doing 'linmos' first and then 'moment' to get the correct PB-corrected total intensity image.
So I suspect the problem may concern the task 'moment' rather than 'linmos'.
The same problem occurs for two different WSRT data sets and one ATCA/CABB data set that I tried, although for the WSRT data sets the PB is assumed to be too small, while for ATCA/CABB the PB beam is too large (again, this only reflects to using 'linmos' after 'moment', the other way around is all ok).
The keyword 'telescop' seems ok, while 'pbtype' provides no output in any fo the tree data sets that I looked at. Only once linmos is applied pbtype gives 'SINGLE'.
Just in case you want to have a look, I put the test-data-sets of two of the sources that I looked at (one WSRT data set and one ATCA/CABB data set) in:
/data/HYDRA_2/emo004/Linmos_test/WSRT/
/data/HYDRA_2/emo004/Linmos_test/ATCA/
"testcube" is the data-cube (output of invert);
"testcube.linmos.mom0" has first linmos then moment applied;
"testcube.mom0.linmos" has first moment then linmos applied.
(note that this WSRT data set has a very elongated beam and pixel sizes that are not square. However, I checked that this is not the problem, the same happens with squared pixels)
Not sure what is going on...
Thanks,
Bjorn
Thanks for your quick reply.
I did narrow the problem down quite a bit:
Apparently linmos does not work properly on the mom0 image (created with 'moment'), but it does work properly on the data-cube that I give as input in 'moment'. So I can circumvent the problem by doing 'linmos' first and then 'moment' to get the correct PB-corrected total intensity image.
So I suspect the problem may concern the task 'moment' rather than 'linmos'.
The same problem occurs for two different WSRT data sets and one ATCA/CABB data set that I tried, although for the WSRT data sets the PB is assumed to be too small, while for ATCA/CABB the PB beam is too large (again, this only reflects to using 'linmos' after 'moment', the other way around is all ok).
The keyword 'telescop' seems ok, while 'pbtype' provides no output in any fo the tree data sets that I looked at. Only once linmos is applied pbtype gives 'SINGLE'.
Just in case you want to have a look, I put the test-data-sets of two of the sources that I looked at (one WSRT data set and one ATCA/CABB data set) in:
/data/HYDRA_2/emo004/Linmos_test/WSRT/
/data/HYDRA_2/emo004/Linmos_test/ATCA/
"testcube" is the data-cube (output of invert);
"testcube.linmos.mom0" has first linmos then moment applied;
"testcube.mom0.linmos" has first moment then linmos applied.
(note that this WSRT data set has a very elongated beam and pixel sizes that are not square. However, I checked that this is not the problem, the same happens with squared pixels)
Not sure what is going on...
Thanks,
Bjorn
-
Mark.Wieringa
- ATCA Expert
- Posts: 297
- Joined: Mon Feb 08, 2010 1:37 pm
Re: linmos problem
Hi Bjorn,
I had a look at linmos to see what frequency it was using for the primary beam.
When linmos is run on the testcube, it uses 1.39 GHz.
When linmos is run on the moment map, it uses 7.64 GHz. This causes the scaling error.
It looks like this is caused by moment not filling in the third axis coordinate (velocity) properly - it is listed as -1.3e6 km/s, clearly wrong.
I'll let you know when this is fixed, in the meantime, doing linmos first and moment last will work fine, as you found.
Cheers,
Mark
I had a look at linmos to see what frequency it was using for the primary beam.
When linmos is run on the testcube, it uses 1.39 GHz.
When linmos is run on the moment map, it uses 7.64 GHz. This causes the scaling error.
It looks like this is caused by moment not filling in the third axis coordinate (velocity) properly - it is listed as -1.3e6 km/s, clearly wrong.
I'll let you know when this is fixed, in the meantime, doing linmos first and moment last will work fine, as you found.
Cheers,
Mark
-
Mark.Wieringa
- ATCA Expert
- Posts: 297
- Joined: Mon Feb 08, 2010 1:37 pm
Re: linmos problem
The problem with the moment axis reference value has now been fixed (by Mark Calabretta), so from tomorrow the order in which linmos and moment are run should no longer matter.
Cheers,
Mark
Cheers,
Mark