AzEl issue #877
Comments
|
PS I'd do this myself, but I remember that there's some obscure 'special' incantations necessary when adding nodes. An alternative would be to just update the existing nodes with the changes mentioned above. I don't see any practical use for nodes giving geocentric Az and El. |
|
BTW on the (really old) astron wiiki there used to be a page that contained small test scripts for most MeqTrees nodes. Is this page still hidden in some alternative universe where it can be accessed in some way? |
|
Ahhh, well spotted Tony. The sacred tools must be wielded well or they can give incorrect results. I had completely overlooked this -- in fact the intention of MeqAzEl was to give the geodetic az/el. So I wonder if we shouldn't just change MeqAzEl itself (or perhaps provide an option in the init state that selects geodetic versus geocentric)? Do you have a feeling for how large the difference can be? I'm now wondering if this also affects MeqParAngle -- I've had some puzzling results with the polarization of 3C286 around transit which I could never explain... |
|
Supporting argument. @bmerry changed AZEL to AZELGEO when comparing meqtrees and astropy parallactic angles. To get them to agree more closely I think. |
|
The differences can be up to 12 arcmin or so, and depends on latitude and peaks at about +/-49 deg (guess what the latitude of the DRAO telescope is?) which is why I started to notice the problem - we were comparing CASA Measures output vs astropy vs JPL HORIZON vs PyEphem for the Sun. And yes, it affects parallactic angle. There the problem is that MeqParAngle calls the CASA ParAngleMachine (@tammojan) which has MDirection::AZEL hard wired in the code, so that's an issue for CASA to look at. My personal suggestion would be for options to be provided to select between AZELGEO and AZEL, but if thats hard to do, then change AZEL to AZELGEO as that's where Az and El are most likely to be used. @o-smirnov If you were observing 3C286 with the WSRT, which is at 55 deg latitude or thereabouts, yes, you should be seeing some discrepancies due to ParAngleMachine using a geocentric definition for AzEl. |
|
Here's a plot of the difference in geocentric and geodetic latitude (0 at the poles and equator - peak at somewhere close to 49 deg) |
|
@o-smirnov Of course the parallactic angle difference at transit is zero, but increases as hour angle increases. (Further investigation shows that the above statement is not necessarily true - see the output from my next message). Here's the output of a run I did for 3C286 as seen from DRAO over a 24 hr period astropy 3C286 J2000 position RA 13h31m8.287896s Dec = 30d30m32.958s |
|
When I make the same run at the VLA site (latitude ~ 34 deg) on the same day I get (just for hour angles in the range -90 deg to 90 deg) I get: astropy 3C286 J2000 position RA 13h31m8.287896s Dec = 30d30m32.958s |
As Oleg points out, Wim Brouw is infallible but that doesn't prevent the rest of us from going astray. I've concluded that the AzEl and AzElRaDec nodes in MeqTrees, while correct as they stand, do not provide the right AzEl for the working astronomer. Wim's 'default' AzEl ( MDirection::AZEL) gives the AzEl of a radio source as seen from the centre of the Earth using the geocentric latitude. This is useless for practical astronomy as the AzEl as seen at the site of an observatory is given by MDirection::AZELGEO the AzEl of a source as seen from a position on the actual oblate Earth using the geodetic latitude and not the geocentric latitude. I suggest creating two new MeqTrees nodes AzElGeo and AzElGeoRaDec. All that has to be done is replace instances of MDirection::AZEL by MDirection::AZELGEO in the *.cc files and references to topocentric by geodetic in the corresponding header files'
Since no-one has ever noticed this error, I suspect that conversions between ra, dec and az, el haven't been done too often !!
The text was updated successfully, but these errors were encountered: