Incorrect restriction on radar "delay" type

IAU-ADES / ADES-Master

ADES implementation based on a master XML file

26 stars 7 forks source link

Incorrect restriction on radar "delay" type #15

Closed matthewjohnpayne closed 1 year ago

matthewjohnpayne commented 1 year ago

The radar "delay" field seems to be restricted to having values less than 100000.0 (micro-seconds).

As far as I can tell, the problem is caused by the "delay" element being of type "PosDecimalTypeW14" which is itself restricted to being of type "PosDecimalType" and hence has a max value of 100000.0

To illustrate the problem, you need to first create a radar.xml file (see [1] below) and then attempt to validate the radar.xml file (see [2] below)

[1] python3 ADES-Master/Python/bin/mpc80coltoxml ADES-Master/tests/mpc80data/radarsample radar.xml
[2] python3 ADES-Master/Python/bin/valgeneral radar.xml

--- general has failed: --- ... --- lxml.etree.DocumentInvalid: Element 'delay': [facet 'maxExclusive'] The value '150885360.' must be less than '100000.0'., line 8

Bill-Gray commented 1 year ago

It'd be nice if radar examples were provided here in both .psv and .xml, not just in punched-card format.

stevechesley commented 1 year ago

So this was a bug in the conversion to and from obs80. The scripts assumed erroneously that the delay is measured in microseconds, whereas the ADES standard is give the delay in seconds and the uncertainty in microseconds. Should be fixed now with commit 9261706.

@Bill-Gray , I have some files that represent all of the Toutatis radar astrometry, which I have occasionally used for testing. I've put those over in the ./tests/radar/ directory. There is no header/context in these files, but I hope they can be useful.

Bill-Gray commented 1 year ago

@stevechesley - thank you; that oughta do it.

It seems to me the times should be rounded to the nearest second.

It's not a high-priority item for me, but... if you happen to have test cases exercising the residual sub-elements such as resRA, sigDec, selAst, biasTime, etc., that'd be good. I make precisely zero use of these at present, and I think I'm not alone in that. But I like the idea; I could see them making a good replacement for the .rwo format, for example.

If you don't have such examples, don't rush; I may produce some and save you the need.