Custom Query (104 matches)

It is possible to use a VNC X server to set up a window containing an 8-bit X visual that can be viewed on a 24-bit X display.

However setting this up is a little tricky; a shell script provided with miriad might make this easier for most users.

Malte has done some interesting work to make miriad callable from python (trac/operations/browser/SCA/src/code/Packages/mirpy).

This would benefit from having tasks produce machine-readable output, rather than having to parse the (often complex) textual output. ​JSON seems an obvious choice of format.

For reference please see conversation at: ​http://atcaforum.freeforums.org/l-band-flux-of-1934-638-depends-on-maxsize-t38.html

It appears that when a heavily flagged (in frequency space) 1934-638 dataset is input into gpcal, the resultant flux appears to be incorrect.

Is gpcal merely scaling the entire band to make the average flux level match the flux level expected of 1934-638 at the "centre" of the band? Is this a problem for other sources?

The mfcal task does not suffer from this defect.

Some example data that I used to replicate this problem can be found at /DATA/KAPUTAR_3/ste616/reduction/dominic_problem/.

Here, the 1934-638.1750.1 dataset can be calibrated using mfcal/gpcal to see how the flux levels vary between the two calibration methods (the spectral slope appears to stay the same). The dataset 1934-638.1750.aver removes the large flagged areas on either side of the usable part of the spectrum, and calibrating with this dataset results in a much smaller difference.

With this result, it would seem that gpcal has always been giving faulty results, although in the higher frequency bands where less spectral flagging is required, the effect is too small to be noticed.