Precision of RA and Dec output

[MatthewWhiting]

It was pointed out by the reviewer of the MN paper that the RA and Dec columns in the output file have the same precision. Normally you would expect RA to have one place more than Dec, as it is in different units.

The 2 decimal places are actually hard-coded in the decToDMS function. This should be changed to make this precision an input parameter.

Further than this, the precision used here should reflect the input data - if we have, for instance, degree-sized pixels, you don't need this level of precision. But if we have micro-arcsec pixels you need hugely more...

[MatthewWhiting]

Move to 1.1.14

[MatthewWhiting]

[907] fixes this, by allowing decToDMS to receive a precision. In practice, this precision is calculated from the pixel size, being int(log10(cdelt*3600/10)), truncated at zero. RA will get one additional decimal place.

This seems to work well enough. Closing this ticket.

[MatthewWhiting]

This is still not right. One of the selavy service images that have been submitted, /DATA/DELPHINUS_1/duchampsvc/images/c4af253b807f7e0e0c6d9f3ae8782eb1.fits, is a VLBA image, and has header info like so:

CTYPE1  = 'RA---SIN'           /                                                
CRVAL1  =    3.07353669963E+02 /                                                
CDELT1  =     -2.777777652E-08 /                                                
CRPIX1  =      4.096000000E+03 /                                                
CROTA1  =      0.000000000E+00 /                                                
CTYPE2  = 'DEC--SIN'           /                                                
CRVAL2  =    4.01889113056E+01 /                                                
CDELT2  =      2.777777652E-08 /                                                
CRPIX2  =      4.097000000E+03 /                                                
CROTA2  =      0.000000000E+00 /                                                

but the results from Duchamp run look like:

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Obj#           Name      X      Y     Z              RA             DEC      VOPT       w_RA      w_DEC    w_50         F_int    F_peak S/Nmax   X1   X2   Y1   Y2  Z1  Z2  Npix Flag
                                                                             [m/s]   [arcmin]   [arcmin]   [m/s] [Jy/beam m/s] [Jy/beam]                                    [pix]     
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    1 J202924+401119 1082.8 1035.6  18.2 20:30:00.000000 +40:12:00.00000 -8701.208     0.0000     0.0000 670.761        95.487     0.044   6.62 1082 1084 1034 1037  17  19    12    -
    2 J202924+401119 1002.2 1018.7  16.7 20:30:00.000000 +40:12:00.00000 -8384.948     0.0000     0.0000 842.300        91.174     0.042   6.31 1001 1003 1017 1021  16  18    12    -

Seems like the precision is not being applied in the right spot. Or its calculation is failing..

[MatthewWhiting]

Just to be clear, going off the PGPlot graph, the positions should be roughly:

• Obj1: 20:29:24.90708, 40:11:19.7747
• Obj2: 20:29:24.90778, 40:11:19.773

[MatthewWhiting]

Changeset [950] fixes this. I needed to change Detection::ra and Detection::dec to double (from float), and #150 exists to follow up this with other parameters and make sure everything is consistent.

I also streamlined the actual decToDMS code, and fixed a bug (the comparison with the precision had the wrong sign in the exponential!). Seems to be working fine now. Closing this ticket again.